Mature Change Management Before Maturing Your CMDB
Posted by on June 06, 2017
Chuck Darst is a Senior Product Marketing Manager for Cherwell Software. Chuck has over ten years of IT Service Management (ITSM) industry experience and over 20 years in a variety of IT Operations Management (ITOM) roles with a focus on machine learning, automation, compliance, and IT security.
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, Gartner1 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
1 Gartner - Implement IT Change and Configuration Management Before Developing a CMDB
Published: 3 January 2017 ID: G00318869
You might also be interested in
4 Must-Have Features for CMDB Tools
Here's how to know if your CMDB is problematic—and what features to look for to ensure you're getting all the benefits the CMDB offers.
5 Do’s and Don’ts of Incident Management
Incident Management is often the first ITIL process organizations put in place—here are important best practices to follow.
Is the CMDB Dead? 3 Ways to Guarantee a Successful Implementation
It's time to revamp the Configuration Management Database (CMDB). In this article, you'll find tips for an effective CMDB initiative.