CMDB Spruce Goose, Star Wars Death Star, or an Answer to World Peace? (Remix 2023)

It’s hard to believe that 16 years ago I wrote the text below in my original article on the important topic of service configuration management, CMDB — Spruce Goose, Death Star, or Answer to World Peace?:

Of all the processes described by IT service management, none receives more attention and media hype than configuration management. For some, the configuration management database (CMDB) represents the impossible juggernaut akin to the famous Spruce Goose. For others, the CMDB represents the Death Star, the ultimate weapon and tool of a dark and insidious master of a strange force bent on strangling the creative energy out of a free-spirited IT department. While for others, the CMDB represents the ultimate panacea for all IT woes and the answer to world peace. In my view, the CMDB represents a much more mundane but necessary concept that underpins the most basic issues of running a successful IT operation: You cannot manage what you do not understand.

While there have been many changes in respect to automation, legislation requirements, and increased business criticality due to digital transformation objectives – not much has changed. Most organizations continue to struggle with the successful adoption and ongoing management of an accurate source of information and an understanding about relational dependencies that reflect the managed IT environments for which they are responsible.

In fact, most organizations have implemented a service management solution with a module called a CMDB. They do not use it for service modeling but rather use it to track IT asset-based information for software license and compliance reasons. Just because you have a module in your tool that is called configuration management that does not make it a configuration management database where services are modeled, and critical relationships are tracked. 

In this updated article, let’s consider the changes that have occurred over the past 16 years that make the concept of an accurate configuration management system a necessity and, in principle, an obtainable goal. We will also consider organizational practices and cultural challenges that continue to make the concept of an accurate configuration system an elusive and seemingly impossible reality.

What’s Changed in 16 Years?

Automation changes:

Discovery and monitoring tools: Discovery tools have come a long way from the vendor/domain specific tools of the early 2000s to where discovery tools are able to discover, map, and aggregate devices and relationships. They represent technology systems in relationship to how they are used by specific organizational groups and roles and even map and track business process transactions referred to by Gartner as business activity monitoring (BAM).

DevOps configuration management: Configuration management has in recent years been highlighted by the DevOps community. A great deal of emphasis has been placed on both the verb of environmental configuration as well as the need to capture the current configuration for the purposes of financial tracking and risk-based compliance. Cloud-based solutions to support environmental configuration and deployment such as DevOps pipelines and toolchains are integrated with IT asset and financial systems to track license requirements and billing automation. 

On a related topic, one of the challenges we face regarding configuration management is that like many English words ‘configuration’ is a word with the same spelling that has multiple meanings depending on context and the audience.

In today’s modern IT world, we use the phrase configuration management in different contexts, including as:

• A noun (the current configuration): What is the current configuration of an IT asset, device, or end-to-end service model?
• A verb (to configure): The act of configuration via orchestration, provisioning, and deployment tools
• An artifact (the standard configuration): Software configuration, the old use of the term that is now known as trunk management in DevOps lingo, focuses on documenting and storing software artifacts that are version-controlled and refers to an actual instance of a script we house as code in a software repository.

I explore this in detail and its relationship to the DevOps usage in the following article: Configuration Management – A Rose by Any Other Name.

AIOps and discovery: Organizations are now using AIOps, which is the application of artificial intelligence (AI) capabilities to help with discovery and configuration by providing a unified view of the configuration items from a systems’ and cross-domain perspective. AIOps enables organizations to discover technology systems and topology data across multiple IT domains and services.

Legislation changes:

During the past 16 years, there have also been major changes and increased legislation and regulatory requirements based on the increased threat posed by cyber and digital attacks:

• Financial reporting (SOX, Basel 2, Turnbull) 
• Privacy regulations (ECPA, PIPEDA, CPPA)
• Data location (Cloud Act, GDPR
• Records retention
• Patriot Act (critical infrastructure)
• Cyber security – (FISMA, HIPPA, Gramm-Leach-Bliley Act)

Guidance includes the NIST Special Publication 800-128 Guide for Security-Focused Configuration Management of Information Systems: U.S. Department of Commerce.

“IT organizations must implement a comprehensive, IT-wide configuration management strategy. Configuration management enables visibility for auditability, ensures configuration consistency for compliance, and intersects with other management disciplines.”¹

So, as we can see, there is no shortage of regulatory drivers that should be ensuring we apply the discipline of configuration management. So, why 16 years later are we still struggling with this? What are the key organizational and cultural challenges that make this concept difficult if not impossible to apply?

What’s Stopping Us from Moving Forward?

Organizational and Cultural Challenges:

Service versus technology orientation: I recently wrote a blog, The Service Catalog Is the Central Pillar of an IT Service Organization. In it, I identified that a critical dependency for many IT service management concepts is that – as an IT organization – we have our IT services defined in a service catalog and that those services are intentionally governed and managed. This is a critical dependency for most IT service management processes, and the service catalog I am referring to goes way beyond the typical end-user request catalog interface that organizations have set up to enable service request management.

The current and ongoing reality is that most IT organizations in 2023 continue to have a technology domain or tower orientation, and very few have defined their services beyond the need to enable end-user service request automation. Considering that modeling services is the overall goal of service configuration management, it is an obvious organizational constraint.

Data governance and management: A popular principle of the DevOps movement is referred to as Conway’s Law: This is an IT theory created by computer scientist/programmer Melvin Conway in 1967. Conway’s Law states that “Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations.”

In summary, organizational structure dictates design and, in this case, our data governance and management approach. In my original blog from 2007, CMDB – Spruce Goose, Death Star, or Answer to World Peace?, I described how that when IT systems are designed, they are designed as systems and are typically represented using unified modeling language (UML®).

What is unified modeling language: UML modeling is the designing of software applications before coding. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, and physical models) play in the building of a skyscraper.

If you are interested in a deeper dive on this subject, I invite you to check out a Practitioner Radio Podcast: PR 51 – Geeking Out on CMDB Object Models.

However, when these complex systems are deployed into production, we let the systemic view disappear. We manage each class of data in sperate databases handled by their respective domain owner groups. In essence, our data management approach replicates our organizational structure that enacts, once again, the principle of Conway’s law.

CMDB governance and management:

How organizations approach the question of who will maintain and update the configuration management data is a critical success factor in the ongoing sustainability of the CMDB.

In principle, an organization’s data management approach should be systemic where a CMDB is just one element of an overall configuration management system (CMS).

A configuration system may require the integration of multiple tools, share a common architecture, and provide an overall informational view of various data sources and discovery tools.²

In essence, there are two perspectives or approaches to how most organizations view the overall purpose of the CMDB/CMS. These two different views identify how an organization will establish who will be responsible for maintaining and updating the CMDB data integrity and currency:               

Approach one: A CMDB is critical to all IT management processes and functions.

The CMDB is a trusted data source used by all IT management functions and processes. The effort is made to consolidate and centralize most, if not all, the similar data sources into the CMDB. Other data sources will be linked/federated only where it makes sense.

Approach two: A CMDB exists to support a narrow scope of IT processes.  

The CMDB is a data source used only for processes such as change management and incident management, and there is no reason for data source consolidation from existing domain-based sources. Everything will stay where it is, and desired attributes and data will be cherry-picked and replicated into a centralized CMDB record that ensures they are up to date through reconciliation.

In approach one, the data management is distributed to the appropriate data owners as well as a small team of people who support the overall CMDB governance and strategy.

In approach two, the data management is delegated to a small team of people, possibly even one dedicated person who is tasked with working with distributed data owners to keep the CMDB up to date for everyone else.

The first approach is the only viable way to maintain your CMDB data integrity, and the second is doomed to failure every time due to MANY different reasons – the most important one being the inability to scale. Unfortunately, most organizations follow the centralized approach and continually fail miserably and keep trying the same model and expecting different results, which is the definition of insanity!

I wrote an article on this subject many years ago that is still very relevant to this day: Viewpoint article, CMDB: The Resort Condominium for IT.

Embrace condo living people!

In conclusion, I am going to use the very same summary of findings that I wrote 16 years ago. However, the opportunity for success is there and the ability to be successful is enabled through advancements in automation. It’s required by legislation and has never been more necessary; so, it is critical that we understand that a lack of success is not about:

• A lack of knowledge
• A lack of intelligence
• A lack of resources
• A lack of tools

We have all the above. Our continued challenges with the CMDB can be summarized as:

• A lack of organizational will
• A culture of silos based on structure (Conway’s Law)
• Leadership that is willing to address these two obstacles

Here is part of the conclusion to my original blog:

In summary, consider that the process of configuration management and your CMDB strategy is a difficult but necessary element of being a service organization. It is without a doubt a challenge to achieve, but I would submit that the most difficult part of this challenge is based on culture and organizational change issues rather than technology constraints – as some would have you believe.

The implementation of configuration management is always done in multiple phases according to reasonable scope decisions. The update of this database through either manual or automated means is more akin to brushing your teeth than the uptake of a new and exciting hobby. Configuration management is not rocket science, the Spruce Goose, the Death Star, or the answer to World Peace – but it does represent a basic building block to support the move from a technology to a service-centric IT management approach.

Troy's thoughts, what are yours?

Like this article? 3 likes

Post a comment

Your comments:

Your name:

Your email:

Remember my personal information
Notify me when someone replies

Please type this word:

• Previous Post
• Home
• Next Post