CMDB — The First Step?

Some organizations are uncertain where to start when they decide to apply ITIL good practices to their IT service management (ITSM) processes. When it comes to the CMDB1, it seems ITIL practitioners have different ideas on what to do first.

One approach says that since the CMDB is the key component of all ITSM processes, it must contain each and every CI2 to effectively support the processes. However, fully populating a CMDB is a daunting, resource-intensive task that could take months to accomplish.

Another approach says that having well-defined core ITSM processes is more critical, and that the underpinning CMDBs should be incrementally populated by the processes. Although this approach might provide for quicker process implementation, having to collect the necessary CI information on an ad hoc basis can diminish the efficiency of even the most well-defined process.

Each approach has its benefits and drawbacks. So what should you develop first—well-defined core processes, fully populated CMDBs, or both?

Chicken or Egg?

Virtually all ITSM processes refer to one or more CIs, and it's clear that CI information is a critical component of process development. What is difficult to determine is whether or not it's better to define all potential CIs that a process could reference before implementing the process.

CMDB purists say that all configuration items must be defined first for a process to be effective. Process purists argue that the extensive effort involved in predefining all CIs unnecessarily delays the implementation of the ITSM process, and a fully populated CMDB without a well-defined process has little value. This ultimately ends up in the venerable "chicken first or egg first" controversy.

For some processes, it certainly makes sense to define CIs in advance. For example, incident management would be more effective if the CIs involved in the affected service were predefined. Since the objective of incident management is to restore normal service to the user as quickly as possible, it would be inefficient to manually research and discover the CIs related to the affected service when responding to the incident.

For other processes, defining all potential CIs in advance of implementing the process would add little or no value. In these cases, the process could automatically create the CIs to populate the CMDB on an as-needed basis. This approach might be used by the Change Management process to register standard changes in a Service Catalog.

A Federated System

ITIL V3 introduced the Configuration Management System (CMS) that describes a logical, layered model containing multiple physical CMDBs rather than a single centralized physical CMDB. This federated CMDB model suggests that a process could store the CIs it manages in its own CMDB, and access CIs in the CMDBs managed by other processes. The CMS defines and controls how this aggregation is performed.

The CMS model provides flexibility for the design and implementation of ITSM processes. In the past, the single CMDB model spawned unwieldy projects that attempted to accommodate all CI types and their attributes in the initial design. This "all or nothing" approach usually included efforts to fully document every CI in the organization, which more often lead to project failure rather than success.

In V3, the CMS adds a layer of abstraction over the underlying CMDBs. This allows ITSM architects to design a logical interface to the physical CMDBs required by a specific process without fully implementing all CI types and attributes.

Without going into the details of the interface design, it should support the creation of any CI information needed or generated by the process. Of course, this requires a bit more effort to develop the interface and automate CI creation, but it's well worth it.

In this manner, organizations can incrementally develop and implement ITSM processes one at a time. As each new process is implemented, you can easily add any additional CI types and attributes needed by the new process without having to update the existing processes.

Same Coin, Different Sides

So, is a fully populated CMDB the first step in developing an ITSM process? Or, should you develop and implement a well-defined automated ITSM process with just the minimal CMDB information necessary to support it?

Perhaps the best answer is "it depends." Each organization must decide which approach best fits their objectives. And with ITIL V3, we now have clear choices for developing CMDBs.

Given the track record of past CMDB projects, it makes sense to focus on the process rather than the CMDB. As you develop additional processes, the CMS abstraction layer lets you expand the CMDB definition without affecting existing processes.

For most organizations, this iterative incremental approach might be the optimal choice for applying ITIL good practices to their ITSM processes. If you're unsure which approach is best, you can always flip a coin.

---

1 CMDB (configuration management database) is a database used to store configuration records of CIs. One or more CMDBs can be a part of a configuration management system.
2 CI (configuration item) is an asset, service component or other item that is or will be controlled by configuration management.

By Harry Hiles, HBH Technology LLC — 03 Jun 2009

---