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".


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.


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.


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



I've driving myself to the edge of insanity trying to help the brilliant minds at the company I work for of exactly what you've put onto paper here. I've described it this way, "configuration management is NOT a CMDB somewhere that someone else maintains for you; it is just simply engineering discipline." I get blank looks back and the "I still don't think we need it", as if it is a thing they can live without.

I don't know how to get through to them (and I really do mean they're brilliant - I see what they can make). I also see what they have trouble handing off to other people to support because they're off making the next great thing and didn't have time to make sure their product was sufficiently understood by everyone (not just them), documented and controlled.

I've gotta find a new assignment or I'll be driven to madness trying to help people see what you've written here.

configuration discipline

it sounds as if you are referring to Dev handing over to Ops. That's one issue which I call Dead Cat Syndrome. But I'm not sure how tightly linked it is to Configuration Management? I'd hope Operations staff set up the infrastructure for a new service, not Dev, so that Ops knows the configuration. The handover should come before that.

The discipline I was referring to is more inside Operations, getting techs to actually record what they changed.

Expert CM Guidance for IT Service Managers and Practitioners

Assuming Rob doesn't delete this comment as too blatant a plug - those interested in practical Configuration Management, rather than the theoretical outline ITIL gives might be interested in the new book on Configuration Management from BCS, The Chartered Institute for IT, published this week.

This was put together from the results of a joint workshop of ITSMF-uk and BCS' Configuration Management Specialist group. The book is a digest of the collective practical experience and expertise of these two groups.


Configuration Management is at the mercy of the source.

I agree that the goal of Configuration Management is to deliver data when needed and with an appropriate level of accuracy to the processes which need it. The biggest challenge with this activity is NOT the gathering of and presentation of data to the people who need it. I think the biggest challenge is controlling how the data is created and maintained.

In many IT organisations, the Configuration Management process doesn't have input into the creation of the data that it consumes - often Configuration Management is asked to come in and make sense of data once decisions have already been made and tools have been selected... Think HR Data - HR is usually in control of this data without any input from Config. Config then needs to make guesses as to how they should interpret the data and where the value can be returned to the IT organisation. When performing Config activities, I often feel like an anthropologist - trying to make sense of a long dead civilisation with a significantly different cultural perspective on the information they used and maintain to perform their daily activities.

Syndicate content