How to 'Fix' your CMDB with Hardware Asset Management

Orland Dami, CIO AdvisorySenior Associate, KPMG

Orland Dami, CIO AdvisorySenior Associate, KPMG

You’ve got a shiny new CMDB, running on some fresh new hardware. The integrations are in place. The relationship maps are up to date. If even one server goes down, you know exactly what service is affected. Today is a good day to be in IT.

Then the call comes in, and someone wants to know what is going with all the mobile devices. And all the laptops. And this, and that. Suddenly the new data is getting stagnant, and ownership of the data is non-existent. Before you know it, the humble CMDB has grown into an incorrigible monster.

But not all databases are created equal. And the issue is so common in my experience, that right at the top of my “ITAM Consultant Toolbox” is a collection of presentations all designed to answer the questions:

“What is the difference between the Configuration Management Database (CMDB) and Hardware Asset Management (HAM)? And why do I even need Hardware Asset Management?”

The impact of ignoring these questions, and ignoring the goals of the CMDB by forcing the technology into a role it wasn’t meant for, can ruin a massive investment in short order.

The Crash Course: HAM and CMDB 101

Let’s start with the basics:

• A Configuration Item (CI) is defined as an asset that needs to be managed in order to deliver a service. This could be a single asset, or a collection of them (e.g. a server).

• A Hardware asset is any physical IT component.

• Hardware Asset Management (HAM) is the set of practices regarding the management of the physical, contractual, and financial aspects of IT Hardware.

• The Configuration Management Database (CMDB) is a core component of configuration management as defined by the ITIL Framework. It is a database of configuration items and their relationships.

• The Asset Management Database (AMDB) is the database that holds the asset information.

Do you have a physical server, with database software, in support of your email service? That’s a Configuration Item AND a Hardware Asset. Your work laptop is also a hardware asset.

It began as a hardware asset when your company received the pre-shipping notice, and it will remain a hardware asset until it is disposed of. But your laptop is, if anything, a means for you to consume IT services, not to deliver them. As such it will never be managed by Configuration Management, and therefore, it will never be a CI. Thus, the expression, “Every CI is an Asset, but not every Asset is a CI”.

Why Things Go Wrong

If you want to set up a CMDB from scratch you need the technology, processes, governance, and people staffed to do it correctly. And the reality is, just like any technology initiative, they all cost money. Imagine a Venn diagram, where one side represents the assets in the CMDB, and the other represents the assets in the AMDB. Instead of these two databases overlapping slightly, the CMDB can often fit entirely ‘inside’ the AMDB. And while the data about an asset is different from one database to the other, the asset itself can exist in BOTH databases.

Lastly, we cannot forget about the Asset Lifecycle. The CMDB primarily concerns itself with active and managed assets – CIs by definition, while the ITAM Asset Lifecycle may begin in the planning phase or when the pre-shipping notice is received. Many clients want a ‘hand-off’ point, where ownership officially transfers to the CMDB group, and out of the hands of the ITAM team, and vice versa. But the reality is, the ITAM/HAM team will always have involvement with hardware assets. The hardware continues to exist in BOTH databases, throughout each respective lifecycle.

So two databases, similar assets, and we know both are a challenge to setup. Is it any surprise that so many organizations just say “let’s put it all into the CMDB”?

How to Fix your CMDB

The only assets in the CMDB should be those that are subject to change management, incident management, or support a service.

And the key fields should be related to those functions, while the physical, contractual, and financial data should exist in the AMDB. Following this ensures that as long as the change management processes is adhered to, once an asset does becomes a CI, the data won’t go stale. Ignore this, and a few thousand CIs can quickly become tens of thousands, or even hundreds of thousands. So you need to ask yourself, does the cost of setting up a basic AMDB outweigh the cost of overly customizing your existing CMDB, the cost of bad CMDB data, and the cost of fixing the CMDB after it goes south?

The Case for Hardware Asset Management and CMDB

An end user might use the same laptop for two years without so much as a ‘cannot print…’ support ticket. But that laptop has software on it, which happens to be quite expensive, and it also may contain sensitive information that carries risk to the organization. Minimizing this risk, and improving the utilization of assets, is what we strive to do with ITAM. Where is the asset physically located? Is it being used? How much does it cost and is it being depreciated? Who owns it? Is the maintenance contract up to date? These are the questions keeping the ITAM professionals up at night.

At the same time, the CMDB answers its own equally important questions, and plays a critical role to the ITSM organization. While ITAM, with the exception of Software Asset Management, is not included the ITIL framework. We must also consider virtual machines, which by definition do not fit the HAM framework. This is where we rely on the CMDB to fill in the blanks. The AMDB simply cannot fit the role of the CMDB, and the CMDB cannot fit the role of the AMDB.

So if you’re looking to ‘fix’ your CMDB with Hardware Asset Management, you really just need to use both.