What is a configuration management database (CMDB)?

Characteristics of a CMDB

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? 

The core functional characteristics of a CMDB are:

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.

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. 

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.  

Support for federated data sets, including normalization and reconciliation of CIs and their data.  

IT service mapping (typically a graphical illustration of relationships and dependencies).  

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.

CMDB benefits

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. 

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. 

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. 

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.

Forrester identifies three use cases where a CMDB is vitally important today:

Planning

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.

Accounting

IT finance requires records of applications or service codes in order to allocate billing statements and properly manage business finances.

Operating

A CMDB improves a number of core ITSM practices, including change management, incident management, and problem management. 

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.

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 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. 

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.

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.

Choosing what to manage in your CMDB

There is no one-size-fits-all answer to which CIs you should manage within your CMDB. Each organization’s use cases and goals should determine the level of breadth and depth that makes sense for their CMDB set-up. In general, it makes sense to start high-level and get the services right and then only go wider or deeper where needed to meet your organizational goals.

That said, CIs can be broadly grouped as technical or non-technical entities. 

Technical entities include business services, technical services, applications, software, databases, containers, virtual machines, operating systems, hardware, networks, ports, etc. 

Non-technical entities can also be modeled in your CMDB if you need to represent them as either dependent or impacted by other assets in your IT service mapping. Non-technical entities may include users, customers, organizations, locations, service agreements, documents, etc. 

Lastly, cloud services should be taken into consideration in the design of a CMDB model. Both SaaS offerings (e.g. Google apps, Dropbox, Salesforce, etc.) and IaaS offerings (e.g. DigitalOcean, Linode, Rackspace, Amazon Web Services, etc.) can be represented as CIs as needed.