Taking on the CMDB Deathstar

Anyone who has read my posts on CMDB and those of Troy DuMoulin on that same topic might think we disagree and they'd be right... but only partly. There is a lot we DO agree on over CMDB. Nevertheless I look forward to some brisk debate at the Pink conference in February in Vegas.

I concur with Troy's arguments that an organisation needs to be at a certain level of maturity before they even think about configuration management. If you don't care about services then you don't care about configuration.

Of course Troy is a nice polite guy who doesn't address my posts head on, but you all know I'm not so restrained :) It seems to me that Troy, like most CMDB proponents, falls into two traps:
1) assuming "configuration management" automatically implies "CMDB"
2) approaching configuration management bottom-up from its component parts instead of top down from its reason for existing, its value delivered.

Some people use "configuration management" and "CMDB" interchangeably which really winds me up but Troy knows his stuff - he's not doing that. He is however operating on an assumption that configuration management will inevitably lead to a CMDB. In one post he said

In most organizations the CMDB is stored in the grey matter of our subject matter experts and has to walk into the room each time we need to make an important IT Management decision.

...as if that is a bad thing.

We don't try to automate our Unix administration IP or security policy or myriad other stuff that rests in that same grey matter but we get worked up when configration data lives there. Why? Because the other stuff is process and IT folk don't reflexively want to automate process in quite the same way they do data. Apparently, data not digitised is an abomination, a failure of diligence, unbearably inefficient.

But the reality is that automating data storage has all the same challenges as automating procedures or policy.

We only automate procedures when they are extremely stable - we don't have to be changing them all the time - and they are performed on a very large scale that justifies the investment.

Likewise we should not try to automate configuration data unless the same two conditions pertain. But our IT environment is constantly changing. I don't mean the many small changes: I mean the BIG configuration changes. New technologies require new sources of configuration data, new relations, new business rules for walking it and drawing inference from it. Humans adapt to these changes far more quickly and cheaply than code does.

And we don't automate a lot of policy because it is abstract stuff that only humans can handle. Which also describes the higher level configuration data too.

Finally, humans are far cheaper than systems that replace them unless there are very large numbers of them doing the same thing many many times per day. Configuration isn't like that in all but the very largest and most complex of organisations. So most of the time there's nothign wrong with configuration data in people's heads - CMDB is not a given.

Which brings me to my second point: approaching configuration management bottom-up from its component parts instead of top down from its reason for existing. What does configuration management actually DO? It only does one thing: it reports the impact on a service of a CI. It does this primarily for three areas: incident, service level reporting, and change. It does it in two situations: a change in availability status of a CI, and a MAC change to the CI. Everything else usually attributed to configuration is actually asset management.

Put another way, there is only one configuration process that needs to be integrated with anything else: Impact Analysis Reporting.

When we design configuration management we should start with the same steps as Troy's post ITIL Implementation Roadmap (Configuration Management):

# Establish the objective of Configuration Management for the IT organization
# Establish the scope of the Configuration Management process
# The definition of policies, standards around control and administration (Centralized vs. Decentralized)
# Define the process ownership, management and coordination roles

...but then I beg to differ. The next step is to look at Impact Analysis Reporting process, as I described in On Demand CMDB

All the other processes which Troy describes, "identification, control, status accounting, verification and audit", are either provided by asset management tools or are not required if we don't build a CMDB.

When we set up Impact Analysis Reporting process, and test it and rehearse it, we may find levels of unacceptable error, or unacceptable delays in reporting a result. Or we might not. If we do, then once we've exhausted the improvements from optimising the procedure and the team of people doing it, then we should look at tools. Simple tools like spreadsheets, analytical reporting tools, data explorers and scrubbers etc... And if THEY don't work, then maybe we can start building a business case for CMDB based on what we need out of Impact Analysis Reporting and can't get when we do it with wetware (humans). If you are one of those 3-5% of sites, bummer. Good luck finding the funds in 2009.

In response to arguments like mine, Troy said

Of all the processes described by ITIL none receives more attention and media hype than Configuration Management. For some, the Configuration Management Database (CMDB) represents the impossible juggernaut akin to the famous Spruce Goose. For others, the CMDB represents the Death Star, the ultimate weapon and tool of a dark and insidious master of a strange force bent on strangling the creative energy out of free spirited IT department. While for others the CMDB represents the ultimate panacea for all IT woes and the answer to world peace...

And yet IT builds and manages these complex federated systems for the business all the time. You would expect the bank to know all of the products and accounts you currently hold with them on a real-time basis. You trust that Boeing or Lockheed have a detailed relational database for each airplane down to the part level.

This is Charles Betz's "ERP for IT" argument. These kind of massive federated ERP systems built on common data are only suited to huge organisations, and we all know the instances where implementing them has all but brought down the company. They only pay off when, as I said above, the procedures are performed very often, repeatable, stable, by a large number of operators. Making that kind of investment is even harder to justify in only one department, IT. I don't see integrated business systems as a rationale for CMDB. Au contraire! it seems to me to be a salient warning.

I recently interviewed Troy for the Pink Elephant conference blog [link here soon] and we got on great. I think we'll have a ball in Vegas but a few of the over-a-beer debates should be interesting.