CMDB brings order to chaos in IT operations

Enterprise Networks & Servers, Sep 2005 by Coyne, Pierre

By now, most IT managers are familiar with ITIL, the IT Infrastructure Library set of best practices that promises to lead IT operations to a Mecca of efficiency and effectiveness. Driven by the need to be compliant with new regulations such as Sarbanes-Oxley, as well as a general mental shift that is mobilizing organizations to directly map critical business services to IT, ITIL standards offer better control of services that affect a company's bottom line.

At the heart of the ITIL's recommendations is the notion of a CMDB - a Configuration Management Database - that could be the key to taking IT operations from chaos to order. There has been a whirlwind of attention paid to CMDBs over the past year, elevating their stature and priority within enterprises. As defined by ITIL, a CMDB contains all relevant ' details of each configuration item (CI) and the important relationships between them. A CI can be any IT asset, including an application, server, router, switch, firewall, etc. Further, the CMDB is likely to be based upon database technology that provides flexible and powerful interrogation facilities. Other than those two indicators, the ITIL does not specifically define how the CMDB should be undertaken.

Centralized or distributed?

Most companies agree upon the importance of a CMDB, but many differ on how to implement one. Boiled down for the sake of simplicity, two fundamental approaches could be taken: a centralized data approach, where all CI details are stored in a single database; and a distributed data approach, where data resides in individual point tools and is accessed to support the various ITIL processes.

According to Thomas Mendel, an analyst at Forrester Research, the term "CMDB" is a complete misnomer. "No vendor is capable of developing a single database that holds all the relevant information in the required format at the same time and that can scale to the needs of larger corporations," he said.

The vendor community, as well as many large enterprises that are undertaking the challenge of developing their own central CMDBs in-house, overwhelmingly echo this thought on the centralized approach.

Collation, maker of application infrastructure mapping software, is regularly involved in CMDB projects, serving as the trusted data source for application configuration information.

For any CMDB project to be successful, it requires simple and fast integration. Enterprises cannot afford to spend several years on a single CMDB undertaking, company executives have said.

One of the inherent problems with a central CMDB approach is the overwhelming number of data sources that hold relevant configuration item details. Enterprises have a multitude of distributed data stores, often owned by different technology silos or lines of business. More often than not, these data tribes are reluctant to undertake the complex and time consuming process of implementing a new data schema. To complicate matters, many CMDB vendors recommend a single vendor approach that looks to replace and standardize on their own tools. The learning curve, implementation costs and workflow issues make this approach highly disruptive to day-to-day operations that can seriously affect ongoing business-facing objectives.

Acquisitions and mergers and an increased mix of legacy and next-generation technologies have created highly complex service infrastructures. Imagine the process of defining the correct subset of data from across the many data tribes, integrating those tools into a common schema, and then replicating this effort to support the range of business critical services. The volume of data that can be stored quickly surpasses the ability of any one database to store and maintain.

Accurate information is necessary in facilitating business and operational decisions. And, with a central approach, data is imported on a scheduled basis. As a result, configuration details can quickly become out of date, affecting the accuracy of automated analysis that supports dependant processes and functions such as incident, configuration and change management, service impact and root cause analysis.

Virtual CMDB approach

No question, the CMDB seems to create almost as many problems as it solves. But before we throw out the baby with the bath water, let's look at where the market is today and where it is going. Many widely known vendors such as CA, BMC and HP have begun to partner with third-party, best-of-breed point solutions vendors for key pieces of the puzzle, such as application discovery and service modeling, recognizing that no CMDB can be the sole source of all data. Because of this, a distributed approach is preferred. Admittedly, this does not address all possible sources of data, nor does it eradicate the need for mapping schemas across the broader set of information sources. This does, however, alleviate at least some of the replacement issues and provides a broader set of options to enterprises.

The argument can be made that even a federated approach that leverages third-party data sources and stores some of this information in a single vendor CMDB database smells much the same as the aforementioned central CMDB approach.