A Configuration Management Database, or CMDB, is no ordinary data repository. Rather, it plays a very crucial role in various IT management disciplines such as IT Service Management (ITSM) and IT Asset Management (ITAM).
What Is Configuration Management Database (CMDB)?
A CMDB or Configuration Management Database is a data repository primarily used in configuration management, a key process in the ITIL (Information Technology Infrastructure Library) framework whose main functions include discovering, controlling, and keeping track of relationships between IT assets and their individual configurations. Perhaps the best way to appreciate the value of a CMDB is to review the essence and purpose of configuration management.
In order for various ITIL initiatives such as change, incident, problem, availability, and release/deployment management to succeed in aligning IT with business needs, the decisions involved in carrying out these processes should be based on accurate and current information. This is where configuration management comes into play.
Configuration management practices provide the necessary information not only about the assets in question but also their configurations as well as their relationships with other assets. This information can make system administrators, IT managers, and application managers better at resolving problems, responding to incidents, deploying network components, planning strategies, making budgetary forecasts, arriving at decisions, and so on.
For example, you can be more efficient in troubleshooting a network disruption affecting all workstations in a particular department if you knew which routers and servers those machines are connected to. Or you can prevent a potential malware outbreak if you tracked the versions of each desktop’s operating system and, in turn, determine which ones needed patching.
How Does a CMDB Work?
All that asset configuration data and relationships, have to be stored somewhere. In most cases (and ideally), that ‘somewhere’ would be a CMDB. A CMDB mainly stores the following kinds of information:
- Assets, which are known as configuration items or CIs
- The relationships/dependencies of CIs with other CIs and other related entities
- Other configuration data
There are different types of CIs, including, hardware, software, documentation, and even staff and vendors, to mention a few. The relationships, on the other hand, may include CI relationships associated with incidents, issues, changes, deployments, and many others.
Before a CMDB can be of any use, it must be populated with data. This is usually carried out through a combination of manual and automated methods. Although data accuracy can’t be 100%, the objective must be to achieve the highest level of accuracy possible. Otherwise, the CMDB’s purpose in life will never be realized.
To make the CMDB reliable right from the start, it’s necessary to involve the ‘owners’ of the CIs prior to and during the CMDB population process. These CI owners should review the data for accuracy, completeness, and consistency.
Once the CMDB has been populated, the challenge shifts into keeping the CMDB updated. Because an enterprises’ IT infrastructure can easily consist of a million moving parts (e.g. due to configuration changes, the arrival of new CIs, the retirement of deprecated CIs, organizational mergers and acquisitions, etc.), that won’t be an easy task. However, it needs to be done in order for the CMDB to function the way it’s supposed to.
What Are the Pros and Cons of Using a CMDB?
As the main objective of using a CMDB is to provide efficient management of your IT infrastructure, a CMDB must be easy to organise and navigate. But, like most deployments to the management and control of IT infrastructure, a CMDB comes with both its upsides and drawbacks.
Benefits of a CMDB
- Reducing an asset’s Total Cost of Ownership (TCO)
- Reducing downtime of infrastructure
- Minimizing the costs of operations and equipment repair with automated tasks
- Performing root cause analysis (RCA) to understand CI issues and resolve them
- Providing a single source of truth regarding a business’s IT infrastructure
- Delivering records of service codes and billing to finance teams
- Helping to meet regulatory compliance standards
Challenges of a CMDB
- Infrequent IT asset discovery can lead to a lack of data accuracy
- There is a lack of opportunities for integration with other tools
- Wrong data that has been stored in a CMDB can lead to ineffective decision making
- It can be difficult and time-consuming to collect all data in a CMDB
- The introduction of too many assets or CIs can be difficult to manage
What Is the Difference Between CMDB and IT Asset Management?
IT Asset Management (ITAM) is a set of IT/business practices that amount to something similar to Inventory Management but with financial and contractual components. Whereas inventory management is concerned with the assets you have, where they’re located, and who owns them, ITAM further expands on those concerns.
Although CMDB is a component of both IT asset management and configuration management, it differs from ITAM by containing and storing assets as CIs. By doing so, and per ITIL, a CMDB focuses more on the data used of managing assets within an IT landscape.
With ITAM, however, you would typically focus on the lifecycle of your IT assets and provide answers to questions such as:
- How much did a particular asset cost?
- What is its current accumulated depreciation?
- What contracts and maintenance agreements are associated with it?
- Is it still under warranty?
- If it’s a software asset, what are the license details?
- What is its current version?
- Which endpoints are running it?
IT asset management tracks and manages assets throughout each asset’s lifecycle – from the moment the asset is requested, through its procurement, deployment, installation, while it’s being provided support, up to the moment it’s retired and ultimately disposed of.
Because the coverage of IT asset management is quite broad, it consequently overlaps with, involves and integrates with other processes like request management, inventory management, procurement, financial management, and others – including configuration management.
This enables businesses to gain a comprehensive view of the organization’s assets as well as a detailed picture of each asset, especially from a financial and contractual standpoint.
Why CMDB Is Critical to Effective ITAM
First, let’s put things in the right context. A CMDB can only be immensely useful to IT asset management for as long as the CMDB can be tightly integrated with ITAM processes. If IT asset management processes can’t easily retrieve configuration data when they need to, the CMDB won’t be as valuable to ITAM.
Fortunately, most modern-day CMDBs now either act as a central repository of configuration data that’s also accessible to other processes or one that can be easily integrated with the datastores of other processes. Some CMDBs, for instance, store information about the devices on a network (which are usually associated with configuration management) as well as software contracts and licenses (which are typically associated with ITAM).
These CMDB architectures enable information generated in one process to be easily seen by other associated processes. In turn, this tight integration can greatly enhance each associated process. Let me give you a couple of examples.
Hardware and software usage information is normally gathered by configuration management applications. However, this information can also be used to support an IT asset management process like procurement. If the ITAM software can easily retrieve usage data, that data can be used to inform and streamline purchasing decisions.
Tight integration of CMDB and ITAM can also reduce risks. Let’s say a server is originally deployed at a particular business unit. As per IT asset management practices, that server is recorded into the CMDB under the ownership of that business unit. Shortly after, a configuration management solution’s automated scanning tool gathers information regarding that server’s CPU, RAM, IP address, MAC address, etc. and then stores these configuration data into the CMDB.
Incidentally, after a couple of months, the same scanning tool discovers the same CPU, RAM, and MAC address (essentially the same server) at another IP address. This could raise red flags and require further investigation if no change of ownership (presumably via an ITAM process) is recorded in the CMDB.
On a slightly different note, if another scanning tool discovers an application that never went through the proper channels, i.e. it was never requested, procured, or installed, as per CMDB records, then it could be a rogue application. Rogue applications can introduce vulnerabilities or can be outright threats themselves. Both can have an adverse effect on business continuity, so these applications need to be dealt with accordingly.
As these few examples show, IT asset management and configuration management don’t have to operate independently all the time. In fact, there are many situations when practitioners of these two disciplines can gain better insight when information is shared between an ITAM system and a configuration management system. The best way to do that, as stated earlier, is a centralized or tightly integrated CMDB.