Desire for Enhanced Visibility Drives Increased Interest in CMDB

Ann All

Ann All spoke with Kurt Milne, managing director of the IT Process Institute, an independent research organization that exists to support the membership of IT operations, security and audit professionals. Its mission is to identify practices that are proven to improve the performance of IT organizations.

 

All: Recent IT Process Institute research found that most organizations begin their process improvement initiatives with change management. Do some organizations experience difficulty moving beyond that stage?
Milne: Although my study didn't test it specifically, it is generally recognized in the industry that ITIL projects should start with change management, then also address configuration management. Change management includes change tracking, change approval, change risk assessment, etc. However, release management practices have often not been the priority and focus. My study shows that the release practices have a broad measurable impact, whereas the change practices do not. My conclusion is that change practices are required and possibly pre-requisite for release, but are not sufficient on their own to impact performance.

 

All: Only 19 percent of organizations responding to your survey have a CMDB in production use. Is interest in CMDB rising?
Milne: I think there is a growing number of organizations trying to implement a CMDB-type solution (although my study didn't look at trending.) At industry conferences, I've asked for a show of hands for who wants one or who is working on implementing one, and interest and activity is quite pervasive. The devil is in the details, however, and there are a number of hurdles to get one in place, and keep it maintained and accurate.

 

The link to change management assures that changes to the infrastructure/applications, etc. result in an update to CMDB data. However, organizations need to also periodically audit the infrastructure (similar to doing a physical inventory at a store) to make sure CMDB data is accurate - until they have assurance that change processes are keeping the CMDB accurate. CMDB helps create an integrated map of what each system has (version, configuration) and what it is connected to, and what is dependent on it.

 

All: What is driving this increased interest?
Milne: The driving forces, especially in larger distributed companies, are compounded:


 

  1. So many key business processes/applications in all industries rely on proper function of the data center, network, applications etc., that the stakes are increasing that these systems work as designed.
  2. Data center consolidation, virtualization, standardization mean that more and more applications rely on underlying systems. Those systems must be treated as business critical assets.
  3. Even with simplification of compute environments, there are layers of database, OS, middleware, applications etc. that all must work together. Each changes as vendors do version updates. There are almost infinite combinations of versions and configurations. Some are reliable and secure. Many are not.
  4. Understanding the current version and configuration of each system is difficult as the various layers are upgraded.
  5. Knowing the desired state or approved configuration is hard.
  6. Knowing the current state or actual configuration is hard.
  7. Knowing what upstream and downstream dependencies there are between systems that may not be located in the same data center is hard.

 

All: Your research found that adoption of a CMDB alone is not necessarily a predictor/indicator of successful process improvement initiatives - but some practices enabled by using a CMDB are. Can you clarify what some of those practices are?
Milne: It is generally recognized that the CMDB is a supporting capability. The CMDB in and of itself doesn't improve performance. It is what you do with it, how it improves other key processes, that drives value. The CMDB-related practices that didn't predict performance variation include (in survey question form):

 

  1. We have a change tracking system that identifies Configuration Items (CI) in a CMDB, including upstream and downstream dependent systems that may be affected by a change request.
  2. We have a CMDB that describes the relationships and dependencies between configuration items (infrastructure components).

 

The change practices that do predict performance variation (which are enabled by a CMDB) include:

 

  1. We identify CIs related to a change request in order to automate communications about pending and implemented changes
  2. We can link change requests to business need through CI relationships.
  3. We provide change history information to personnel managing incidents and problems.
    Linking change requests to infrastructure component (aka configuration item CI) - and to business need - predicts higher levels of performance in the areas of fewer failed changes, improved failure response time and reduced configuration drift.

 

All: Did your research also indicate some other best practices?
Milne: A snapshot of the key practices of top-performing organizations in my study includes:

 

They maintain production systems in a known, tested, risk-reduced state. They standardize configurations to reduce complexity and improve scalability and supportability. They update production systems from golden-build configurations to minimize risk. And, they monitor for configuration drift and unauthorized changes to keep systems in a known state.

 

They minimize access to production systems. They recognize that small changes have a big potential impact, and they remove development access to the production environment. They clearly define roles and responsibilities and separate the duties of develop, test and build, and production release.

 

They allow modifications to the production environment only through a carefully controlled process. Every production modification is recognized as an availability and security risk. Each release meets build requirements, including documentation and support instructions. Releases are tested. Backout plans are tested. Releases are scheduled during maintenance windows and considered a failure if they do not exactly follow release instructions or are not completed on time. Release failures and process exceptions undergo root cause analysis to identify improvements that reduce process variation.

 

They use executive influence and human-resources practices to build a process-oriented culture. Following documented processes and procedures is recognized as a basic job expectation. They focus on process exceptions as a way to identify the cause of variance and to identify process improvement efforts. IT executives actively participate in monitoring process variance and process improvement efforts.

 

Overall, these practices contribute to a systematic way to achieve the highest levels of performance. In top-performing IT organizations, consistently high and predictable performance is not dependent on individual preference or skills, and can be achieved across location and business unit. This point is key. IT and business executives want predictable performance and results that cut across location and IT skill sets.



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 

Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data