Skip navigation
All Places > CA Service Management > Blog > Authors Mstricker

CA Service Management

2 Posts authored by: Mstricker Employee

In my last post, I defined the problems inherent in blurring the lines among the domains of IT asset management, systems management and service/configuration management. 

You can help your organization avoid the confusion by clearly distinguishing among the three goals—and the groups responsible for meeting those goals. I know—it’s easier said than done—but here are some tips:

Assign a person or team to handle financial IT asset management—to account for each IT asset the organization owns. They need to receive all records of IT purchases from Purchasing and all records of discovered and managed computer systems from Systems Operations. A solution such as CA IT Asset Management, which compares the two sets of records and documents lifecycle data such as make, model, location, and status for each computer system, will be invaluable to the team.

and

Assign a person or team to handle systems management—to ensure that all network systems conform to policies. They need to coordinate with the security team for security policies, the operations team for standard configuration policies, and the software distribution team for required/allowed software, patching, and reporting. A solution such as CA Client Automation is essential for supporting these activities and discovering computer systems on the network.

and

Assign a person or team to handle services and configuration management—to minimize downtime, outages, and operational errors by governing the configuration of business-critical applications and services. They need to coordinate with the application, release management and change management teams to model the authorized configurations of new applications and services when they come online and throughout their lifecycle. A must-have for this team is a solution such as CA Service Desk Manager, which captures the authorized configurations and relationships among the components that support the application or service. Another must-have is a solution like CA Configuration Automation, which discovers the configurations and relationships of the components (such as web servers, database servers, and application servers), compares the discovered configuration with the authorized configuration and identifies gaps.

Yes, this effort requires discipline—but it can be done. Your organization will thank you.

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.