ITSM for high-velocity teams
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.”
5 IT asset management steps to get you started
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:
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 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.
Atlassian's IT asset and service configuration management handbook
Your step-by-step guide to asset and configuration management in Jira Service Management.
Get the handbookJira-native asset and configuration management
Assets in Jira Service Management offers visibility into dependencies so you can manage assets and configuration items (CIs), quickly troubleshoot incidents, and minimize the risk of changes.
Read this article