CMDB adoption: How best to get the job done

How to win with three pairs

Industry analysis by Beth Schultz, plus the latest news headlines.

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

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

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.

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.

Schultz is a longtime IT journalist. You can email her or find her here.