Death To CMDB! Long Live The Dream!

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!


CMDB is more than just a tool

I couldn't agree more, Glenn.

I would like to add one short, but very important, comment to follow up on the idea that we should abandon the term rather than the concept.

Configuration Management (Service Information Management?) CANNOT be built from the ground up. Since most organizations started service management initiatives as a "grass roots" efforts configuration management as a whole was doomed to failure.

Why? Because as soon as you start controlling data that is used by more than one person or department it becomes political. If your service management project does not deal with the politics of inter-departmental alignment, then your Configuration Management effort will reflect the dysfunction.

The solution? This is not a tool. It is a way of life. When something is important to you, you manage it. You make it work. You know everything you NEED to know about it - and you know what you don't have to know.

In my opinion, the solution starts with understanding and agreeing on our priorities as a service provider. What is our reason for being? What do we do that delivers value? What do we need to manage to deliver that?

Once we understand and agree that - we can set common goals and metrics - and once we've done that we can figure the levels of management responsibility - and therefore the type of data required by each stakeholder. Some data needs to be available to everyone and it needs to be properly coordinated. Other data needs to be available and managed by only a single department.

The solution, I believe, starts with a Service Portfolio (or whatever you want to call the tool that itemizes your key priorities and how you manage them)

I think that service

I think that service providers have to take a somewhat different and yet practical approach to IT Service Management in order to focus less on internal processes and more on customer needs and satisfaction. The danger in trying to implement 'full blown' ITSM best practices is that you will most likely spend more time on fixing internal processes than delivering true value to the customer.

I'm not saying ITSM is bad in any way, but there needs to be a balanced in order for service providers to deliver AND return services quicker and with greater user experience. Traditional IT users have to be treated as consumers of IT services - this is what they expect and deserve.

I like the term 'Service Information System' because it's the service itself that is key to success and not the CMDB.

We can all agree that IT service best practices are a must, but here's the catch: most IT departments do not have the time to implement it. If they do, their customers will seek services elsewhere because it just takes too long getting access to services intended to support business goals.

Not having time is the reason you have to start with a 'bottom up' approach. You have to find the correct solution (spend as little time on the solution as possible to achieve your goal) to automate IT activities. IT automation is the only way to provide real IT as a Service and free up time to allow for optimizing IT, implement a balanced set of best practices and work closely with the customer.

Here's my recommendation to quickly free up time:

1. Identify your top 5 service desk incidents/requests
2. Automate the remediation of incident or delivery of request
3. Publish an automation (Run Book) in an intuitive self-service IT Store for users or service desk to request

Now you can take a 'top down' approach to ITSM and create your portfolio of services and it should be done with the practical approach in mind where the actual service is the object you manage.

1. Create the service object.

2. Identify who and why users should have access to the service (identification should always be aggregated from non IT systems) = Service Qualification.

3. Configure each service to be delivered automatically in a subscription model as soon as a user qualifies, and provide additional services through self-service.

4. Control (adapt and secure) the usage of the service when it is live in operation.

5. Return services automatically as soon as users no longer qualify (change in business rule).

Benefits of this approach:

• Business rules directly determine service qualification
• Delivery is instant and proactive
• IT can remain compliant as services are automatically returned when no longer needed
• The user gets a better overall IT experience and is treated like a consumer