Why CMDB’s Fail

Why do CMDB Initiatives Fail?

We keep hearing IT organizations say “we need a CMDB”.  They want this in order to manage the risks associated with their changes and/or to understand the assets they have.  This usually includes a focus on the less-tangible elements (including applications and databases) and how they are related to services. Over the past few years, I have seen many CMDB initiatives, covering both first-time efforts and attempts to resurrect initiatives that had faltered. From my experience, the following 3 factors were the leading causes of failure.

Let the discovery tool do it for me

The first instinct with discovery tools is often “let’s plug it in and capture everything out there”.  But that instinct is misguided – we really must tell it to collect only what we need.  Allowing the tool(s) to scan and discover your environment without saying what we need will bring in masses of data, a large part of which is either not controllable, not useful or both.  This will be sensed as cost ineffective and/or too time consuming, so gradually the dedication to keeping records up to date falls off, and the CMDB becomes less effective as that happens.


Before selecting a discovery tool or tools, identify what you need from the CMDB by stating clear requirements. Once requirements have been stated, define the data model you need, which will include CI classes, CI types and the attributes you need to manage for each. When you have this information, THEN you can look at the discovery tools available and identify the toolset that best meets your needs, remembering that you will have to configure the toolset.

Lack of an organization-wide change management process

Change Management is fundamental to keeping your CMDB viable. If you do not have a unified Change Management Process, updates and changes to the environment will not be consistently validated against the CMDB, with the data elements becoming out of date and hence useless as a reference. I have seen CMDBs fail because Operations and Application development teams do not communicate or use the same Process.


Ensure the organization has an empowered ITSM Program Team responsible for ITSM across the whole Organization – including Change Management.  This team needs the authority to govern – to enforce its policies.  When everyone marches to the same drummer, the outcomes are better aligned and useful to the business.

Expecting it to be done in a short time

As you can likely infer from the previous points, a CMDB is not something that you expect to finish overnight.  The growth and maturity of a CMDB never has a finishing line, it constantly evolves. All IT environments change due to hardware and software technologies coming and going and business needs changing. The CMDB strategy must keep up with this.   I have seen organizations take the time to implement a CMDB using a “Design Wide, Implement Narrow” approach, and within five years, evolved a CMDB to the point where they are managing everything they wanted covered across the organization. They started with the most immediate needs, and then grew where and when the business requirements dictated.


Be patient, plan and get the right people in place before starting this endeavor. You will see benefits even in the early stages if you don’t try to rush it.  The success and benefits of your Configuration Management System, CMDB, and process, will be seen in processes such as Incident, Problem, Change and Release & Deployment.

In conclusion

Implementation of a viable and effective Configuration Management System (CMS) and CMDB is not something to be undertaken lightly. It takes:

  • Time (requirements, data model definition, and CMDB discovery tools selection),
  • Planning (organizational alignment, resourcing, and an overall ITSM Directorate),
  • Service Asset and Configuration Management process implementation (intra-process alignment, roles, governance) and
  • Communication (awareness & benefits campaign, expectations, and timelines).

Approached this way, the likelihood of a successful CMS/CMDB will be greater, with observed benefits across the organization as a whole and the investment seen as a good one. Additional information on the CMDB can be found here The CMDB Imperative: How to Realize the Dream and Avoid the Nightmares and Wikipedia: configuration management database



• Posted by John Crook on Sep 18, 2013
• Filed under Articles
• Tagged with

Share this post