The Role of CMDB in
Effective IT Asset Management
IT Asset Management Software, ITSM Software
A CMDB or Configuration Management Database is no ordinary data repository. Rather, it plays a very crucial role in various IT management disciplines. In this post, we zoom in on the CMDB’s role in IT Asset Management.
We’ll start by introducing you to the functions, benefits, and other pertinent concepts regarding CMDBs and then follow that up with a discussion on IT Asset Management. Finally, we’ll explain the importance of a CMDB in the context of the latter.
What is CMDB?
A CMDB or Configuration Management Database is a data repository primarily used in configuration management, a key process in the ITIL 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.
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, in the context of CMDBs, are known as configuration items or CIs;
- The relationships/dependencies of CIs with other CIs and other related entities; and
- 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 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, arrival of new CIs, 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.
Now that you have an overview of what a CMDB is, let’s now talk about IT asset management.
What is IT Asset Management?
You can imagine IT Asset Management or ITAM as a set of IT/business practices that amount to something similar to Inventory Management but with financial and contractual components. Whereas inventory management is only concerned with the assets you have, where they’re located, and who owns them, ITAM further expands on those concerns.
With ITAM, you would typically answer questions like: 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.
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.
By leveraging on the information generated in ITAM-based business practices, organizations who implement IT asset management are more capable (than companies who don’t) of:
- Reducing their assets’ TCO (Total Cost of Ownership);
- Maximizing the utilization of each asset;
- Enabling IT resources to meet the demands of business units;
- Maintaining business continuity;
- Meeting compliance requirements; and
- Achieving better business-IT alignment.
Why CMDB is critical to effective IT Asset Management
First, let’s put things in the right context. A CMDB can only be immensely useful (or critical) 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.