Vendors promise that configuration-management databases will provide a single source of truth for IT infrastructures. No longer will compartmentalized functions blind us to the complexity that leads to outages of critical business services. In fact, they claim, CMDBs will automate many of the routine data-center tasks that bog down administrators.

At their best, CMDB offerings will provide a unified view of network assets, map device and application dependencies, and let us manage services, not machines. All this should yield increased productivity, less downtime, automation of tasks, and a platform for a brave new generation of network and systems management.

Sound too good to be true? It probably is. The biggest problem is that many vendors that profess to have customers' best interests at heart will enrich themselves by holding users hostage with their so-called integrated CMDB platforms. Sure, software companies are in business to make money, and lock-in is a time-tested method for generating repeat sales. That doesn't mean we have to like it.

Moreover, most evangelizers gloss over the fact that any IT organization setting up camp around a CMDB will face a host of difficulties. Atop the list is the pain of federating disparate IT data repositories and reconciling information stored in incompatible schemas. Vendors, of course, have a solution: Buy more software—in this case, a management suite architected around the CMDB.

Vendors are taking two main architectural approaches to configuration management. Some offer stand-alone products, which let IT roll them out without having to buy another application, such as an asset-management system. But don't confuse stand-alone with independent. A stand-alone database will integrate more successfully with products from the vendor's own family than with third-party systems.

Other vendors embed the CMDB in one or more management-suite components, such as a service-desk application. Enterprises that use multiple applications in the suite will find that those applications play well together, but the business will still struggle to integrate third-party data stores. Several vendors have offerings in both categories.

If you're committed to maintaining heterogeneous toolsets, then for the time being, you'll have to put your faith in a pre-standard working group that pays lip service to the notion of interoperability without inviting all stakeholders to the table.



Mission: Control
IT-management vendors know that a CMDB is key to influencing the purchase of management software. "If you own the CMDB, you'll own the management infrastructure," says Arlen Beylerian, director of product management for CA's Business Service Optimization unit.

What gives the systems this power? Configuration management—having a clear picture of assets and their relationships—is the bedrock of IT. It underpins essential tasks, such as change management and root-cause analysis, as well as things like data-center automation. All this information is then available for IT processes, including help-desk and change management and the monitoring of internal service-level agreements.

A well-designed CMDB should access information in many data repositories. The CMDB stores limited information about assets—say, a server's name and the applications and services with which it's associated. More detailed information will reside in other data stores, such as an asset-management app or discovery tool. Depending on the task or process you want to perform, the CMDB fetches additional information by reaching out to the appropriate data store, including other CMDBs.

A CMDB also must reconcile information gathered from disparate data repositories. And this reconciliation must match up the different schemas used by third-party tools to describe assets and their attributes. The patch-management agent might describe a server by name, for example, while the help-desk agent uses Media Access Control address. Reconciliation ensures the CMDB understands when different tools refer to the same asset.

On paper, federation and reconciliation are easy to describe. In reality, they can be devilishly complex to accomplish, often involving custom integration, software developers' kits, published APIs from vendors, or some form of Web service. CMDBs include reconciliation engines to integrate third-party data, but these still require significant up-front effort by IT to create a well-defined naming schema for assets and their attributes.

Vendors promise to remove some of this complexity if we buy into a single management suite. BMC claims tight integration among its Atrium CMDB and other products—a click of a button will call relevant information from, for instance, Remedy or the BMC Configuration Manager portfolio, and deliver it into the CMDB user interface.

Products from Altiris, CA, and Opsware have similar capabilities. CA's CMDB configuration-item viewer shows up as a tab in its Unicenter Service Desk application and federates with other CA products, such as Unicenter Network and Systems Management. Other vendors are working to integrate CMDBs as centerpieces of broader management suites.

EMC offers pre-built adapters to integrate and reconcile information from third-party products, including those from BMC, Hewlett-Packard, IBM Tivoli, and Managed Objects. Like CA, however, EMC says its professional services team should be on hand to help get the adapters up and running. HP uses a federation and reconciliation technology acquired from Peregrine, called ConnectIT, that maps fields from one data source to another.

Organizations that prize diversity won't find an open standard anytime soon. Only a limited subset of vendors is participating in the creation of a draft specification to integrate information from disparate resources. The project is being driven by the CMDB Federation Working Group, launched in April 2006. When completed, the spec will be submitted to a standards body.

To avoid reinventing the wheel, the group will look to incorporate the work of existing standards where possible, says Mark Johnson, a senior programmer at IBM and member of the working group. For instance, CIM provides a schema to define IT elements as common objects.

All this reuse sounds good, but the consortium is an exclusive club. Membership was expanded from the original founders—BMC, Fujitsu, Hewlett-Packard, and IBM—to include CA and Microsoft. But other players, such as EMC and Managed Objects, have been rebuffed. It's also not clear just when a specification will emerge. The original goal was December 2006, but the release of a draft has been pushed out to an unspecified date this year.

For now, the federation working group lets major vendors pay lip service to the notion of interoperability standards. It also gives them a significant time period—at least two or three years before standards-based products hit the market—in which to corral customers with the promise of simple, in-suite integration.

A lack of standards hasn't stopped enterprises from deploying CMDBs, Johnson observes. One reason is that they tend to start small, with a subset of IT assets and CMDBs populated with rudimentary data. "They'll grow it over time as products and processes mature," he says.

Overall, the CMDB market is in its infancy, but healthy growth is projected. Forrester Research estimates that the number of installations will go from around 600 today to more than 4,000 in the next five years.

Until a standard emerges, however, IT will have to put some effort into linking disparate data stores. And once links are established, upgrading one product or another will require caution, as changes could break the integration. Such issues will surely increase operating expenses over time.



Sign Me Up
With the potential to dominate a customer's IT-management purchases, it's no wonder IT vendors are rallying around the CMDB banner. Last year saw a flurry of acquisitions designed to beef up vendors' offerings or get them into the market. HP purchased Mercury, CA bought Cendura, Symantec snapped up Relicore, and EMC added nLayers to its stable. And in late 2005, IBM picked up a company called Collation. The common thread among these acquisitions: application-dependency mapping.

A key technology for CMDBs, app-dependency mapping identifies and creates a visual map of the devices that support an application, including routers, servers, and switches. It also looks at software components and code dependencies on which an application relies, as well as network configurations like routing tables and port assignments that let apps travel across an enterprise.

The connections among the underlying devices that support an application have considerable effect on uptime. But given the network complexity, it's difficult for IT to have a clear picture of dependencies among the application infrastructure. By providing a map, a CMDB will help IT better understand the impact of potential changes and diagnose app failures.

Some vendors, including BMC, Managed Objects, and Opsware, built their own app-dependency mapping technologies. Altiris says it plans to make such mapping available later this year. Tideway Systems is the last of the stand-alone app-dependency mapping companies.

The acquisitions derby demonstrates that the CMDB market is in flux. Some vendors still have work ahead of them to incorporate the CMDB as the foundation for their IT-management suites. As mentioned, two main go-to-market strategies have emerged—both designed to influence IT's future purchase decisions. Vendors that offer stand-alone CMDBs generally position them as an overlay technology that can be brought into an organization and fitted atop a variety of third-party data sources.

Stand-alone products are aimed at IT shops looking to implement a CMDB without necessarily buying into a vendor's entire product line. That said, the stand-alone CMDB will integrate more easily with other components in a vendor's suite, greasing the skids for future product sales.



Path To Integration
The second approach embeds the CMDB in one or more products in a suite. A help-desk application will also include a CMDB, for example. For companies that have a management vendor of choice, this approach provides the fastest path to integration because other products in the suite will share the data schema, easing reconciliation and invoking other applications without the need to create connections. On the downside, third-party federation will take additional effort.

Microsoft is also expanding its IT-management role under a new brand—System Center—which will be a portfolio of systems-management products based around Microsoft extensions to the IT Infrastructure Library (ITIL). The goal is to provide better integration of Microsoft management products.

The company says existing management products will be re-branded under the System Center name. For instance, SMS will be renamed System Center Configuration Manager. In addition, a new product, code-named Service Desk, is slated for launch under the System Center umbrella; it will include a CMDB to support change and configuration management. A beta version of Service Desk is scheduled for release in the first half of this year.

Microsoft's move to enter the market is significant, but expect little detrimental effect on the major vendors in this market. In fact, Redmond could even help them by exposing midmarket and smaller customers to the CMDB concept. Microsoft's management products tend to focus on the Windows OS and Microsoft applications. The company will have to work hard to establish its credibility as an all-purpose IT-management provider. That said, other vendors will ensure that adapters or connectors to pull data from Service Desk into their own CMDB platforms are readily available.

As the market grows, vendors are differentiating themselves through the capabilities that can be built on top of a CMDB—for example, ensuring that changes are associated with a work order. BMC has a function to compare the state of a CI in its database to actual state based on the latest discovery of that CI. If there's a discrepancy, the CMDB will look for a change request. If an approved request exists, the CMDB will update the CI attribute; if not, it can trigger an incident or alert.

Managed Objects has a similar feature, in which the CMDB reconciles infrastructure changes with trouble tickets in a Remedy system. If a change doesn't have an associated ticket, the CMDB can request an investigation.

Through a partnership with mValent, HP's Universal CMDB also can compare existing configuration settings to spot divergence from an ideal state. The HP-mValent partnership provides automated remediation as well.

Once the dust settles and as CMDBs mature, IT can expect to delve into more analytics around real-time monitoring and analysis of all the components of a business service, deep root-cause analysis, and advanced warning of emerging problems.

If you're looking to CMDB, identify how and where IT practices need to change, and evaluate existing CMDB offerings. Then, place your bets on the ability of your provider to meet federation and data-reconciliation needs and deliver future apps that will live up to the promise of the CMDB. If you choose well, you could strike a mother lode of productivity realized by automating routine tasks.

Andrew Conry-Murray is business technology editor at Network Computing, a sister publication of Optimize.