Understanding the Configuration Management Database (CMDB) and its core functions is a critical aspect of service management. The CMDB forms the hub of numerous service management practices and provides a means of correlation needed to deliver business services successfully.
The CMDB Defined
In the most simplistic terms, the Configuration Management Database (CMDB) is a database containing information about the devices and applications that deliver services in an enterprise. This includes all hardware, operating systems, software, and applications, network gear, servers and storage, virtual machines and containers, including the facilities needed to store such equipment like racks and power. There is no limit to the items that can be stored in this database, so documentation, plans, and logical information may be stored as well. The aspects of the CMDB that turn this collection of data into a configuration management database, however, are the information about the physical attributes of the items and the relationship between items, both of which enable lights-out data center operations and planning.
Other terms relating to the CMDB include:
- A Configuration Item (CI) is any item whose data is stored in the CMDB, the component or record itself
- The term attributes typically refers to the configuration of the device: the software version, or for physical devices, the memory, CPU type, storage, etc.
- Relationship in terms of the CMDB defines how items are used together. For example, an application may be “hosted by” a server. The relative time “hosted by” defines the relationship between the two CIs.
- Service Mapping refers to the activity of identifying all components of a business service or application and mapping their relationship to that service. After discovering CI attributes, this is the most critical aspect of the CMDB as it is the activity that enables the correlation capabilities that enable the CMDB to assist organizations in understanding the impact of a failure or the risk of a change.
Purpose of the CMDB
The primary purpose of the CMDB is to provide the data IT needs to support service management practices. For example, with Incident and Event Management, the CMDB provides information about the CIs that can be causing a reported issue or which services might be impacted by an issue detected by monitoring systems. The change enablement practice relies on CMDB data to determine risk.
Putting a modern spin on things, the CMDB, along with historical data in service management platforms, fuels predictive analytics capabilities supported by artificial intelligence by being the hub that ties historical information from event, incident, problem and change records together. This allows artificial intelligence to analyze the data these records contain to assist with proactive activities and risk management.2
Essentially, the purpose of the CMDB is to provide this level of information to the other Service Management practices. From the first iteration of ITIL®, the CMDB was central to the success of a service management implementation. Still, many have shied away from building the CMDB due to the difficulty of building and maintaining the data, a problem that is solved with today’s discovery and service mapping tools.
Determining What to Include in the CMDB
Everything! A case can be made for including every device in the enterprise in the CMDB. Collective wisdom focuses on infrastructure, and that is certainly a place to start, but repetitive issues also occur at the personal device level, software, and patch level. Thus, it’s important to prioritize the approach to building the CMDB:
- Begin with discovering all devices, components in data centers
- Build the relationships between these components and critical services (service mapping)
- Expand service mapping to include less critical services
- Expand to include a level of understanding of hosted services, at least an understanding of which providers support a particular service
- As soon as practical, move to the desktop level:
- Intermittent issues can often be traced to differences at the workstation level and the configuration, patches installed at the desktop
- While it may not be practical for all organizations to get to this level, it may be necessary for some
- When ready, include the physical plant information that enables data center capacity planning.
There is also the guidance that indicates practice documentation and plans, as well as technical documentation, should be included in the CMDB. As with all guidance, organizations should determine for themselves whether they will handle these items as part of the CMDB or within knowledge management. The more critical aspect of this is that there should be a single repository for such documentation.
The Difference Between the CMDB and IT Asset Management
IT Asset Management is a financial discipline, so the main difference between the CMDB and the Asset Management Database (AMDB) is the view of the data contained within them. Asset management is concerned with understanding the financial value of assets owned by an organization, so essentially, every component that can be discovered or tracked within an enterprise that has financial value is an asset and should be included in the AMDB. But the AMDB is simply a database of assets and their value and other financial information. It contains no relationships that enable one to determine the business value produced by the use of the assets. Assets need to be managed and understood, but adding the attribute and relationship information to an asset are the activities that turn it into a configuration item, providing value beyond understanding the assets’ financial value.
Asset management is important to the financial management of the organization, but the CMDB enables an organization to go beyond the tangible value of an asset to an understanding of the total cost of delivering a service. By understanding and tracking the cost of an asset as well as its maintenance and by being able to track all asset maintenance costs up to the level of the service they support, an organization, and derive the total cost of ownership of a service. Compared against the revenue generated by that service (or general value of internally used services), the true value of the service can be evaluated.
Thus, when comparing asset management to configuration management, asset management enables an organization to measure the value of a service, while the CMDB enables an organization to operate and maintain that service.
(See also, “The role of your CMDB in effective IT management”)
Why is the CMDB So Important
You cannot manage what you cannot see. The Configuration Management Database enables organizations to manage their infrastructure in accordance with its criticality. A CI has no business value on its own; its value comes from the use of the services it supports. Therefore, without a CMDB, every incident is critical, causing fire drills and stretching staff to address any/all failures with the same level of importance. With a CMDB, issues can be prioritized based on the use of the failed CI, and higher attention can be given to CIs that affect business-critical services.
The CMDB is also critical as a risk mitigation tool. When planning changes, it’s vital to understand the potential impact of the change should it fail and/or the services that will actually be impacted. This enables risk management activities to take place before the change is executed, thus mitigating the risk. It also allows IT to communicate proposed changes to the appropriate business stakeholders, determined by using the CMDB to identify the services and then the service users/consumers.
The CMDB also provides value in being able to identify the cost of operation of a service. By identifying the components needed to operate a service, tracking costs of maintaining, and making changes to these components, the organization can derive a total cost of ownership (TCO) for the service. This enables an organization to evaluate whether services they use are worth their cost: essentially, the CMDB help determine the true value of a business service in an objective manner.
(See also, “Successful CMDB implementation in six steps”)
Virima features are easy to use and configure, and designed to work well with each other. They also produce useful, actionable reports about your IT environment, for IT managers and business decision makers. These features can help you and your IT management team achieve and sustain maximum business value of your CMDB, today and tomorrow.