Trap? What Trap?
The term "IT asset management" is inherently confusing.
To some people, it might mean:
I want to manage IT assets from a governance perspective: I want to make sure the assets (desktops, servers, etc.) have a common configuration, meet my basic security policies, and have a standard set of software. (A better term for this is "systems management.")
To others, it might mean:
I want to manage IT assets from a service perspective: I want to make sure my business-critical applications are up and running, that we’ve recorded their current configuration and relationships, and that we can detect configuration changes that could affect their function or availability. (A better term for this is "service/configuration management.")
And to still others, it might mean:
I want to manage IT assets from an accounting perspective: I want to know what assets I own, if there’s a gap between the most recent inventory and my records of owned assets, and the location and status of all assets. This is “pure” IT asset management.
To recount, there are three domains: IT asset management (ownership of IT assets), systems management (governance of IT assets) and service/configuration management (governance of services/applications).
Here's a typical breakdown of the data divisions among these domains.
In some circles and contexts, all domains are called IT asset management, which always leads to confusion and often to deployment of inappropriate software solutions.
A frequent example of this confusion is that many shops confuse a CMDB with an asset repository. A hardware asset repository should contain only physical items that have been purchased, while a CMDB contains configuration items (CIs) that represent a virtual server, a service or a process. The CMDB should contain only CIs that support a service or application, yet I often get requests from clients to include everything we can discover on the network in the CMDB.
To add to the confusion, the three domains contain overlapping data. For instance, a particular server could be an asset under financial control, a system that needs to comply with software, security and configuration policies, and a component of an application or service. So from a data perspective, it makes sense for these domains to share data, but that leads to blurring the lines among them.
The negative consequences of blurring the lines among these domains can be serious. For example, using all of your discovery data (from systems management) to populate your CMDB (configuration management) can cause your CMDB to become unmanageably large. The CMDB will include items that don’t support critical services, and it won’t include undiscoverable components that support your services, such as processes. Using the same discovery data to populate your asset database (IT asset management) makes it impossible to audit your owned assets against inventoried assets, because you have made your database of inventoried assets your master list of owned assets. As a result, the main function of IT asset management, IT asset governance, fails.
Now that I’ve laid out the problem, you’ll want a solution. Tune in to my next post, coming soon, for my recommendations.
In the meantime, if you’ve experienced other negative consequences of blurring the lines among these domains, feel free to leave a comment.