CMDB or Configuration Database:
Know the Difference

With all vendors offering a configuration management database strategy and few offering true CMDB capability, it is critical to know the difference between a CMDB and a configuration database.

WHAT YOU NEED TO KNOW

Not all configuration repositories are configuration management databases. A CMDB is a special-case database that must have four critical functions, which distinguish the CMDB from other tools. Reconciliation will ensure the data is coalesced – avoiding duplicates and enabling matching of configuration items from different sources. Federation will bring in multiple data sources directly and by linking to sources. Mapping and visualization will enable a peer-to-peer and hierarchical view of the CIs. Synchronization will ensure the same version of the truth across integrated systems. Finally, access controls are not a new function or one of the four distinguishing functions of CMDBs, but access controls will need to be addressed differently in CMDBs than in other management tools. Access controls will ensure only the right administration changes are made to the schema and access is monitored at a CI level. Tools marketed as CMDBs that do not have all four critical functions will require significant human resources to build them in.

ANALYSIS

Every vendor claims to have a configuration management database (CMDB) or a CMDB strategy. Yet they are merely playing off Information Technology Infrastructure Library (ITIL) hype in this area and don't really have all the necessary functionality required for a true CMDB: reconciliation, federation, mapping and visualization, and synchronization. Rather, many are taking their domain-specific configuration repositories (such as for desktop or server configuration management, asset management, or help desk), adding one of these functions and calling it a CMDB.

As organizations look for ways to build a comprehensive view of all infrastructure components, individual (technology-domain-specific) configuration management data becomes the basic feed for a coalesced or centralized view that federates or links to other configuration data stores (depending on the CMDB architecture) to meet the "viewing" needs of its many consumers. The domains will maintain a much-deeper view of a component, and the CMDB will need only a certain level of depth to represent the overall service view. A key driver for CMDBs is the need for a view of how components relate so that IT can do a better job of adapting to changing business needs while ensuring that changes will not affect availability and security. Despite its core role, many organizations have relied on manual efforts and homegrown databases to maintain this type of information. The problem with this approach is human inaccuracy in the form of manual input errors or the failure to follow prescribed processes consistently; automation can reduce the human error factor with something more predictable and less risky.

Most enterprises are also trying to leverage existing tools (such as inventory/discovery databases or service desk repositories). Today almost none of the existing tools that are repositories and databases offer all of the specialized functions of a CMDB. Existing databases and repositories were not designed with a CMDB in mind, and they lack one or more of four management-related critical capabilities needed to provide desired CMDB capability: reconciliation, federation, mapping and visualization, and synchronization. In addition, a CMDB is not a store for data (such as performance data), but instead is a representation (or model) used to represent configuration items (CIs) and their interrelationships.

Reconciliation is the ability to rationalize the same instance of a CI or component that might come into the CMDB from multiple sources. For instance, one discovery tool might see a Windows server by a hostname, another might discover it by an IP address and yet another by its Media Access Control (MAC) address; reconciliation ensures that there is only one instance of this server with the right configuration data represented in the CMDB. Today this is typically done manually by comparing various data sources, which invariably results in unreliable data, or it is not done at all, which is why having this capability in a CMDB architecture is critical. The most challenging aspect of reconciliation is to be able to determine that the same instance of a component or CI coming from different sources may very well have different naming conventions (such as Word and MS Word). Reconciliation will also need to include capability that checks the relationship for integrity to ensure that the managed linkages are both semantically and actually accurate. Therefore, the CMDB will have to ensure that the reconciliation engine can determine that multiple identities are actually the same component or CI and to assist in avoiding inadvertantly changing the configuration to match the wrong source (not the trusted source). This also enables the CMDB to be the hub between different management tools.

Federation enables multiple data sources to feed some level of data or just link data stores (or link configuration repositories) into the CMDB while the individual IT domain sources continue to maintain detailed configuration information about an infrastructure component. It would be impossible to store and manage (and eventually scale) all configuration data (types) in a single CMDB. The most significant effort taken on for a CMDB is determining what data is "core" and what data should remain in local IT domain data stores or what data should be linked to (such as change records, help desk records, and so forth). The CMDB will maintain a subset of the detailed information for most components. The most important element of federation will be determining the "trusted" source. This origin of the data will be the authoritative and reliable source. Checkpoints and decisions to make modifications can be made against this data or a designated configuration data source. Federation is not just integration, as is done in tools today for discovery data. It is not just the ability to bring data into a new data store (such as integrating discovered PC and server data into an asset tool). It is the ability to bring multiple data sources into a coalesced view where the various feeds come together to represent a view with relationships across components. As uses of these tools broaden, a critical differentiator will be the ability to federate not only with a single vendor's data sources but across multiple vendor data sources.

Mapping and visualization provide the ability to illustrate logically or physically the peer-to-peer and hierarchical relationships between CIs. Like federation, this function, too, is different from how today's tools show relationships. Today's discovery tools only show parent-child relationships from a hardware-to-software perspective. A new set of tools that has emerged over the past two years offers a new type of discovery and mapping. IT service dependency mapping tools discover applications and underlying servers as well as some switching fabric to show peer-to-peer and hierarchical relationships across them, additionally enabling visualization of the direction of the relationships (such as unidirectional or bidirectional). While these tools can run as stand-alone, they are a good example of what you can expect from CMDB visualization – but the CMDB should be able to visualize all relationships across all CIs from a variety of federated data sources. In fact, several IT service dependency mapping tools have been acquired by vendors with CMDB strategies (for example, IBM acquired Collation, and Mercury acquired Appilog). They offer these tools as stand-alone dependency mapping discovery solutions and will also include them in their CMDBs when they become available. Mapping and visualization also include reporting (running a report to see what applications reside on a specific server), which in the short run will morph into more of an analytic capability ("If I make this change, what will be impacted?").

Synchronization is the ability to update the CMDB with approved changes, as well as to identify changes that are not approved. Once a baseline is established, comparisons are made against various sources. If inappropriate changes are detected, a notification is triggered to a change management workflow to alert the appropriate IT domain to investigate and potentially remediate the drifted configuration. This results in achieving the goals of closed-loop change control.

Once automated, a CMDB will, in a (near) real-time fashion, enable the ability to provide input into the risk and impact analysis of a planned change via a view of the interdependencies of one IT component with respect to another (such as helping to understand the impact of a vulnerability in one application on all of its associated components). This capability will also be able to help IT organizations quickly identify when a system is not in its desired state, although the CMDB would be working in conjunction with its federated data sources to achieve this. A CMDB is a database (like other tools that have databases), but it is a "special case" database with the unique combination of the functions cited above. Each capability alone is necessary but definitely not sufficient to ensure expected vs. discovered configuration information, which generally comes from configuration databases or repositories. Today many vendors offer one and sometimes even two of these functions, but no vendor today has demonstrated all of them in a best-of-breed, tightly integrated offering.

Another important function is access controls. Access controls exist in all management tools and offer a variety of functions to ensure the right people make the right changes to the right components. This is often done with role-based administration functionality, but because CMDBs will be a culmination of many sources and stakeholders, it will be even more crucial to ensure the right people have access to making changes not only to data but to the CMDB model.

Access controls ensure that only the appropriate roles (humans, as well as tools and systems) have read and write access to the information. This is a bigger requirement than one might think at first glance. Because of the federated nature of the information, updates to the CMDB may not only update the central store, but also likely cascade to the trusted source or vice versa and report on the discrepancies. Most of the CMDB vendors that have "architected" the previous functions (reconciliation, federation, mapping and visualization, and synchronization) do have some extended capability for access controls.

Build or buy? Because the vendor market is just beginning to surface, some enterprises have opted to build their own CMDBs. Some enterprises that have mature processes cannot wait for the tools to mature to meet their needs, and some feel that their needs are unique to their specific business environment. Some of these enterprises are calling these homegrown databases CMDBs (in name only to match the initiative), but they are more centralized repositories for single-focus domains (such as one for network infrastructure, one for platforms, and so forth). Others are building out their existing service desk solutions to include configuration data as they follow ITIL's processes and CMDB definition – although ITIL does not prescribe how to implement a CMDB. But in all cases that we have heard thus far from our client base, each requires significant resources for customization and has limited capability for reconciliation and mapping relationships.

Does a configuration database have value? Absolutely. Every IT domain that maintains, manages, or monitors an infrastructure component or set of components relies on a data store to contain the information that tracks changes to the component. The role of that database is critical to daily decisions that are made against that information. Additionally, some CI sources will be spread across multiple repositories. A discovery/inventory database maintains information that is relative to the components that are managed by that tool, but the tool doesn't integrate or federate other discovery tools to be able to tie together or map relationships across components. Service desk tools maintain a repository of problem and incident records and can tie together some discovery data, but they don't reconcile multiple instances of the same component and can't maintain the peer-to-peer or hierarchical relationships of the discovered items. However, they can maintain the relationships across incidents and the discovered items. Do these examples demonstrate a value in having one or two functions? Definitely, but a CMDB must be able to do all four. Most vendors today offer a repository with varying capability to federate and different approaches to reconciliation.

The business case justification for a CMDB is usually tied to high-visibility projects, such as security auditing, change management, process re-engineering (for example, ITIL), improving availability of mission-critical systems, and compliance initiatives. The IT organization is challenged to correlate this data to provide better service management to the business and a more cohesive view of the IT infrastructure. A practical approach for a successful implementation of a CMDB will require a federated data model with a consistent view that receives at least some data from element-specific tools (for example, desktop configuration management, server configuration management, network management and storage management). However, many other feeds are required to build a comprehensive map of the entire infrastructure (for example, purchasing systems and asset management). The driver for this "renewed" focus on an integrated view is that IT must define services from end-user devices to servers, networks, storage, applications and data to better serve the ever-changing and dynamic nature of business needs.

Gartner RAS Core Research Note G00137125, Ronni J. Colville, 13 March 2006.