Mature Change Management Before Maturing Your CMDB

Too many CMDB projects have become black holes, sucking resources and life out of IT with little provided in return. Despite more pragmatic approaches these days, Gartner¹ states that more than half of CMDB efforts become unmanageable. With that in mind, how much information needs to go into your CMDB—and when? Hundreds of articles and entire books have been written on this topic, and getting to a specific answer for an individual organization can require weeks or months of workshops and design analysis. In the interest of brevity, I will condense this into one blog post.

Process Adoption and a Hierarchy of Needs

It is with good reason that Incident and Change Management top the list of most commonly adopted ITSM or ITIL processes. The “Big Three” typically include Problem Management, even if this specific process is frequently not very mature. Service Level and Knowledge Management typically round out the top five of adopted processes. And as self-service becomes more common, Service Catalog and Request Fulfillment join the upper echelon of implemented processes.

While you need to know the Configuration Item (CI) when handling an incident or managing a change request, the extent of Configuration Management and CMDB adoption varies widely. Like food and shelter in Maslow’s hierarchy of needs, all service desks track CI’s to some degree. (And it is interesting that Maslow’s model and popular maturity models like CMMI or Gartner IT Score all have five levels.) Whether is it called a master data repository (MDR) or a CMBD, a service desk will have this type of basic CI information to support its core management processes.

Service Management and the CMDB Holy Grail

While many processes benefit from the visibility a CMDB provides, improving Change Management continues to be a top driver for implementing a service-aware CMDB. Self-inflicted service outages due to change “collisions” have been a bane of IT teams for years. Understanding the dependencies and relationships among services, applications, and infrastructure helps identify potential collisions during an impact assessment phase—instead of after it reaches production.

To address the change collision risk conundrum, CMDB information including dependencies needs to be accurate. As IT environments scale and become more dynamic, automated means of discovery and CMDB population become essential. The combination of having current configuration information and change records further enables “unplanned change” and its twin, “configuration drift,” detection, which are common aspects of compliance and security management programs.

If it were only that simple. CMDB efforts continue to struggle for several reasons, but most frequently, it relates to over-scope—that is, putting too much information into a CMDB or attempting to map too many applications or services at once, especially when first beginning.

First Things First: Mature Change Management

Back to maturity models for a moment. Before IT can reach self-actualization, be optimized, or become a business partner, IT needs to have defined processes that people actually follow. Complicating matters, Change Management is one of the most highly customized processes due to differences across organizations in what changes can be standardized or automated, the degree of regulatory oversight, what is subject to Change or Configuration Management, and more.

Before layering service-based impact analysis, you need to have well defined and reasonable processes that IT will follow, as opposed to excessive processes that are bypassed or “worked-around” with a leaky emergency change process. This includes assessing, authorizing/rejecting, scheduling, and reviewing changes. These are all important tasks in improving the effectiveness of Change Management and should be done before adding visibility of service dependencies.

With the rise of DevOps, I would also recommend evaluating your Change Management process to incorporate smaller batch sizes that can be classified as ITIL® Standard changes. These changes can then move through the process in a more automated fashion.

Once these are in place, the IT organization can better pursue service-based management and mature its CMDB by adding application dependency mapping.

Next Up: See how Cherwell supports key ITIL processes including change management

Learn More

Reference
¹ Gartner - Implement IT Change and Configuration Management Before Developing a CMDB
Published: 3 January 2017 ID: G00318869