Configuration management is four things.
- Identification
- Change control
- Status accounting
- Auditing
Nothing more, nothing less.
Derived disciplines such as software configuration management, product data management and so on, are always based on these four functions.
Configuration Management Variants
Many people include other disciplines under the banner of configuration management. This is a mistake for two reasons:
- It confuses the definition of configuration management
- It makes describing both configuration management processes and the processes of the conflated disciplines more complex and, perhaps more seriously, creates an artificial dependency between disciplines.
Conflating disciplines such as build management or release management with configuration management gains nothing while simultaneously corrupting and confusing the definition and descriptions of each discipline.
It is ironic that a discipline such as software configuration management which, when dealing with software systems, emphasises the need for modularity, clear interface definitions and system boundaries, is itself poor at maintaining such clear distinctions between configuration management and other disciplines.
Briefly, the four functions of configuration management are described next.
Identification
In a nutshell: Everything that is to be controlled is to be assigned a unique identity.
Identification is a process, in that you need to establish how controlled items will be given their identities, and an imperative, demanding that all controlled items are assigned a unique identity.
Creating a scheme for assigning unique identities can be tricky, so be prepared to dedicate some time to this task. Aim to create a scheme that:
- guarantees uniqueness without having to verify each new identity against an existing list;
- does not contain attributes of the items environment that may change (the class error being the inclusion of an item’s location in its unique identity – as soon as the item moves the identity becomes confusing as its location information no longer concurs with the items new location);
- is readable by human beings.
The identification process must be as simple as possible. Requiring user to complete long forms, or submit items to a long identification process without very good reason, will have one of two outcomes; either, users will simply work around the system, or (if they are compelled to comply) work will be significantly delayed.
Where practicable make the identification process automated, or at least sufficiently simple that users can administer it themselves.
Change Control
In a nutshell: Every change to controlled items is to be raised, assessed, approved, implemented and verified. Furthermore, records are to be maintained sufficient to control and record this process for posterity.
Change control is the braking system for configuration management. Just as with the braking system on a vehicle, if applied inappropriately the change control system will slow the system down or result in catastrophic failure. However, applied with finesse a change control system will help a project complete in the fastest time possible. (It is notable that F1 cars, although designed to travel a course as quickly as possible, still have a braking system.)
Change control essentially consists of five simple steps:
- Raise – properly document the effect desired from the change. Notice that this does not necessarily identify the controlled items that will be changed to implement the change at this time.
- Assess – technical and business analysis is performed to determine the cost/benefit of performing the change. It is during this step that the controlled items that need to be changed are identified along with the extent and nature of the changes. Costs and benefits are established so that a reasoned decision can be made as to whether the change should proceed.
- Approve – a suitable authority, one holding sufficient authority to affect resource changes for example, approves or rejects the change based on the information provided from the assessment step.
- Implement – approved changes are scheduled for implementation and then implemented. Implementation covers all steps up to and including delivery of the change to the requesting user. Implementation includes all development testing and operational implementation of change.
- Validate – the final step if for the original user (who raised the change) to confirm that the change has been correctly delivered. Only when this confirmation is received is the change considered closed.
How, if at all, does this (configuration management process) change control differ from change management? In principal it does not differ, in practice is differs in scope. Change management tends to deal with changes in a more abstract sense than configuration management. That said, there is significant overlap and it is perfectly possible to have both configuration management and change management handling the same changes.
Status Accounting
In a nutshell: The status and disposition of controlled items and the records used to control changes to them, are to be know and reportable at any time.
Throughout any journey it is wise to take stock of your current situation. This is the role of status accounting. Status accounting is to be able to answer questions such as:
- How many changes are currently in the change system?
- Of these, how many are in each of the process steps; raised, assessed, approved, implemented, and verified?
- What is the total predicted outstanding cost of these changes broken down by resource (e.g. finanicial, man/hours development, or man/hours testing)
- What is the disposition of each controlled item?
Status accounting is about taking a snapshot of a project during its life cycle.
Auditing
In a nutshell: The history of controlled items and the records used to control changes to them, are to be subject to examination to ensure that all change was records, approved and implemented according to the defined configuration management process.
Where status accounting is about taking a snapshot of a live project, auditing is about verifying that the product of a project has integrity. Are all controlled items in a product accounted for? Where all products subject to the correct configuration management process? Have all changes to the controlled items in arriving at this product been correctly accounted for?
Final thoughts
Configuration management is often perceived as an overhead, too complex to be practically applied. This view is badly mistaken. It should be clear from this article that configuration management, correctly defined, is a very straightforward discipline.
