CMDB: what does it really mean

"CMDB" means many things to many people. When the IT Skeptic debates against "CMDB" or "CMS" what I really mean is "that huge IT Monument to unnecessary technology which is known to the vendors and their sucker buyers as CMDB". Unfortunately the more precise label is a bit ponderous :) The term CMDB which was originally a label for a Generic Thing has become hijacked to be the label for a Great Big Technology.

I can handle vendors inflating and over-selling the CMDB concept - after all we expect that - but ITIL does it too. The implication of ITIL is that everyone needs a CMDB. And since ITIL fails to define CMDB technology, being anything from a piece of paper to a multi-million-dollar software package, everyone equates CMDB with the latter. (Actually I wouldn't be at all surprised if Ivor slipped some common sense into Service Transition somewhere about a spreadsheet being good enough for many situations, but - like many books that inspire a movement or religion - ITIL is more about what people THINK the books say than what they actually do.) And that's the concept I'm chucking rocks at - the "solution" at the big end of the technology spectrum.

One of the very few companies in my country that just might have had a good business case for a software CMDB ended up spending millions on an over-analysed over-engineered stand-alone solution that delivered little and late. It was designed and built by multiple certified ITIL V2 Managers. If they had recalled a few simple concepts they might have been more successful:

• Nothing can be perfect, least of all IT operational information
• Better to have something simple working than something complex unfinished
• Technology is not a solution to anything except inefficiency or ineffectiveness of process. If the behaviours are wrong or there is no process, there isn't a technology that is going to fix that.
• A CMDB only offers any value as a service (in the programmatic sense not the ITSM sense) to other tools and a source of information (especially impact analysis) to humans. A stand-alone bucket of data is a sink of value not a source.
• A simple asset database is not a CMDB. Asset information offers much return for much less investment than a CMDB does. Go for an asset database first.

We often need to track the relationships from services to their component CIs, in order to improve the efficiency and/or effectiveness of our processes. Once we understand the deficiency to be addressed, then we should select appropriate technology. Often the solution is a spreadsheet or a webpage or a capability to track the association within an existing tool. Is that a CMDB? Strictly, yes. Do I think that is a good idea? Yes. But if I say so, that doesn't mean that I approve of sinking six-to-eight-figure sums into implementing some monster technology to be a CMDB. These are different uses of the term "CMDB". Perhaps I can say that there are three uses of the term "CMDB":

1. To refer to things that aren't a CMDB at all because they don't record the configuration of a service, they are an asset database.
2. To refer to specialised technologies that are nothing but a CMDB
3. To refer to a way to record the configuration of a service that doesn't need a specialised tool.

The last one is a much-overlooked option. Let's stop leaping straight to the over-engineered option 2. Don't start building a specialised CMDB just because you have determined a need, and most of all don't start building it before you even have a need.