Organic CM: Natural Goals of Configuration Management

Before starting to establish or improve configuration management in any organization, it is very important to be able to articulate what CM means.   This issue of being able to describe CM to non-CM people is perhaps the biggest issue facing a configuration management professional.    Certainly, there is the ‘classic’ definition of CM:   Configuration Identification, Configuration (change) Control, Configuration Status Accounting, and Configuration Audit.    However even within CM circles this definition generates debate – particularly around the subject to “Configuration Status Accounting” – so how can we expect non-CM people to understand it?    It should not be surprising that most non-CM people find the definition at best non-compelling, and at worst non-accessible.

Therefore Organic CM takes the stance of describing the operational goals of CM, rather than an exact definition.    This turns out to be a much easier thing to do; in fact the natural goals of CM can be summarized in one simple and very accessible statement:

The natural goal of Configuration Management is to be able to compare expected –vs- actual.

This statement should give almost instantaneous meaning to CM:  this comparison of actual –vs- expected occurs so frequently in everyday life and creates the perfect starting point for further discussions about CM.    This easily leads into high level (policy) discussions about what things are ‘important’, who controls them, how to determine expected and actual values, who needs to know when there are differences, and how reconciliation should happen.

One thing to be aware of is that expectations can be general, or specific.    The big difference between the two is that specific expectations are clearly assigned and have associated and usable metrics, while general expectations are “everyone’s” responsibility.   A particularly good example of this sort of thing can be found in the expectation of quality:  there is usually some Quality Assurance group that is specifically responsible for software “quality”, while the developers and the rest of the organization have a general responsibility.    A good way differentiate between the two is that specific responsibilities will be directly reflected somewhere on an employee’s evaluation review, while general expectations will be reflected indirectly, vaguely, or not at all.   As the goal of CM is predicated on comparison it naturally deals with specifics rather than the general.

One additional thing that this goal statement allows us to do is to evaluate where CM best fits in an organization.