I’m sitting on my sofa at home (Yes! Home!) on Sunday morning just before Christmas. I’m “shut down” for the holidays now, but of course, I’m watching Twitter and now listening to my brilliant friends Chris Dancy and Troy DuMoulin discussing CMDB (configuration management database) on the Practitioner Radio podcast. It’s a marvelous episode, covering the topic of CMDB in with impressive clarity! I highly recommend you listen to their conversation. It’s full of beautiful gems of wisdom from two people who have a lot of experience here – and it’s pretty entertaining too!

I agree with everything these guys discussed. In particular, I love the part where they cover systems thinking and context as the key to linking everything conceptually. I only have one nit about this podcast, and the greater community discussion about CMDB, though. Let’s stop calling this “thing” a CMDB!

I coauthored a book with the great Carlos Casanova (his real name!) called The CMDB Imperative, but we both hate this CMDB term. This isn’t hypocritical. In fact, we make this point clear in the book. Like the vendors, we used CMDB to hit a nerve. We actually struggled with this decision, but we realized we needed to hit those exposed nerves if we were going to sell any books. Our goal is not to fund a new Aston Martin with book proceeds. If so, we failed miserably! We just wanted to get the word out to as many as possible. I hope we’ve been able to make even a small difference!

“CMDB” is misleading in countless ways, but let me highlight a few of the biggest flaws:

  • CMDB carries a lot of baggage. I am fortunate to speak with lots of people in this job. When we get talking about CMDB, they almost always respond negatively, with a sigh of resignation, shoulders drooping, and eyes rolling. Stories of CMDB failures abound. Many of those who were burned lack the will to take another shot at it. We can cast the blame all over, but that doesn’t matter. What matters is that the damage has already been done. Let’s move on, forget about blame, and fix the future.
  • It’s not a DB. Every time (every time!) someone attempted to build out a comprehensive, large-scale CMDB as a monolithic database (the vast majority of attempts), it failed. I’ve seen this play out hundreds of times and I myself made this mistake eons ago. The right approach is a federated model of data repositories scattered across your environment. The data is already there in many cases, so why try to force this into a single monster-sized database. Abandon any illusion that a single database will work!
  • It needs to include more than configuration data. When ITIL v3 appeared in 2007, it introduced the CMS (configuration management system) as a superior model to CMDB. The authors were right. CMS is indeed far better, but even CMS doesn’t go far enough. It’s also often confused with “content management system.” The ‘C’ part of CMDB (and even CMS) is a limitation. Configuration details are undeniably important, but the information model has much more potential if we expand beyond that perspective. The right approach also captures performance data, codified process models, policies, and other information that enriches the context that makes the data meaningful and useful. Expand your mind beyond configuration.
  • You cannot rely on people to keep the data accurate. This is another common failure and again, one I made as far back as 1986. I learned. Manual updates to the data are necessary in some cases, but we depend too much on manual updates. ITIL is largely to blame, but mostly old-school ITIL. The new thinking of service management incorporates automation to ensure speed and quality of process execution. Every time a human touches the CMDB, you expose a failure risk. The cumulative risk of thousands of touches is astounding. Automation tools are rendering many manual updates obsolete. Deploy discovery and reinforce it with integration to your automation technologies. For example, when you move a virtual machine from one physical server to another, let the automated system do the update for you. Keep those human hands out of the CMDB wherever possible. Automate everything you can.
  • Service catalog is included, not separate. In the CMDB realm, service catalog is usually a separate topic and disconnected from the CMDB. This is unfortunate. Chris and Troy talked a lot about abstraction and layers of visibility cleverly using Google Earth and Street View as analogies. When you think of CMDB in terms of this hierarchical structure, you realize context and meaning exist in many layers. The layers are linked by abstraction, so you can navigate up and down the chain like you zoom in and out in mapping systems. What we have come to know as the service catalog is the model as seen from a high level. Make sure the service catalog is integral to your whole information architecture.

I keep referring to the right approach, so what is this right approach? The community debated this heavily in 2011, culminating in a report I published at the end of that year with the title, Reinvent The Obsolete But Necessary CMDB. While I was one of the principal instigators of this debate and the primary author of the report, many people in and out of Forrester contributed to this. The biggest part of the debate was what to call this new model. After a lot of gnashing of teeth, we all concluded that an appropriate identity was Service Information System (SIS). It’s not sexy, but it captures the essence of the right approach.

I implore the entire community to wean themselves off CMDB – the term, not the concept. The concept of having a model of reality is profoundly valuable, but the tarnished CMDB term is holding us all back. As we try to automate more of our environment and as the services themselves get more dynamic every day, this need for trustworthy contextual information becomes more important.

Nobody is yet married to the SIS term, but it seems to be catching on. It is the best identity we have for this new model of CMDB. Let’s start talking about SIS instead of CMDB. Doing so is an audacious step, but it’s also necessary. You should not have to deal with the intricacies of federation and object modeling. Apply pressure to the vendors to simplify the inherent complexity. Make them do the hard work for you.

While you’re at it, push the vendors to also hop on the SIS bandwagon. I will publicly appaud the first vendor to make the jump from CMDB to SIS. This is not easy for them and it’s our fault. If customers are asking for CMDB, they must deliver it or they don’t make money! Stupid demands yield stupid products. Help them gain the courage to break the mold, but that means you and I need to have the courage too! The future belongs to the courageous, not the conformists.

Death to CMDB!