What is a Configuration Management Database (CMDB)?
How do you find out the state of configurations of assets such as products, systems, and software? How can companies understand the relationship between assets and components of a system to keep track of their configurations? This is the reason why organizations implement a Configuration Management Database (CMDB).
What is a CMDB?
A CMDB is a database used to document and store information about hardware and software assets. Its purpose is to provide detailed information to IT departments about IT services, its components, and how they relate. A CMDB consists of Configurable Items (CIs) which are basically the components that make up your IT infrastructure or service delivery.
Though CMDBs are often marketed as an application or platform, CMDB is merely the database in which CI records are stored. In order to consume the information you will need an application that makes use of the data.
Why do you need a CMDB?
The main purpose of a CMDB is to support service management processes (ITSM) that are helping IT departments to improve their service delivery. A CMDB is therefore relevant for several service management processes such as incident management, change management, impact analysis, root cause analysis, reporting, and more. Some organizations extract business intelligence data from the CMDB for better knowledge sharing across the organization.
Several service processes can benefit from a CMDB. Source: CIO Wiki.
Successfully implementing a CMDB will help organizations free information, become less dependent on key people, improve efficiency and automate manual processes. Some regulations and industry standards (such as ISO27001) require information about services and IT infrastructure to be properly documented.
How to populate a CMDB
Populating a CMDB involves creating, updating, and keeping information about CIs accurate. There are many ways to populate a CMDB:
- Automatic discovery
- Import information
- Integrations
- Manual populating
Automatic discovery
Using a discovery product is a way to automate the process of keeping records in the CMDB relevant. Basically, a “discovery” scans, identifies, and inventories any IP enabled devices on a network. The information is then used to populate the CMDB. It’s fully automated but will require some time invested in configuring the IP ranges and devices that should be discovered. While being a preferred method of populating the CMDB, the discovery product must support any type of CIs to ensure full coverage. Therefore organizations often use a combination of different methods to populate the CMDB.
Import information
With information about CIs already available in various sources, a CMDB can be populated by using imports from these data sources. One example is Excel spreadsheets, in which IT organizations have been maintaining information about CIs manually. Other import formats can be XML or CSV.
Integrations
If data is already collected and stored in an existing system or CMDB, the information can be reused by integrating the database with the new CMDB. Just remember to choose which system is storing the master data so that people are updating information in the right database.
Manual populating
There is always the opportunity to populate a CMDB by manually adding records to the database. Of course, relying on a manual process will impose the risk of inaccurate data. But if there are CIs that cannot be discovered, imported or found in any other system, relying on some manual processes might be the only option.
Common challenges with a CMDB
The most obvious challenge related to a CMDB is keeping the information up to date. There might be thousands, if not millions of CIs that need to be documented. Initially, all data must be imported into the CMDB. A time-consuming process that often requires a lot of administration depending on the preferred method to populate.
Since most CMDBs are populated using discovery tools, this data must be verified using multiple data sources. According to CIO-wiki.org this is one of the biggest CMDB challenges.
Once the CMDB is implemented, three important questions arise for the organization to answer:
1. How do we keep the information relevant?
Keeping the CMDB relevant is about how the organization works with adding new CIs, updating attributes, and properly categorizing CIs in a way that is relevant for the users. If the organization has not fully thought this through, keeping the CMDB relevant will cause more frustration than joy.
2. How do we track and update changes?
IT infrastructure is always changing and since the changes are often not planned or expected, updating the attributes and relationships of CIs in a CMDB becomes a challenging task. A CMDB that is not kept up-to-date slowly becomes irrelevant and staff risk going back to the old way of working.
3. How can we make the CMDB more user friendly?
The CMDB is supposed to reflect what IT looks like. Since the CMDB is just a database containing a vast amount of CI records, the information easily becomes complex for users to consume. Making use of the data in a user-friendly UI is, therefore, key to increasing the value of a CMDB. This further requires the organization to know why data is collected, how it should be used, and by whom, so that applications can be simplified to solve specific use cases.
