Network World's Network/Systems Management Newsletter, 07/24/06
CMDB adoption: How best to get the job done
By Dennis Drogseth

In getting ready for a Webinar entitled "CMDB Adoption in the Real World - Just How Real is it?" - it occurred to me that several of the most significant results could be summarized in what I might call "three pairs." Now for those of you who play cards, you know that three pairs is neither a poker nor a bridge hand - but it appears to be the hand that we've been dealt with in CMDB land.

But before taking a closer look, let's provide a quick reference point for what a Configuration Management Database (CMDB) is. Historically the CMDB is a creation of the IT Infrastructure Library (ITIL) and its best practice recommendations. ITIL's notion of the CMDB reflects its definition of configuration management as touching virtually all aspects of the infrastructure as it maps to service delivery. This includes hardware and software, topological and configuration detail as well as operational and business impacts, service mappings, asset-related implications and even incidents impacting critical services. In short, the CMDB is a dynamic common ground for providing consistent perspectives across virtually all management disciplines.

Two parents

In the last column I wrote on CMDB adoption based on some fairly extensive research (154 respondents, plus 30 hours of in-depth focal interviews) - I focused on CMDB's two parents: ITIL and the need to find a better way to integrate and reconcile multiple management investments. In other words, although ITIL has done a superlative job of codifying the need for an integrated resource of information to enable service management from a process perspective, another CMDB driver is toolset integration.

Now the need for toolset integration has been around as long as the IT infrastructure/service management industry has existed. In the past, GUI launches were considered adequate, as were event sharing as alerts got passed upwards from one system to another. But data-level integration was often considered superior - as through it data can be actually shared and can support multiple analytic, visualization and reporting capabilities with consistency. In other words, if you really want to integrate your management investments - isn't finding a compelling way to integrate data vs. simply having siloed tools launching off each other or sending alerts to each other - a more satisfactory answer?

Well, generally, the answer is "yes" - and the CMDB adoption frenzy is being driven a lot from that requirement. But what's interesting is that CMDBs are really more about reconciling and rationalizing different management tools than they are necessarily about pure play data integration, as we shall see in the two CMDBs.


Probably the most stunning realization from the research - for me, at least, is that there are two overarching clusters of CMDBs. One is a more classic, "core CMDB" designed to capture desired state in terms of configuration, topology, service interdependencies, etc. When changes are made in classic ITIL fashion, they're reviewed by a Change Advisory Board (CAB) and approved before the data in the CMDB is itself altered. In this way, core CMDBs can be hugely valuable in change impact management - and ensuring that changes occur in a controlled and consistent manner. This in turn can bring great dividends in terms of everything from operational efficiency costs to IT service performance and new service provisioning.

The other overarching CMDB system (one could argue that it's not a CMDB) is a real-time system reflective of discovered states that's typically utilized for service impact management. In other words - this class of CMDB is used for performance and fault management, service level management, and real-time issues in business process management. Here, typically, data isn't moved - reconciliation is based on defining a trusted source (e.g. which toolset will I depend on for Layer 2 connectivity/topology), providing time synchronization across brands and making that data consistently available across the full IT organization. Sometimes a meta-schema is deployed as well for consistent representation. When this is the case, the discovered information can provide a resource for populating, upon review, the "desired state" CMDB.

Two owners

If all this sounds like a huge technological challenge - wait till you get to the politics! Just getting groups to mutually agree on trusted sources for information may threaten the habits, egos and in some cases even the identities of some of your most stalwart IT professionals. CMDBs can create huge efficiencies (one real-time system reduced mean-time-to-repair by 70% when downtime cost $1 million a minute) - which can also be scary to organizations and individuals.

To get the job done, your best bet is to have defined process owners, to help evolve and communicate best practices in dialog with the full organization. You'll also want an architect or technology owner with resources of his/her own to support the thorny issues of technology integration and process automation. These two need to work together. And they need to do so in patient dialog with the rest of the organization.

Needless to say you will also need commitment including budgeted resource and executive buy-in to get moving. This commitment becomes easier when you can show value in phased rollouts within six months to a year.

Copyright Network World, Inc., 2006

Questions or problems regarding this web site should be directed to abeckman@outdoorssite.com.

Copyright 2008 Art Beckman. All rights reserved.

Last Modified: March 9, 2008