"Good IT Service Management is simply not possible without” a CMDB? Balls!

I just read Larry Cooper’s article in the latest DITY newsletter: A CMDB Runs Through IT. Larry’s assertion is that “Good IT Service Management is simply not possible without” a CMDB. My reaction: balls!

I guess the key word is “good”. In that circular reasoning used by so many ITIL advocates (and cults in general), if you define good ITSM as ITSM-with-a-CMDB then this statement must be true. But if “good” is defined as “effective and/or efficient”, then I beg to differ.

“Most IT shops just starting their ITIL journey, including smaller ones, need to get past the idea that they can ‘do IT’ without a CMDB”. Um.. all of them do it now Larry.

And statistics show that the majority of sites who have improved their maturity in some or all of the ITIL processes did it without a CMDB (configuration management is implemented in less than half of ITIL sites).

The tricky reasoning here is more often found in software vendor white papers, but this is very similar. The reasoning of the article goes like this: it would be nice if all the ITSM data was gathered up in a CMDB therefore everything you do now that needs ITSM data needs a CMDB.

The simple test to show this thinking isn’t worth a pile of foetid dingo kidneys is to ask yourself “do we do it now without a CMDB?” The answer to every example in the article is “yes”.

You can do good ITSM with Excel and PostIt notes, if the processes are good enough. Technology does not make ITSM possible, or even good. It just makes it easier and more efficient once the processes are good. ITSM is about process - it is done by process.

There are a couple of things that are pretty hard to do without a CMDB in large organisations: incident impact analysis, root cause analysis and change impact analysis. But even these activities are often done with a “CMDB called Bob”, i.e. in someone’s head. [How many organisations distrust what the CMDB tells them enough that they go check with Bob anyway?]

Look at all the other examples in the article. Every one is done now with a specific “data island” tool, and good ITSM can be done by continuing with such a tool. I’ll just pick a few:

“The real value of Incident Management is only realized when we can associate incidents to the appropriate CIs”. So we need a list of CIs in the Incident logging tool. “It also makes incident trend analysis infinitely more valuable as knowing which CI’s (or CI types) are causing the most incidents can help us determined if we problem management ought to be involved.” Simple query against the incident log database.

“An RFC can only be issued against a known and authorized CI”. Asset database, simple list again.
“Proper Release Management is critically dependent on the CMDB to know the ‘last known good state’ of the CI in production”. Standard checkpoint/backup practice.

“Capacity Management is all about the CI’s that make up the IT Infrastructure – what is their total capacity and how much of it is being used.” Standard historical performance database.

“The IT Service Catalogue as well as the key attributes of signed Service Level Agreements (service level targets, support hours, capacity requirements, and so on) are critical pieces of knowledge that need to be reflected in the CMDB such that proper Service Level Reporting can occur”. For “reflected” read “duplicated” so why is it “critical’ that we “need” it?

Look, centralising everything in a geek’s über-repository has been the dream for years. And yes it would make life easier. More efficient even, but only if you take a narrow view of the execution of a task. If you spend ten thousand hours building and maintaining a tool so that it shaves an hour off a task, is that more efficient? Depends how often you do the task.

If you spend a million implementing a tool to mitigate the risk of Bob falling under a bus, is that money well spent? Compared to two Bobs?

If you divert a project team for six months to build something invisible to the business is that competitive?

Will an automated CMDB that involves synchronising/federating data from a a dozen sources be more or less error-prone than Bob?

CMDB is not essential to doing a good job. Good ITSM is possible without CMDB. Good process is essential. Good tools are nice.