Configuration Management is a process not a thing

ITIL defines Configuration Management as the delivery of information but then spends most of its pages describing Configuration Management as the maintenance of a static repository of data, not an active process of serving that data to others. Let's get it clear: Configuration Management is a process not a thing (in the wild wanton ITIL sense of "process": if that word upsets you - as it does me - then substitute "practice" or "activity").

Improving Configuration Management is about improving the data that is delivered to other Practices. Configuration is not about pretty data stuffed and mounted in cool GUIs. It is about the value, the business benefits, derived from that data.

When we improve Configuration Management it pays to recall the mantra "People Process Technology" or as the IT Skeptic prefers "People Practices Things".

People

Our focus is to improve the way people behave, and hence the results they get. So the main issue is to address configuration culture. The problems with configuration data generally arise from people who

• don't want to be answerable for what they do,
• don't want their technical brilliance challenged by having their work checked beforehand or after the fact,
• or are "too busy" to keep adequate records

Unless we address these cultural issues, all the whizzy CMDB toys in the world are not going to address the problem.

Practices

When staff try to do better with configuration, we address improving their practices. With Configuration, the key practice is Service Impact Assessment of incidents, problems and changes. If we deliver what the organisation needs for understanding the impact on services, we are doing Configuration Management. I contend that all the other benefits commonly ascribed to Configuration Management are in fact benefits of the simpler Asset Management, which is performed with different processes and simpler tools.

All the other Configuration Management practices exist to collect and assure the data needed for Service Impact Assessment, so their results are measured in the same terms: our ability to deliver Service Impact information.

Before we rush off implementing a CMDB, we first need to be optimising our practices. That's what ITSM is all about, remember? Optimising Service Impact Assessment reporting involves being more timely, more accurate and more efficient. "More timely" doesn't necessarily mean faster. Timely means fast enough. We must look at the true business requirement for the impact data. Perhaps the need is actually measured in hours rather than minutes or seconds. Likewise there comes a point where the information is accurate enough to reduce the risk to an acceptable level. Further accuracy and speed are ETF - Excessive Technical Fastidiousness, also known as GAR - Geek Anal Retentiveness. Let it go. Pursuing more speed and accuracy than really necessary to address business risk acts against the third objective: efficiency. Put another way, you would be blowing your employer's money.

Things

Sometimes by improving practices we identify genuine bottlenecks or sources of error or inefficiency which would be helped by better tools. We must keep in mind the objective of better Service Impact Assessment information delivered when required. It is not about better information lying around unused just in case. That is one way: if the need for speed is so high that it is impossible to derive the information fast enough when required, then we need a big bucket standing ready: a CMDB. By addressing culture and practices first, you will have the empirical data you need to build the business case, to justify the investment in a CMDB by the risks involved and the demonstrated inability to reduce those risks to an acceptable level through behavioural and procedural change alone.

More likely we only need to store simpler derivations of the data that take us steps closer to the full information, reducing the amount of effort required when information is requested, leaving us less pieces to assemble. E.g. network topologies, server inventories, network traffic patterns, more complete asset lists, access to new data e.g. org charts, procurement.

And/or we need tools to help us perform that derivation, that piecing together, more quickly. E.g. query and analysis tools, data cubes and spreadsheets, report delivery mechanisms

To read most of what is written about Configuration Management, you'd think a CMDB was a given, an essential tool for all organisations. I hope you can see that it is just one option, one piece of the puzzle of People Practices and Things. If you go through the filtering described here and still determine you need a CMDB, welcome to the Five-Percent Club