Guide to configuration management databases (CMDBs)
According to ITIL 4, a configuration management database (CMDB) “is used to store configuration records throughout their lifecycle and...maintain the relationships between [them].”
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.
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.”
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.
IT asset management (ITAM) vs. configuration management
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.
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).
There are different considerations about that car within the different practices:
ITAM considerations Configuration management considerations
When did you buy the car? What oil type is being used?
From which dealer? How often is the oil being checked?
What was the price? How many miles until the next oil change is due?
What’s the make, model, and trim? What is the engine configuration?
What is depreciation? Has it been modified?
What does the warranty cover? - -
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.
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.
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.
The benefits of a CMDB
The core problems that 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 contexts 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 are 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 the 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’ 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 were 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.
Unlike legacy CMDB’s, Insight for Jira Service Management offers a flexible and open data structure so you can manage all your resources.