ITSM Now!

Many IT Organizations have implemented a Configuration Management System to track and control IT Service Assets. As I mentioned in my earlier article “Don’t be Intimidated by ITIL”, this system doesn’t necessarily need to be an elaborate and costly commercial product. It just needs to have sufficient scale, features, and capabilities to meet the current and future needs of your particular business.

With a Configuration Management System (CMS) in place, the organization immediately begins to realize a number of benefits, including (but certainly not limited to):

• Improved ability to track changes and anticipate downstream impacts
  
• Easier and quicker handling of incidents
  
• Greater speed and accuracy in escalation of incidents
  
• Greater security due to increased control over items in the environment (Configuration Items, or CIs)
  
• Increased ability to manage proactively due to improved ability to spot trends in capacity, availability, and incident management
  
• Facilitates compliance with Sarbanes-Oxley, HIPA A, and other regulatory frameworks
  
• Greater control over software versioning and licenses
  

That’s the good news. The bad news is that these highly desirable benefits will quickly disappear if the Configuration Management System is not actively managed. In order to realize the benefits, nearly every other aspect of IT Service Management utilizes data stored in the CMS in order to make decisions. If the data is not current, accurate, and complete, these decisions will invariably be suspect, and the consequences can be dire. The CMS goes from valuable asset to dangerous liability.

The bottom line: your Configuration Management System is only as good as the process you put around it.

Fortunately, this fate can be avoided. A few tips for ensuring the validity of data:

• Make someone within the IT organization accountable for the integrity of the data in the CMS. In a large organization, this might be a dedicated role, but in many businesses this person might wear other hats. The Configuration Manager role could be combined with the Change manager, Release Manager, or possibly the Service Desk Manager.
  
• Establish regular naming conventions and stick to them. This is absolutely essential to ensure valid data, and attention to detail is required. I frequently encounter companies with CMS entries for “SERVER1, server1, Server1, and server-1”. These all refer to the same piece of hardware, but let’s look at some potential consequences of this:
  
  
  • A System Admin submits a Request for Change for SERVER1. The Change Manager reviews and approves the change. Some services and application dependencies are listed for SERVER1, but others are tied to server-1. Implementation of the change results in unanticipated service outages.
    
  • The existing IT Service Continuity Plan contains disaster recovery information for server-1. When a new service is added to the server, it is recorded under SERVER1. The continuity plan is not updated and a full recovery of services in case of emergency becomes impossible.
    
  • The server is retired and fully depreciated by the accounting team. The status of SERVER1 is changed to “retired”, but other names for the same system remain active in production. Production dependencies remain in place, and an outage occurs when the “retired” server is unplugged from the network.
  
  When multiple entries for the same Configuration Item are discovered, it is essential to carefully merge the entries, change histories, and associated relationships into a single entry.
  
• Perform regular audits. It is essential to periodically review the current conditions in the physical environment and compare to the data contained in the CMS. The CMS should be considered a snapshot of the environment at a point in time. Performing audits validates the snapshot at a more recent point in time, so it is desirable to audit frequently. In order to assist with this…
  
• Introduce some level of automation. In extremely small IT environments it might be possible to maintain a CMS manually, but the scale quickly becomes unmanageable. The introduction of automation tools to assist with the audit process is generally considered a necessity. An example might be a simple shell script that verifies OS and software versions across the environment and compares these values to the CMDB. Various network mapping tools exist that can assist in validation of CIs as well.
  
• Define appropriate process metrics. What can’t be measured can’t be managed, and the Configuration Management process is no exception. Of course, specific metrics will vary based on the needs of a given business, but here are a few good ones to start with:
  
  
  • Number of failed changes / changes with unanticipated consequences. Variances in this number can reflect the validity of the CMS data or the Change Management process, so this metric is incomplete without supporting data.
    
  • Variance between CMS data and audit results. Ideally there should be no variance, but in the real world there always is. This is a direct measure of adherence to established processes, and can expose a need for training or other management intervention.
    
  • Number of licenses purchased and unaccounted for in the CMS. This measure can provide an indication of effective spending in addition to adherence to legal requirements.
    
  
  

A good CMS is the backbone of successful IT Service Management. The implementation of a good CMS is a significant achievement, and the addition of supporting processes and metrics allows the organization to realize sustainable benefits on an ongoing basis.