The Configuration Management System and the Road to Automation

Is your IT Process Automation (ITPA) automating train wrecks? Without the visibility offered by ITIL’s Configuration Management System (CMS), you may be sidetracking your efforts to implement more consistent, more effective, and more compliant and risk-free ways of working.

Last summer I wrote about “Stepping Up to Process Automation: Why You Should Care.” That article laid out a kind of “automation landscape” to help you navigate through your choices. In this article I’d like to follow up with some perspectives focused on how to bridge your CMS investments to automation technologies more effectively.

While IT Process Automation (ITPA) and Configuration Management Systems (CMSs) have very different roots, they are slowly beginning to converge in more advanced CMS deployments. CMS deployments that depend on extensive manual updates quickly become error prone and administratively costly. To some degree, progress between CMS phase definitions is and should be contingent on levels of automation to support more expansive capabilities in order to avoid creating operational sink holes.

So it is not surprising that respondents in Q1 2009 EMA research said that their number one technical priority for expanding their CMS deployments was “supporting IT process automation” at 54%, a full ten percentage points ahead of supporting processes for the Change Advisory Board, which came in second.

On the other hand, many in IT express a fair amount of confusion in linking their investments in automation with the CMS.

There are a lot of reasons for this. A few of the most salient are:

1. CMS technologies and capabilities for advanced automation are broad in nature, relatively new to the market, and are each in themselves a source of confusion. So combining the two effectively means charting your way through two of the most complex, though potent, transformative forces in the industry and intelligently defining the linkages.
2. Both CMS and IT automation capabilities depend on process awareness and maturity, and so cannot be fully grasped by simply defining the technologies themselves.
3. While the traditions behind the CMDB and CMS have been focused on cohesiveness, governance, and executive commitment in support of strategic growth across IT, many areas of advanced automation -- from job scheduling and load balancing to device-specific configuration tools – have been siloed and tactically driven by engineers and hands-on professionals seeking to get a leg up on what they view primarily as personal tasks.
4. The very packaging of CMS-related technologies ranges from service-desk-centric solutions (which inherently imply some workflow linkages for Incident and Problem Management) to more operationally centric solution sets targeted at automation associated with integrated discovery, diagnostics, and dynamic adaptability to change.
   Since there is no single industry-consistent place to start with a CMS, and since the market offers no single consistent beginning point, there is no common answer to where you should begin to focus your efforts around CMS investments and automation.
5. ITIL, itself, offers great value and guidance – I would actually call it visionary in many respects, especially in terms of the Configuration Management System (CMS) and lifecycle service/asset management. However, ITIL rightly avoids getting into thorny details of individual products and technologies, and so presents a vision that is largely transcendent to where and how automation can be optimized.

Given all this, my goals for this article are to provide you with a few, top-of-mind guidelines for charting your own individual course in linking CMS initiatives with automation. And I welcome, by the way, your thoughts and feedback, as well. The definitive text on doing this well has yet to be written, and won’t be written, but the fastest way to get there is to all learn from each other.

Recommendations

The first thing to do is to look at the “automation landscape” as I did back in Q3 2008 and compare it to the “CMS” landscape in order to understand which linkages are most native and essential between the two, and which are more secondary. Secondary linkages may prove at times even more powerful in extending the benefits of your CMS investment, but they are less essential to the effective operation of the CMS itself.

The Automation Landscape

The automation landscape can be logically broken up into three categories: machine-to-machine; machine-to-people/or people-to-machine; and people-to-people.

The categories that I find most useful are: Lifecycle Application Automation, designed to support better collaboration across application development; QA/Test and Operations, which combines all three flavors of automation; Service Management Automation, targeted at triage and diagnostics, which is typically machine-to-machine and often dependent on advanced analytics; Data Center Automation which includes core capabilities for Configuration Management, job scheduling, virtualization and load balancing and is more machine-to-machine or machine-to-human; and ITSM Automation which is Service Desk-centric, and focuses on workflow and human-to-human interactions primarily.

Technologies for CMS Automation

As Configuration Management Systems evolve, they are becoming a center of automation capabilities in themselves, chiefly machine-to-machine in support of better information management to inform human decision making and to provide a springboard for more active types of automation ranging from closed loop Configuration Management, to dynamic infrastructure optimization, to application provisioning, to Service Request management, to far more automated capabilities for compliance, audits, and troubleshooting.

But first and foremost, your CMS investment needs to be well architected to support automation required for its own effective operations and evolution. With these capabilities, your CMS is well positioned to “take care of itself” as an integrated resource for governing more active forms of automation. So it’s important to look at “core CMS automation” requirements. A partial list might include:

• Dynamic infrastructure discovery technologies.
• Dynamic application dependency mapping technologies.
• Technologies for synchronizing, normalizing, and reconciling multiple data sources across the federated CMS, including various discovery sources as well as multiple MDBs (or possibly federated “citizen” CMDBs) established as “trusted sources”.
• Technologies for managing CI states (discovered, approved, etc.), including automated flagging of instances where “discovered” and “approved” states are in conflict.
• Automated support for audits to define CI owners, configurations, relevance (service/customer impact or usage depending).

A partial list for Tier 2 levels of automation for a CMS might include:

• Analytic/ visualization technologies directly linked to CMS operational requirements to understand where changes have occurred, who and what might be affected when changes are planned, who and what the owners might be when problems arise, and through federation – what the root cause of a problem might be.
• Process technologies directly associated with CMS governance, such as support for the Change Advisory Board, or core incident and problem management associated with critical CIs.
• Analytic/visualization technologies in support of service lifecycle management in which key lifecycle records (incidents/ problems/ asset specifics) are dynamically linked with CIs.
• Automated support for application lifecycle requirements so that the CMS can be harvested by application developers, Q/A Test and Operations, as well as service desk professionals.
• Closed loop Configuration Management in which the CMS provides a cohesive platform for planning, initiating, automating and validating scheduled changes across the infrastructure.
• Asset capabilities automatically flagging redundant hardware and non-compliant software (Software License Management).

Summary

In most deployments, of course, the above are still far from fully automated and many are not automated at all.

But, perhaps the most important thing to keep in mind is that just as the CMS should provide unified insights into the impacts of change – as process automation evolves, it, too, must be viewed not as a siloed set of technologies, but as a unifying force.

None of this is of course free of politics and good process planning. But it is exciting to see technologies at least begin to emerge that truly can help to empower new, more effective, and in some cases more automated ways of working across all of IT.