Guide to configuration management databases (CMDBs)

Within a CMDB, these tracked items are known as configuration items (CIs). As defined by ITIL 4, CIs are “any component that needs to be managed in order to deliver an IT service.”

In other words, your CMDB stores information on the configuration of items within an organization, including hardware, software, systems, facilities, and sometimes personnel. It is the purview of the IT organization to define which items should be tracked and how to do so. This configuration data can include relationships and interdependencies between items, the history of changes to each item, and class and attributes—such as type, owner, and importance—for each item.

According to ITIL 4 , a configuration management database (CMDB) “is used to store configuration records throughout their lifecycle and…maintain the relationships between [them].”

The goal of a CMDB is to provide an organization with the information needed to make better business decisions and run efficient ITSM processes. By centralizing all configuration information, leaders can better understand critical CIs and their relationships. CMDBs are important in impact analysis, root cause analysis, legal compliance, incident management , and change management .

As a CI, however, the power pole may not make sense. There’s no web of interdependencies to track. There’s no configuration when we’re talking about a hunk of wood. And trying to enter power poles as CIs in your CMDB may not add enough value to the system to justify the time and effort.

Now, not every asset is also a CI. For some companies, it may make sense to track assets that don’t have the configuration and dependencies that make them valuable to track as CIs. For example, a power company may track individual power poles as assets. They have financial value to the organization and knowing when they’re damaged, replaced, etc. may be worth tracking within asset management.

There are different considerations about that car within the different practices:

So, what’s the difference between those practices? Let’s use a car as an example because it could be both an asset (something of financial value to a company) and a CI (a dynamic component important to an organization’s services).

Now, when we talk about assets and CIs, IT asset management (ITAM) and configuration management , it’s easy for things to get confusing. At first glance, it seems like the terms are interchangeable, but the truth is that they may deal with some of the same components of a business, but they are concerned with different aspects of those components.

Access controls that allow you to give different access levels to different people or teams as needed and to trace changes back to their source in case of questions or incidents.

Creation of CIs and timely population of their data , supported across three different methods: manual input, integrations (API-driven, SCCM), and discovery tools that conduct automated scans of all IP addresses in an organization’s network to collect software and hardware info, effectively gathering an inventory of each physical and virtual device in the company.

Compliance features that give you detailed records and visibility for auditors into not only the current state of CIs, but also their historical changes, checks and balances, incidents, etc.

Seamless dashboards with CI metrics and analytics that make it easy to track the health of CIs, their relationships, the impact of changes, patterns that lead to incidents or problems, and the cost—in money and resources—of building and maintaining each service within an organization.

So, we understand what a CMDB does, its role in configuration management, and how it relates to and differs from asset management. But what does CMDB functionality look like on a more practical level?

At the end of the day, a CMDB should reduce complexity, prevent errors, increase security, and help ITSM practices like change and incident management run smoothly.

In problem management, a CMDB can help with root cause analysis, getting teams to the heart of a problem quicker. It can also support proactive problem management by helping teams identify assets that need upgrading to reduce service costs and unplanned downtime.

In incident management, a CMDB can help identify the changes that led to an incident and get to faster resolution. Incident records can be associated with their relevant CIs, helping teams track incidents over time alongside the assets they impact.

In change management, a CMDB can improve risk assessment by anticipating which users, systems, and other CIs might be impacted. In regulated industries, it can also aid compliance, helping teams manage controls and providing a clear audit trail.

Technology managers need CMDB data to plan, both at a high level with enterprise architecture and portfolio management and at a more detailed level with asset and capacity management.

At best, this can cause confusion between teams. At worst, it can turn into a major incident . And all that’s needed to avoid this scenario is a good CMDB.

For example, let’s say CI A’s data is housed in one department and CI B’s is in another. CI B depends on CI A in order to function properly. But when CI A’s department decides to take it offline for maintenance, they don’t have visibility into the impact they’re making on CI B.

This prevents teams from understanding important context when making decisions, which can impact risk assessment and reporting, impair decision-making, slow issue resolution, and ultimately cost the business both financially and reputationally.

The core problems that a CMDB addresses are siloed data and outdated information. Before implementing a CMDB, most organizations have data scattered across various systems with various owners, making it difficult to see a bird’s eye view of all CIs and their interdependencies and making it even harder to understand what information is and is not current.

The challenges of CMDBs

Industry statistics tell us that only 25% of organizations get meaningful value from their CMDB investments. And such a high failure rate has left the technology with a rather problematic reputation.

The good news is that the reasons for failure are preventable and tend to fall into six predictable categories:

Culture

As with anything in an organization, culture and team commitment is one of the most important factors in whether new technology and processes are successful. In a recent study by the Harvard Business Review, 93% of executives said the greatest challenge in data-driven digital transformation is people and process. That holds true for CMDB projects.

Relevancy

CMDBs are often called the “single source of truth,” which can sometimes lead to organizations trying to shoehorn all their data into one without thinking through the use cases that are relevant to their needs. 

As with any data repository, a CMDB should contain focused, useful data that supports internal processes like change management. Make sure your CMDB has a clearly defined value objective, owner, and a way to update data to reflect all changes.

Centralization

When we say a CMDB is a centralized place to view asset data, that does not mean that all asset data has to live solely in the CMDB. This common misconception can turn into a lot of work for teams as they try to move all their data into this “single source of truth.” The real best practice here is to federate data from other tools so that the most appropriate tool is used to support each use case. 

For example, it often makes more sense to keep financial data in an IT financial management (ITFM) tool and software license information with a software asset management (SAM) tool. The data can be imported and mirrored in your CMDB, even without that being its primary storage space.

Accuracy

Many organizations struggle to develop and maintain an accurate CMDB. The most common issues are discovery tools running too infrequently, an absence of automation rules, or a reliance on manual inputs. The typical answer to these challenges is event-driven discovery that augments traditional, bottom-up discovery. 

For those unfamiliar with those terms, bottom-up discovery is when assets are mapped starting with infrastructure and branching out into customer-facing CIs. Event-driven discovery is when something happens—an event within a system, a problem, etc.—that causes systems to talk to each other. Then, based on that event, the system maps the related CIs and their connections.  

Now, not every CI is discoverable. For example, your team may want to map monitors in your CMDB. Because the monitors aren’t discoverable by an automated system, they’d need to be manually input through a spreadsheet (or similar method). 

The key to accuracy is harnessing the power of both bottom-up discovery and event-driven discovery to get the clearest picture of your assets and their connections.

Process

There is a perception in some organizations that CMDBs are for modeling legacy infrastructure and software, rather than the new stack of cloud and software-defined infrastructure and the modern workflows hosted on them. 

The truth here is that we shouldn’t let the debate about semantics keep us from exploring the genuine value of tracking our CIs—legacy and modern—in a tool that gives us a bird’s eye view of our technical ecosystems.

Tools

Choosing the right tool is paramount if you want to avoid the unhappy failure statistics above. Some CMDB tools amount to little more than asset repositories—data structures fixed on legacy physical infrastructure and discovery tools that react slowly to any changes. To succeed with a CMDB, you need one that accounts for new types of assets and is capable of quick change.