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.


CMDB/CMS is not an architecture

There are many kinds of systems marketed to improve IT management. Whether or not any given company needs them requires in depth business case analysis. And, for organizations of a certain size, an architecture for the IT capability itself is highly advisable. This architecture might cover any number of systems, e.g. project management, IT finance, help/service desk, incident management, change management, SDLC tooling, IT supply chain & asset management, availability, capacity, analytics, and a myriad of lower level element management systems (monitoring, provisioning, services like backup & scheduling, etc).

All of these systems share certain data entities and subjects. A CMDB can provide a useful master system of record for some of these entities and mitigate some "silo" tendencies compared to if these systems are implemented standalone. But the discussion should be framed as an overall architecture for the IT problem domain, and not prejudiced by prefixing the word "configuration" to it.

Charles T. Betz

Syndicate content