Skip to main content

CMDB Systems: Some Key (and Surprising) Findings from Deployments

Dennis Drogseth

In writing CMDB Systems: Making Change Work in the Age of Cloud and Agile, we gained a lot by talking to deployments. In the spirit of our own recommendations for how to manage and optimize a CMDB-related initiative, our goal was to learn from reality more than just preach a series of best practices. What I’ve chosen to write about here are just a few highlights, following four key areas of interest:

■ Dialog, Communication and Stakeholder Planning

■ Architecture

■ Cloud

■ Agile

Start with: CMDB Systems in the Age of Cloud and Agile - Why We Wrote the Book

Dialog, Communication and Stakeholder Planning

Taking the time to engage stakeholders effectively is one of the bigger challenges in any strategic IT initiative, and one of the biggest single catalysts for CMDB success. One of the problems, of course, is time and energy to engage in something new, no matter how valuable, when most IT professionals are already overworked and trapped within their own treadmills.

The Hamster Scenario
“Cultural challenges were a big factor — in getting the silos to think about new ways of working together. Something like what I call the “Hamster Scenario” running around its wheel. You’ve got some processes in place and you’re used to those processes. When do you step back and change those processes? In other words when does the hamster get off its wheel and think it might move in other directions?” (a transportation/travel company from Chapter Eight)

Next is a comment in both the challenge and resolution category about dealing with a very different concern — too much enthusiasm, and with it, too many expectations:

Challenge/resolution: Trying to please everyone
“When we discussed the CMDB with different groups in our organization, each team got very excited about what they wanted to get out of our CMDB. But very quickly we could see that many of their priorities were at least a couple of years away from implementation. So everybody’s understanding of the scope was different. For instance, we had desktop people saying 'can I inventory my mouse? Can I inventory my keyboard and my monitor?' They all wanted to see those as CIs.

“But managing this wasn’t too difficult. I asked everyone two questions; first, ‘What is this equipment that you’re prepared to manage from day one through its entire lifecycle as a CI?’ And second, ‘Do you have the resources to manage these items as CIs once they get into our CMDB?’ If there were no costs associated with CI inclusion, then everyone would want everything included in the CMDB right at the start. But as soon as they begin to understand the costs, including update and data access costs, they viewed it differently.” (a manufacturer from Chapter Four)

Architecture

Image removed.We spend a lot of time in the book looking at architectural challenges, including a very progressive technology landscape as it’s evolving to support more dynamic and complex service interdependencies. Below are just two perspectives, the first on service modeling, and the second on assimilating multiple data sets.

Service models vs. data models
“Our Service Model is based on ITIL’s definition, and it’s all about the processes, functions, services and technologies that we deliver to our customers. So therefore it’s a separate idea that can be applied to the data model. Our Global Finance team defines our business strategies company-wide. And these are of course not about a data model or technology. But that’s where we started, so we can trace everything we do back to those business services.” (manufacturer from Chapter Four)

Assimilating and reconciling many multiple sources
“Each discovery tool has its own idiosyncracies in terms of what it captures and how it works. This impacts both our ability to manage it and our ability to optimize our hardware and software asset investments in terms of utilization and licensing. With our integrated data analytics, we’re leveraging 35 different discovery tools in order to get a more cohesive 'golden record' for the CMS ... This includes desktop security, network management and administration, application dependency mapping, systems management and administration, asset management solutions, and BSM performance management, just to mention a few categories.” (a financial services company Chapter Nine)

Cloud and Agile

Since our book does its best to focus on the very current landscape of cloud and agile, I thought it fitting to end with two excerpts — one on each point. I think both are a bit surprising as well as insightful, but I’ll let you decide which might raise more eyebrows.

Cloud
“... the general idea is to leverage ADDM visibility for consistency across the cloud and hybrid cloud environments — so that you can identify servers that are not registered in your configuration management tools. Another example of the value of this type of visibility is keeping track of the Amazon Machine Images (AMIs), which can potentially lead to malware and other problems. There are over 30,000 community AMIs and not all of them are patched correctly, so if a developer decides to use one that’s not authorized it may cause problems. When that happens, ADDM can help to identify and remediate the problem.” (a software manufacturer from Chapter Fifteen)

Agile/ DevOps
“Before investing in the CMDB we were very fragmented in how we saved information. Some of it was in Visio, for instance. Some were in OneNote or in Excel. We also had a lot of Word documents — so it was difficult-to-impossible to get insight into impacts when we were about to make a change …

“At that time, development was a little bit ahead of operations in terms of maturity. Our operations organization was fairly siloed and hadn’t yet invested in best practices. We often had no clear idea what would happen if, for instance, we unplugged a server. Most of our change records there resided inside someone’s head … If somebody was sick at the wrong time, it could be very disruptive …

“But we did have some [scrum] best practices that had evolved in development for source control. So when we saw what a CMDB could do, we felt we had a chance to transform our way of working when it came to managing change.” (a mid-tier financial planning company from Chapter Fifteen)

All right, I’ll be candid. Probably the biggest single “revelation from the trenches” for me was this last — a development team purchasing a CMDB to support an agile environment using scrum and pushing it into operations.

The point being in these and other insights is that each deployment shares common challenges with other deployments, on the one hand; but is also distinctive on the other hand. The goal is, invariably, to find the best path for you — while learning from the many other voices of wisdom and experience available. And this was, perhaps, the single most pervasive "guiding light" in seeking out optimal content for our book.

Hot Topics

The Latest

Pilots are everywhere, stakeholders are seeking results, businesses are pushing for new tools, and IT teams are being asked to make AI secure, reliable, and useful at scale. But as organizations move from testing AI to operationalizing it, many are discovering that the biggest barrier is not the model, the use case, or even the budget. It is the file data foundation within ...

Fast or cheap? For most of my career in engineering, speed and quality sat on opposite ends of a seesaw. The "OR" in "fast or cheap" was non-negotiable. It was expected that pushing for faster releases meant that something in quality would give way. Tightening quality controls meant the schedule slipped. Every engineering leader I know has lived some version of that tradeoff ... The seesaw is starting to level out ...

I have been building enterprise software for more than 20 years ... One thing stays true across all of it: You do not find out your foundation is wrong during the crisis. You find out when the debt comes due. For a lot of organizations, that bill is arriving now. New research ... puts hard numbers on something practitioners have been sensing for a while. The telemetry problem isn't coming. It's already here ...

The rapid growth of AI workloads is pushing traditional log management approaches to their limits, according to The State of Log Management 2026 report from Dynatrace. Modern logs have become critical to understanding, validating, and securing AI-driven decisions, helping organizations ensure reliability, compliance, and performance at scale. However, the volume and complexity of AI telemetry are overwhelming legacy tools ...

For years, secure connectivity has relied on a familiar pattern: route traffic back to centralized gateways, inspect it, and then allow access. This model worked when applications lived in a handful of data centers and users were largely confined to offices. That model is now under strain. Applications are distributed across clouds, users connect from everywhere, and real-time workloads demand performance that centralized inspection points struggle to deliver. As traffic volumes grow and latency expectations shrink, routing everything through a small number of control points has become both a performance bottleneck and a resilience risk. The future of secure connectivity requires a different approach ...

The AI experimentation phase is over, and the private cloud is where enterprise AI workloads are being deployed for security and scale, according to Private Cloud Outlook 2026, a new report from Broadcom ... 2026 marks an acceleration into a full AI tipping point. The shift is being shaped by three forces — costs, complexity, and control — that public cloud environments are increasingly failing to address for production AI at scale. Key findings from the report include ...

44% of organizations have reported an outage in the past year tied to suppressed or ignored alerts, and 78% had at least one incident where no alert was fired at all ... Engineers learned about failures from customers. That gap between what our tools report and what our customers experience is the problem DevOps teams have been quietly solving with GenAI tooling, even as most enterprises continue to run their NOCs on manual alert triage ...

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...

CMDB Systems: Some Key (and Surprising) Findings from Deployments

Dennis Drogseth

In writing CMDB Systems: Making Change Work in the Age of Cloud and Agile, we gained a lot by talking to deployments. In the spirit of our own recommendations for how to manage and optimize a CMDB-related initiative, our goal was to learn from reality more than just preach a series of best practices. What I’ve chosen to write about here are just a few highlights, following four key areas of interest:

■ Dialog, Communication and Stakeholder Planning

■ Architecture

■ Cloud

■ Agile

Start with: CMDB Systems in the Age of Cloud and Agile - Why We Wrote the Book

Dialog, Communication and Stakeholder Planning

Taking the time to engage stakeholders effectively is one of the bigger challenges in any strategic IT initiative, and one of the biggest single catalysts for CMDB success. One of the problems, of course, is time and energy to engage in something new, no matter how valuable, when most IT professionals are already overworked and trapped within their own treadmills.

The Hamster Scenario
“Cultural challenges were a big factor — in getting the silos to think about new ways of working together. Something like what I call the “Hamster Scenario” running around its wheel. You’ve got some processes in place and you’re used to those processes. When do you step back and change those processes? In other words when does the hamster get off its wheel and think it might move in other directions?” (a transportation/travel company from Chapter Eight)

Next is a comment in both the challenge and resolution category about dealing with a very different concern — too much enthusiasm, and with it, too many expectations:

Challenge/resolution: Trying to please everyone
“When we discussed the CMDB with different groups in our organization, each team got very excited about what they wanted to get out of our CMDB. But very quickly we could see that many of their priorities were at least a couple of years away from implementation. So everybody’s understanding of the scope was different. For instance, we had desktop people saying 'can I inventory my mouse? Can I inventory my keyboard and my monitor?' They all wanted to see those as CIs.

“But managing this wasn’t too difficult. I asked everyone two questions; first, ‘What is this equipment that you’re prepared to manage from day one through its entire lifecycle as a CI?’ And second, ‘Do you have the resources to manage these items as CIs once they get into our CMDB?’ If there were no costs associated with CI inclusion, then everyone would want everything included in the CMDB right at the start. But as soon as they begin to understand the costs, including update and data access costs, they viewed it differently.” (a manufacturer from Chapter Four)

Architecture

Image removed.We spend a lot of time in the book looking at architectural challenges, including a very progressive technology landscape as it’s evolving to support more dynamic and complex service interdependencies. Below are just two perspectives, the first on service modeling, and the second on assimilating multiple data sets.

Service models vs. data models
“Our Service Model is based on ITIL’s definition, and it’s all about the processes, functions, services and technologies that we deliver to our customers. So therefore it’s a separate idea that can be applied to the data model. Our Global Finance team defines our business strategies company-wide. And these are of course not about a data model or technology. But that’s where we started, so we can trace everything we do back to those business services.” (manufacturer from Chapter Four)

Assimilating and reconciling many multiple sources
“Each discovery tool has its own idiosyncracies in terms of what it captures and how it works. This impacts both our ability to manage it and our ability to optimize our hardware and software asset investments in terms of utilization and licensing. With our integrated data analytics, we’re leveraging 35 different discovery tools in order to get a more cohesive 'golden record' for the CMS ... This includes desktop security, network management and administration, application dependency mapping, systems management and administration, asset management solutions, and BSM performance management, just to mention a few categories.” (a financial services company Chapter Nine)

Cloud and Agile

Since our book does its best to focus on the very current landscape of cloud and agile, I thought it fitting to end with two excerpts — one on each point. I think both are a bit surprising as well as insightful, but I’ll let you decide which might raise more eyebrows.

Cloud
“... the general idea is to leverage ADDM visibility for consistency across the cloud and hybrid cloud environments — so that you can identify servers that are not registered in your configuration management tools. Another example of the value of this type of visibility is keeping track of the Amazon Machine Images (AMIs), which can potentially lead to malware and other problems. There are over 30,000 community AMIs and not all of them are patched correctly, so if a developer decides to use one that’s not authorized it may cause problems. When that happens, ADDM can help to identify and remediate the problem.” (a software manufacturer from Chapter Fifteen)

Agile/ DevOps
“Before investing in the CMDB we were very fragmented in how we saved information. Some of it was in Visio, for instance. Some were in OneNote or in Excel. We also had a lot of Word documents — so it was difficult-to-impossible to get insight into impacts when we were about to make a change …

“At that time, development was a little bit ahead of operations in terms of maturity. Our operations organization was fairly siloed and hadn’t yet invested in best practices. We often had no clear idea what would happen if, for instance, we unplugged a server. Most of our change records there resided inside someone’s head … If somebody was sick at the wrong time, it could be very disruptive …

“But we did have some [scrum] best practices that had evolved in development for source control. So when we saw what a CMDB could do, we felt we had a chance to transform our way of working when it came to managing change.” (a mid-tier financial planning company from Chapter Fifteen)

All right, I’ll be candid. Probably the biggest single “revelation from the trenches” for me was this last — a development team purchasing a CMDB to support an agile environment using scrum and pushing it into operations.

The point being in these and other insights is that each deployment shares common challenges with other deployments, on the one hand; but is also distinctive on the other hand. The goal is, invariably, to find the best path for you — while learning from the many other voices of wisdom and experience available. And this was, perhaps, the single most pervasive "guiding light" in seeking out optimal content for our book.

Hot Topics

The Latest

Pilots are everywhere, stakeholders are seeking results, businesses are pushing for new tools, and IT teams are being asked to make AI secure, reliable, and useful at scale. But as organizations move from testing AI to operationalizing it, many are discovering that the biggest barrier is not the model, the use case, or even the budget. It is the file data foundation within ...

Fast or cheap? For most of my career in engineering, speed and quality sat on opposite ends of a seesaw. The "OR" in "fast or cheap" was non-negotiable. It was expected that pushing for faster releases meant that something in quality would give way. Tightening quality controls meant the schedule slipped. Every engineering leader I know has lived some version of that tradeoff ... The seesaw is starting to level out ...

I have been building enterprise software for more than 20 years ... One thing stays true across all of it: You do not find out your foundation is wrong during the crisis. You find out when the debt comes due. For a lot of organizations, that bill is arriving now. New research ... puts hard numbers on something practitioners have been sensing for a while. The telemetry problem isn't coming. It's already here ...

The rapid growth of AI workloads is pushing traditional log management approaches to their limits, according to The State of Log Management 2026 report from Dynatrace. Modern logs have become critical to understanding, validating, and securing AI-driven decisions, helping organizations ensure reliability, compliance, and performance at scale. However, the volume and complexity of AI telemetry are overwhelming legacy tools ...

For years, secure connectivity has relied on a familiar pattern: route traffic back to centralized gateways, inspect it, and then allow access. This model worked when applications lived in a handful of data centers and users were largely confined to offices. That model is now under strain. Applications are distributed across clouds, users connect from everywhere, and real-time workloads demand performance that centralized inspection points struggle to deliver. As traffic volumes grow and latency expectations shrink, routing everything through a small number of control points has become both a performance bottleneck and a resilience risk. The future of secure connectivity requires a different approach ...

The AI experimentation phase is over, and the private cloud is where enterprise AI workloads are being deployed for security and scale, according to Private Cloud Outlook 2026, a new report from Broadcom ... 2026 marks an acceleration into a full AI tipping point. The shift is being shaped by three forces — costs, complexity, and control — that public cloud environments are increasingly failing to address for production AI at scale. Key findings from the report include ...

44% of organizations have reported an outage in the past year tied to suppressed or ignored alerts, and 78% had at least one incident where no alert was fired at all ... Engineers learned about failures from customers. That gap between what our tools report and what our customers experience is the problem DevOps teams have been quietly solving with GenAI tooling, even as most enterprises continue to run their NOCs on manual alert triage ...

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...