10 Tips for a Successful CMDB Project

The ability to understand relationships and dependencies across IT components, applications and services has long been desirable for IT organizations and it is the promise of configuration management database (CMDB) projects. The accuracy of data that application dependency mapping tools provide, in combination with the need for higher quality configuration data to improve ITIL processes of incident, problem and change, are part of a collection of reasons why CMDBs grew so explosively over the last 12-18 months.

The catalyst for CMDB projects is simple and the benefits are a tangible reality. If IT understands infrastructure relationships and dependencies they are better able to control change and manage the impact of change when it does occur. Patch management is a good case in point. A recent Computerworld survey found that two-thirds of Oracle DBA’s don’t apply security patches, primarily because they can’t understand the impact installing a patch will have on the database service.

The model of information about IT infrastructure components that a CMDB provides enables IT to understand the interdependencies about components in the context of the service. The DBA in the paragraph above for example, can see a holistic service view of the database application prior to installing a patch. This enables the DBA to understand the business impact a patch may have on other IT components and by extension, the service and take measures to prevent any adverse effects prior to implementation.

While the improvement to IT service quality in this anecdote is highly desirable, it understates the magnitude of a CMDB’s value proposition: to provide a more flexible, agile and resilient IT infrastructure that is truly aligned with business objectives. The ability to control change and manage impact means IT can respond quickly and as a strategic partner to a number of business demands, including the following:

• Consolidate and integrate new IT infrastructure following a merger or acquisition.
• Quickly provision IT services to a new office in an emerging market.
• Rapidly implement a new web service in response to customer demand.

The business case for a CMDB project is compelling, however the implementation can be a bit more challenging. To that end, below are 10 tips for a successful CMDB:

1. The 4 “Ps”

A good chef knows that cooking up something appetizing is a combination of culinary skill, a time-tested recipe and fine ingredients. The best chef with the perfect recipe cannot even hope for a delicious outcome if the ingredients are lacking. Likewise a CMDB is about the ingredients or as ITIL says people, process, products and providers. A CMDB implementation requires organizational buy-in, a proven methodology for implementation and best-of-breed technology.

2. It’s what you do with the data
Don’t spend all your time defining the CMDB instead give it a purpose. It’s easy to fall into the habit of parsing words and arguing semantics. However, the point of a CMDB is to improve service quality. If IT folks can clearly describe what it intends to do with the data in the CMDB, then they have gone a long way to defining its purpose and understanding what is actionable information as opposed to merely data. This purpose will guide the thinking and logic throughout the projects, for example, what should, or should not be included in the CMDB.

3. Data quality over quantity

A successful CMDB is not contingent on data it’s contingent on the right data. Be sure to identify the relevant data and proper process for accessing it. A CMDB should tie together carefully selected silos of information that model a service in its entirety. This makes what was mere data more accessible and meaningful, and in turn, transforms data into the information required to control change and manage the impact of change.

4. Don’t get hung up on a database
That a CMDB is called a “database” is a bit of a misnomer and focuses staff into thinking about change or asset management since the term connotes the idea of a traditional relational database. This can set unrealistic expectations that derail a project before it even gets started. For example, what might begin as a broad-based project with lofty goals winds up as an asset management project.

A principle reason the CMDB disguises itself on the pages of an asset management RFP is because it’s a high-profile buzzword that’s easier to justify. However asset management is more akin to an inventory audit, while a CMDB is about relationships among physical or logical items that comprise the service IT delivers to the business. More importantly, it’s about the impact a break in those relationships has upon users. Asset management is just one of many important data sources in a federated and heterogeneous IT infrastructure.