Everyone knows a Configuration Management Database ( CMDB ) is a good idea. We’ve known that for years. And yet, in many years of ITSM practice, I’ve rarely seen a good one.
CMDB and Change Management
There’s a big difference between the ability to automatically scan for devices and a functional CMDB (or the broader Configuration Management System (CMS)) – at least as it’s positioned in ITSM.
In the traditional sense, Change Management authorizes changes to be implemented in the production environment. One of the results of an approved change is updating of the CMS – to reflect the approved state.
In practice, this works in one of two fundamental ways:
- When authorized, the CMS is updated to reflected the approved configuration change. Once the CMS is updated, production is updated to match the approved (new) state now reflected in the CMS. This can happen through automation or manually.
- When a change is authorized, the production environment is updated as approved, and the CMS is updated to reflect the new state of production (which presumably reflects the approved change). This too can happen through automation or manually.
In a more advanced state, either of these two approaches significantly improves practically every other ITSM practice.
Detecting unauthorized changes of state
With a good system in place, the state of the production environment and the CMS can be compared. Any differences between the two reflects a potential unauthorized change that can range from minor error or a major security breach.
It also serve as a meaningful reflection of the effectiveness of the Change Management process.
This is all good for effective IT Operations, but here’s the challenge:
The world got complicated
It may be a solution to a vintage problem.
In other words, this is what we should have had in place many years ago.
But the world of modern IT operations has changed a lot since CMDB was envisioned.
Here’s some ways the world has changed:
- Agile/DevOps approaches to application development
- Rise of product management (as opposed to project management)
- Widespread adoption of cloud hosting (AWS, Google, etc)
- Build, test, and deployment automation
- Containerized application hosting
- Enterprise implementation of SaaS solutions
Cars and Drivers
There was a day when drivers had to have a tremendous amount of mechanical knowledge to drive an automobile. The Model T is hand-crank started, not unlike a lawnmower. The driver had to adjust the ignition timing with the Spark Lever on the steering column. It has three pedals, none of which is the gas pedal – that’s adjusted by another lever on the column.
The point is, most modern drivers would be completely lost trying to drive a model T for lack of detailed understanding of the machinery.
Modern cars, on the other hand, have easily understood, standardized controls. The average driver can successfully drive most any production car.
In other words, you can drive a modern car without knowing much about the underlying mechanics.
To what end
What does the Model T have to do with CMDB and IT operations?
Simply this: modern IT delivery is increasingly complex. So much so that it takes an ever-increasing amount of effort to fully understand it, let alone keep an accurate configuration inventory. (Yes, I’m WELL aware there are tools that help).
In practice, though, there’s a point of diminishing returns for the level of effort required to keep such an inventory. We have to ask ourselves – to what end are we maintaining accurate configuration information? The usual answers have to do with understanding how proposed and implemented changes will/have impacted the environment. Add quick and effective resolution of incidents and problems.
In fact, nearly every aspect of IT service delivery is aided by effective configuration management, and yet…
Imagine a world
It takes a lot of work to maintain a CMDB, begging the question – ‘what if maintaining a CMS became costlier than the value it produced?’
I’m not saying that’s true now, certainly not in every situation.
But if you stand back and look at the industry overall, we see two opposing trends that relate:
- Increased complexity – especially in infrastructure operations, and
- Increased simplicity, isolation and automation – especially in application development
The modern IT infrastructure is a complex hybrid of on/off premises, cloud and SaaS applications, with decoupled, data-centric interface strategies, increasingly designed around business (or enterprise) architectural principles.
Even a cursory reading of Google’s Site Reliability Engineering reveals a modern view of complexity and ‘engineering quality in’ (ala Edwards Deming). Infrastructure that’s managed with this view in mind becomes vastly more resilient; antifragile. And, it’s resilient because it’s designed to be, not (necessarily) because the operations team controls the configuration with an iron grip.
Add to that the product approach to enterprise applications, and with it, the elements of modern build and test automation, and containerization of applications and suddenly…
Wait. What was I talking about again?
Oh, yeah. CMDB.
See the paradox here?
The CMDB approach, one could argue, is focused on the details of the machinery, under the belief that that level of understanding is required for stable, reliable IT services.
By contrast, what I’ve described as the modern approach is focused exclusively on the ability to produce desired outcomes. Of course, it’s a debatable opinion that is only defensible in certain contexts, but hear me out:
- If a complex system produces a consistent, reliable level of business outcomes, does it really matter that we don’t fully understand how it works?
- If the level of effort required to establish and maintain a CMS was instead applied to engineering a resilient, predictable system, would the business be better served?
- As smaller companies, school districts, government agencies adopt Agile, DevOps, SRE and modern cloud infrastructure, does the need for configuration management change; diminish?
Making it work
The point of all this is that over time, I see the value of (at least a traditional) CMS diminishing. I’m in no way anti-CMDB, and I’m all in for automation of the practice.
The trick, of course, is for organizations to determine the optimal approach to CMS. As IT is increasingly put upon to accelerate and increase the value we bring, we have to challenge everything we do. We have to deeply understand how the things we do add to, or take away from business value.
