Credit: Dreamstime
A configuration management database (CMDB) is a data repository that stores information about all hardware and software assets in your IT environment.
This critical component of the ITIL framework allows for efficient oversight and management of organisational assets, known as configuration items (CI), and delivers greater insight into how they relate to one other across the company.
Assets logged in a CMDB include products, facilities, software, systems, and even key stakeholders in a process. As a centralised log of all the business’ assets, a CMDB can assist in making important business decisions and in running more efficient ITSM processes by providing an organised, up-to-date catalog of asset configurations and relationships.
A CMDB can help organisations identify and resolve problems, respond more quickly to incidents, and improve budget forecasting, decision-making, and the deployment of network components.
CMDBs and asset management
While a CMDB combines aspects of IT asset management (ITAM) and configuration management, its purpose and use differ from that of an ITAM register. An ITAM data store focuses more on the lifecycle of individual assets and pertinent data such as where they’re located and who owns each asset.
A CMDB goes a step further, focusing more on managing assets and how they interact with one another in the IT infrastructure. But the two can be integrated, and a CMDB can assist with ITAM to reduce risks and gather more data on assets and related incident management.
For example, if there’s an asset in an ITAM register that isn’t in the CMDB, that can be discovered in a quick automated scan, enabling IT leaders to quickly determine whether it is a rogue asset or something missing from the CMDB.
CMDB benefits and challenges
By keeping an organisation on top of its IT environment, a CMDB can reduce downtime and costs, improve analysis, and help meet regulatory compliance standards. A CMDB can also keep records of service codes and billing for financial analysis and perform root cause analysis to resolve CI issues. Maintaining a CMDB, however, is not without its challenges.
For example, it can be difficult to keep a CMDB accurate and up-to-date, and there’s always the chance that incorrect data could lead to misguided decision-making. It also requires a lot of staff time and resources to collect and maintain data in a CMDB. With so many assets to include, a CMDB can also be overwhelming to manage.
CMDB for compliance and metrics
CMDBs can also be useful for business intelligence, software and hardware builds, inventory, incident management, impact analysis, root cause analysis, and change management. The typical CMDB involves a dashboard that can quickly deliver insights into CI metrics and analytics.
These dashboards enable businesses to track how CIs are performing, especially after changes are made to the asset. It can also give a better picture of the amount of money and resources that go into the creation and maintenance of all the services in the organisation.
CMDBs are also useful for maintaining compliance measures for auditing given that it logs all the changes made to a CI over time and any problems or issues. Assets can typically be input manually, through digital integrations and automated tools that scan the IP addresses to collect data on software and hardware. Through a CMDB, organisations can also manage access controls, IT service mapping, and the creation of federated datasets.
Configuration item types
A configuration item type (or CI type) is an ITIL term that describes all the data of the elements or items an enterprise wants to store within the database.
At the most basic level, all networks, software, hardware, and storage CI types are stored and tracked in a CMDB; as a company grows, it may choose to add more CI types to the CMDB. These may include people, markets, products, and third-party partners and vendors. The more assets that are tracked, the more information and insight organisations can have for knowledge management purposes.
The data included in a CMDB is important, and the goal is for it to be as accurate as possible. To ensure the highest accuracy, all owners and stakeholders for a CI should be involved in reviewing the data to ensure that it is accurate and consistent when added to the CMDB.
Keeping the CMDB updated is difficult because of the overwhelming number of assets it might track; as CIs are introduced, updated, reconfigured, retired, or merged with other assets, all of that data needs to be updated and tracked in the CMDB as well.
The most common CI types include:
- Hardware
- Software
- Applications
- Communications and networks
- Devices
- Services
- Location
- Documentation
- People (including staff and contractors)
Common tracked asset relations include:
- Incidents
- Issues
- Deployments
- Changes
- Updates and upgrades
- Configurations
- User control access
Schematic representations of the CMDB
Database schemas are visual representations of data that is stored in the organisation’s database. There are two common database schemas for a CMDB: a relational data model and a semantic data model.
The relational data model is based on first-order predicate logic presented in an ordered sequence that can’t be modified while the program is running, also referred to as a “tuple.” In this model, CIs are connected by unique “keys” that link the assets together and provide specific answers to user queries via retrieval procedures.
The semantic data model relies more on the resource description framework, which is a metadata data model that uses a subject-predicate-object approach, often referred to as “triples.” This model maps the relationship between several assets through the use of relationship descriptors to offer better context into the relationship between assets.
