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


So how do you define a CMDB

I really do think you missed the point. An Excel database or a Post-It note, or in a really small organization, someone's brain, can qualify as CMDBs. (Just kidding on the last one, unless you can clone the person on a regular basis for business continuity purposes.) I haven't actually read the WP, but any formal, organization-appropriate tracking of things (also known as CIs) can qualify as a CMDB and, in my mind, is an essential foundation for good service management. Call it a spreadsheet, a wall full of stickies, or a full-blown ITIL-enabling system, it's still a CMDB and a requirement for any organization wishing to call itself serious.

If it don't do all that, it ain't a CMDB.

Oh no, not this arguement again, please. I haven't read Version 3 Service Transition yet, but it's on its way to me as we speak. In version 2, a CMDB has some specific attributes that makes it a CMDB as compared to an asset database or a list. This has been debated a few times on this blog. Bob's brain is about the only thing on your list that is in fact a CMDB:

  • tracks relationships including mapping CIs to a service,
  • stores *all* the CIs in the environment,
  • reports the current status and history,
  • enables ITIL activities such as incident impact analysis, root cause analysis, change impact analysis, and SLA monitoring and reporting

If it don't do all that, it ain't a CMDB. Leastways, it wasn't in V2...

ITSM without CMDB?

I agree. You can do service management without a CMDB, but don't forget that service management was being done with a CMDB long before the CMDB name appeared. I have seen a lot of CMDBs built with Excel, Access, perl, and zip ties. If the site has a robust process, those tools get the job done. A commercial CMDB won't save a site that is unable or unwilling to invest in a good process for maintaining their CMDB and managing their services.

However, Skeptic, I think you miss a point: with the right process, a commercial CMDB will do a better job of leveraging IT staff and resources than a homegrown system built by folks whose talent is managing services, not building systems to support service management.

Marv Waschke
Disclosure: I work for a CMDB vendor. http://ca.com/blogs/waschke

CMDBs are a huge undertaking: get two Bobs

Marv, we are in agreement, excpet the bit about how I miss the point :-D

The point of the article might be that CMDB does things better, but that is not the CLAIM of the article. The article claims they are essential, that a good job cannot be done without one. As you and I agree, that's balls: process is what counts.

And perhaps you miss my point: the fact that a tool makes things better is not enough to invest in it. It has to make it sufficiently better to business justify the investment. This means the money is well spent and the money would not be better spent somewhere else.

CMDBs are a huge undertaking. I don't believe they return the investment except in huge organisations. For everyone else, get two Bobs.

Two Bobs? Where am I going to get two Bobs?

Ah Skeptic, we agree again, a tool has to improve things enough to pay for itself. But part of the cost of not having a CMDB is the fact that Bob is busy answering questions instead of applying his experience to the high skill stuff with real payback, like discovering permanent solutions to chronic problems. And have you ever hired a Bob? I haven't. A good Bob takes at least 3 years to grow. And then he decides that no matter how much you pay him, he is quitting to run a winery.

I don't know about CMDBs not having good ROI except in huge organizations. I don't have any facts to back me up, yet, but when I think back to the days when I was administering small IT systems, I wish a CMDB had been the first management application I purchased.

As I recall, the first serious IT management problem that comes up is when your head gets too small to hold the configuration and run the department at the same time. That comes about 18 months before your monitor gets too small to hold the sticky notes. I think that means buy a CMDB first and a Service Desk 18 months later. If you can find a cigar box and some index cards, you can stave off the Service Desk by another 6 months. This goes along with the process first theory. Processes built around configuration management are more fundamental and proactive than incident and problem management practices. I believe in skipping reactive and becoming proactive as soon as soon as you can.


Nice reply.

Nice reply.

If the business case is there, I'll go along with any CMDB project.

But I'll be looking hard at that business case to ensure it has costed the ongoing audit and maintenance of the data and of the processes delivering the data.

An aside on CMDB federation

Last week you commented on the forthcoming CMDBf interop session. I am sitting in it right now. I won't reveal any results, but I will say there were no voices were raised today.

if the super-suits start "discussing" who has to change

As I've said in the past, I'm sure things are convivial at the techo level. The fun bit begins if the interop doesn't work and the super-suits start "discussing" who has to change...

Syndicate content