Demystifying The CMDB

Promise: CMDBs offer a definitive source of information about individual components of the IT infrastructure and how they're related. IT managers will better understand how changes to the components will affect each other and the business systems that rely on them.

Players: IBM, HP, Computer Associates, and BMC all provide some species of CMDB across their own product lines. Smaller vendors such as nLayers and Relicore provide mapping and discovery tools. No entity has yet emerged to drive CMDB standards.

Prospects: The CMDB is in its infancy. There are no standard definitions of what information goes into a CMDB, no schema for structuring that information, and no standards for integrating data from disparate vendors. That said, experts say enterprises can still get benefits from small-scale CMDB deployments from a single vendor.

The Configuration Management Database (CMDB) is a simple idea with powerful repercussions for enterprise management. Based on the premise that business processes should be served by technology rather than be at its mercy, the CMDB is a central and ideally accurate source of information for all components of an enterprise architecture. The hope is that such a database will streamline network management and enable new levels of service.In theory, a CMDB is populated by information gleaned from a variety of sources, including asset management, network and systems management, and change management tools. The CMDB becomes a trusted source of configuration information for every component of the enterprise, including servers, switches, routers, and desktops. Configuration information ranges from technological data, such as IP address, disk space, OS version, and patch level, to management information, such as serial numbers and software licenses.

Once a CMDB is populated, IT managers can use it to see the relationship between the various components that serve a business application and predict how changes made to one component will affect other components and the applications they serve. This will allow IT managers to better respond to problems and better provision the architecture to support new business initiatives.

While the CMDB promises a host of benefits for the enterprise, it's also horrendously complex, lacks implementable standards, and is rife with proprietary exploitation. At present, there's no standard schema for the data that's supposed to reside in the CMDB. In addition, any CMDB implementation that aims to import and utilize data sources from disparate vendor tools will require manual integration.

ORIGINS OF THE CMDB

The notion of a CMDB emerged from the IT Infrastructure Library (ITIL), a set of IT best practices written by the British government's Office of Government Commerce. The goal of the ITIL is to re-imagine the role of the IT department in an enterprise. "Historically, the IT department has been a place where you pour money into a new technology and hope it improves productivity," says Dennis Drogseth, vice president of consulting firm Enterprise Management Associates (EMA).The ITIL movement decrees that business processes should drive technology choices rather than the other way around. ITIL documentation describes best practices around seven core processes, also known as libraries: Service Support, Service Delivery, Infrastructure Management, Security Management, Planning to Implement Service Management, the Business Perspective, and Applications Management. By following these processes, an enterprise's IT organization should become accountable to the business and support the business in a measurable way.

The CMDB is an ITIL concept. It's a trusted and authoritative source of information about the components that make up a network architecture. Each component in a CMDB is called a Configuration Item (CI). In addition to maintaining an updated account of all the CIs in a network, a CMDB also visualizes the dependencies among components.

IT managers draw on the information in that CMDB to ensure that network management and operations tasks are being conducted with accurate information. It also helps IT managers understand how management operations will affect both the architecture and the business services that depend on it.While IT managers have a host of network discovery and management tools at their disposal, these tools all operate inside specialized realms, be it the networking realm, the asset management realm, or the change management realm. Thus, the IT groups lack insight into the overall relationships and dependencies that exist among various components of the network.

A CMDB rectifies this blind spot by showing the relationships between components. "A CMDB will give you a visualization to say, 'What is the impact of this change? What is the root cause of this problem?'" says Ronni Colville, vice president of IT Operations Management at consultancy Gartner. "With that kind of information, you can start making better decisions."

CMDB PROBLEMS

In theory, a CMDB sounds like a vendor-agnostic resource that lets third-party tools populate a CMDB with information and draw on data stored there. In practice, that's not the case--at least not yet. While the ITIL describes the processes associated with a CMDB, it says nothing about just how a CMDB gets built, how various tools are meant to feed data into the CMDB, how data should be structured inside the CMDB, and how various applications are meant to use that data.

Vendors have rushed to fill that definition vacuum with their own implementations. For instance, Computer Associates created a data schema that's consistent across its own product line. This data schema populates the company's version of a CMDB. HP has been shipping a CMDB with its Service Desk that uses Web services to pull application information across HP's product portfolio. BMC Software's Atrium CMDB is shipped as a component of, or can be integrated with, eight BMC applications, including the IT Discovery Suite and the Remedy IT Service Management Suite.However, all these CMDBs are essentially proprietary extensions to the vendors' own product suites. "There's no standard in the industry for how a vendor should build the data model inside the CMDB," says Colville. "There's a huge propensity to lock into one vendor for all of this."

Brian Emerson, solutions marketing manager at BMC, says the company understands the need for interoperability. "We provide integration adaptors to external data sources, such as someone else's help desk." However, that integration will likely require professional services and manual tinkering with SDKs. At this point, there's very little integration with other products out of the box.

FEDERATION AND STANDARDS

On paper, the CMDB appears to be a central data store, but in fact vendors are pitching the notion of federation. In the federation model, various management tools maintain their own spheres of information about the network. These spheres can then be linked up as necessary to exchange data with other applications. While there may be a physical CMDB somewhere in the enterprise, it will draw on other data stores on the fly to present a virtualized repository to users and applications.

"We believe in federation of the CMDB," says Gili Raanan, founder and CEO of nLayers, which makes an automated discovery tool for application infrastructures. "There will be no single CMDB because there are so many details that a single repository makes no sense in a large environment, both for capacity reasons and because of different IT domains."Other experts agree. "The whole CMDB discussion is redefining how vendors integrate their products," says EMA's Drogseth. "It's a way of saying there's going to be this solar system of data stores that will interact."

To make federation happen, vendors need to find ways to take disparate information and transform it into a single data model. The problem is that many organizations have multiple discovery tools to glean information from the same components. A federated CMDB must prevent data duplication, as well as be able to understand that different pieces of data gathered by different tools--an IP address, patch level, a host name--all belong to the same component. This process is called reconciliation, and experts say it's critical to a successful CMDB. They also say most reconciliation engines are proprietary.

"Vendors will be much better at reconciling their own data points," says Gartner's Colville. "They know they have to integrate, but how good will they be?"

Two standards efforts have been proposed to help with reconciliation, but to little effect. The first is the Data Center Markup Language (DCML). Originally created by Opsware, the DCML is currently being developed by the Organization for the Advancement of Structured Information Standards (OASIS).

According to OASIS's DCML charter, the standard is an XML specification for representing components of the data center and information used to manage those components. The goal is to create a vendor-neutral language so that IT managers and data center management tools can exchange policy, configuration, and operating information in a reliable and standard way.However, while the DCML has several major participants, including BMC and Computer Associates, Gartner says the standard has had little acceptance in the enterprise and no use, in part because it lacks a framework to provide a visual representation of the data center components. A visual representation of interdependencies is an essential requirement for any CMDB.

The second standard is the Distributed Management Task Force (DMTF)'s Common Information Model (CIM). CIM is an object-oriented model for unifying and extending existing standards such as SNMP. CIM takes objects from the management domain and divides them into classes based on several criteria, including characteristics and features, relationships, and behaviors. Most pertinent to CMDBs, CIM includes the ability to show relationships among objects, including their dependencies.

"The DMTF is probably the most active," says Drogseth. "Most [CMDB] vendors talk about CIM."

Of course, talk doesn't necessarily translate into action. One reason is that at this point, vendors simply don't feel compelled by their customers to move toward a standardized CMDB reconciliation model.

"Customers are just trying to get a handle on what a CMDB can do," says BMC's Emerson. "They aren't shutting us out because there isn't a standard language."In the end, any real standard for CMDBs is likely to emerge from a consortium of power players in the market, including HP, Computer Associates, BMC, IBM, and Microsoft.

THINK SMALL

Enterprises that attempt to roll out a CMDB as a silver bullet for all their network management ills are likely to be disappointed. The difficulty of interoperability and the lack of standards mean a fully realized CMDB may be years away.

However, experts say enterprises can still get benefits by thinking smaller. "The way to succeed is to start with something specific and then understand the broader requirements and evolve [the CMDB] over time," says EMA's Drogseth.

For instance, the data center may be a good target for a CMDB. Many organizations struggle with application outages because of changes made to servers. A CMDB that stores essential data on all the components in the data center and maps out the interdependencies between those components can help IT managers make changes without the business coming down. Both the well-known vendors and smaller players such as nLayers and Relicore now offer solutions for the data center that include a CMDB.Of course, IT managers also have to keep in mind that they can't rely solely on software to solve their problems. "If you're going to do it, you need to make an investment that goes beyond buying software," says Drogseth. "You have to think through your priorities and processes. If you make those assessments by themselves, you'll already enjoy some benefit."

Technology Editor Andrew Conry-Murray can be reached at [email protected].