The word is out about configuration management databases (CMDBs). Spurred by early adopter success stories, which often report an ROI of 200 percent, 400 percent, or more1, more than 65 percent of enterprise IT shops are currently in the process of implementing a CMDB solution2.

The benefits of a CMDB are many. Besides being billed as a must-have for IT Infrastructure Library® (ITIL®) adopters, a CMDB brings an attractive assortment of operational benefits, including improved service levels, reduced downtime, and fewer outages. These cost-saving advantages, along with the high cost of not deploying one, have incited companies to start CMDB projects.

There is, however, a flip side to this. A significant number of organisations have experienced disappointing results from their CMDBs. Why do some CMDB projects lead to discouragement while others generate demonstrable ROI?

Generally speaking, it’s not a CMDB’s technology that is insufficient, but rather, how it is populated. If the appropriate information model is not built into the CMDB before it is populated, it will fail—simply because it will contain massive amounts of irrelevant information. For CMDBs to be effective, they must be useful; they must be able to access data that answers business questions and solves business problems. CMDBs that are populated with discovery data alone do not function in this way.

Misleading Assumptions

Before an implementation effort begins, it’s important to discard misconceptions about the CMDB itself. If IT teams harbour mistaken assumptions about what a CMDB is or what it can (or should) do, it’s likely that its deployment will take a wrong turn.


A CMDB is not a “thing.” Organisations that believe this run the risk of not investing enough in pre-implementation planning, one of the chief causes of CMDB failures. Essentially, they become overly focused on the technology3 —presumably, what the CMDB will automatically “do.” As a result, their initial expectations for the CMDB’s performance typically run high.

A CMDB will not solve data quality problems. Many organisations rush to implement a CMDB because they believe that having a single source of record will eliminate issues with poor data quality. However, information is actionable only when it is 97 percent accurate, according to data management experts. To avoid misleading data --and an unreliable CMDB-- implementation teams must achieve continuous data quality assurance before, during, and after CMDB implementation.

A CMDB doesn’t have to contain every configuration item (CI). In fact, it’s unadvisable. Some businesses, believing they must store every piece of data in the CMDB, become overwhelmed with the notion of populating it. However, not every CI is appropriate for CMDB storage; accordingly, populating the CMDB cannot possibly be an entirely automatic, tool-driven process. IT organisations must determine which CIs are important to monitor for the business; these CIs belong in the CMDB and should be built into its information model.

A New Mindset: the CMDB as a Process

Implementing a CMDB should be conceived as a process or a journey. Embracing this mindset will prevent IT teams from trying to do too much, too early, with their CMDB. A CMDB’s success hinges on having the right data. The best way to achieve this is to populate the CMDB gradually, following a series of planned steps that lead to building a business-focused information model. It is this model that enables the CMDB to identify relevant data and ensure the proper process for accessing it.

Step 1: Define the Project Scope

A frequent difficulty with CMDB projects is that they are too broad and lack short-term wins. Fortunately, this scenario can be avoided by simply narrowing the scope of expectations attached to the CMDB. Instead of attempting to model every IT component in the enterprise, which results in a purely technical view, adopt a top-down approach that begins with the business.

Focus on a critical service, a given domain, or a line of business. Work with the business owners of the project to identify a specific business problem that occurs in one department or during a particular service delivery. Articulate the questions that need answers. Then, formulate objectives for the CMDB project that effectively address the problem, identifying short-term and long-term goals.

After the business problem and project objectives have been identified, loosely sketch how the business owners see the IT infrastructure as it relates to their individual department/service. Maintaining this high-level view, identify the core CIs (such as configuration, asset, and inventory information) necessary for achieving the business-defined project objectives.

Next, draw arrows representing relationships among core CIs without delineating their attributes. This sketch defines how the CMDB will be used and what it will manage. By identifying this information, your organisation essentially lays the groundwork for your CMDB’s information model from a business view.

The secret to a successful CMDB

Step 2: Identify Discovery Data

The goal here is two-fold: (1) to determine the relevant data sources that hold answers to the business problem articulated in Step One and (2) to identify each data source’s structure, format, location, and other information needed to understand the type of adapter needed to access and transfer discovery data into the CMDB.

Start by working with the technical owners of the project to identify the managing and monitoring products (or trusted discovery data sources) that are connected to each core CI identified in Step One. Then, identify the formats of these data sources (e.g., database, log file, XML, CSV, WS, report).

At this stage, note how each of the products (or data sources) represents and works with the data internally:

  • How often is the source updated?
  • How many times per day do the technical owners use the information in the product?
  • Are there related products used in conjunction with the data source?
  • Are there any access or security restrictions?

The answers to these questions, combined with the designation of each data source’s format, will result in a basic understanding of the adapter types required to populate the CMDB.

Step 3: Build the Information Model

An information model must be created in the CMDB to ensure that only CIs and relationships that are clearly tied to Step One’s business objectives are loaded into the CMDB. Begin by developing a comprehensive topology of the information needed to fulfil the business objectives. Add CIs as necessary, defining CI attributes and the relationships between and among CIs. This schema, or organising structure, expands and further refines the business view sketch developed in Step One. For the model to be usable in impact analysis, it should contain CIs that model actual configurations, as well as related CIs that model documented configurations.

Rules for governing the integrity of the data should also be defined and incorporated into the information model to ensure that the relevant configuration data is accurate, consistent, and accessible. These business rules, which may include constraints that specify conditions or relationships that must always be true or must always be false, help identify anomalies in source data so it can be transformed appropriately.

When the CI topology and data integrity rules are completed, the CMDB will have a filter (in the form of an empty model) that can separate the business-relevant information from other, nonessential data.

Step 4: Extract, Transform, and Load

The goal of this phase is to access and validate raw data, transferring it to the information model in the CMDB.


First, work with the technical staff to obtain, configure, or build an adapter to connect to the specific format of each data source. Be sure to identify any changes (such as added monitoring products, new or different data formats, etc.) that have occurred since the completion of Step Two. Use the newly constructed adapters to read, copy, and move the raw data into a transient data source (or staging area) for processing.


Use the business rules that were defined in Step Three to map the raw data to the information model. Keep in mind that one raw data source can become the information source for several CIs or CI types in the CMDB’s information model.

Next, perform the data transformation, using a processing engine to convert the raw data from its original state into the form required to move it from the staging area and into the CMDB. This may involve reformatting and/or cleansing the data to remove duplicates and inconsistencies.


Finally, connect adapters to the processing engine, transporting and loading the transformed data results into the CMDB.

When Step Four is concluded, the raw configuration data will have business significance because it has been filtered through the information model. Both IT and business owners can then use the CMDB to determine how systems are actually configured in the field and compare these facts to the service definitions that describe how the systems should be configured.

The careful completion of these four steps results in proper population—the most critical determinant in your CMDB’s success and the key to making it the one validated, integrated source of truth that decision makers throughout your organisation will use with confidence.

1) A Board Room View: Understanding Your CMDB Project’s ROI. Boulder: Enterprise Management Associates, Inc., July 2008
2 Matney, Chris. “CMDB Requirements: The Hidden Killer.” EMA Analyst’s Corner. June 2008.
3 10 Best-Practice Tips to Help You Succeed with Your Enterprise CMDB Project. Boulder: Enterprise Management Associates, Inc., June 2008.
4 Muirhead, Richard. “CMDB: A Journey, Not a Destination.” 18 March 2008.
5 10 Best-Practice Tips… Enterprise Management Associates, Inc.
6 Guidelines for writing detailed requirements for CMDB projects are presented in EMA’s hands-on workbook, How to Define Detailed Requirements for Your Enterprise CMDB Project (April 2008).

Brad Serbu is President of Research and Strategy, ASG Software Solutions