Most CMDBs are missing up to 40% of the devices that actually exist in the network. The result? Bloated renewal costs, unmanaged assets, and stalled automation projects.

Join IP Fabric and NTT Data for a practical session on how to close the gap between your CMDB and network reality. 

You’ll learn how to:

• Eliminate wasted spend tied to outdated inventory.
• Identify unmanaged or misclassified assets.
• De-risk automation and change management with dependency mapping.

Ready to re-build trust in your CMDB? Watch the full webinar on demand.

Joe Kershaw: Thank you for joining us. To my esteemed guests, thank you for joining us as well. My name’s Joe Kershaw. I lead our European revenue function in sales as well as some of our global strategic partnerships, which one of which is, the guys from NTT Data. Today, we’re gonna have a discussion and a technical demonstration focused on CMDBs and the constant problem of accuracy challenges.

I’ve been speaking with one of our team just over the last couple of days about one of the big European banks that’s already integrated their network digital twin deployment into an instance of NetBox for automation. They’re now integrating ServiceNow CMDB to get that asset governance as a foundational aspect. And the third phase of this integration plan is to build a compliance dashboard and start defining metrics and looking at leadership level service insights based on the foundation of accurate data. So this is as relevant as I've ever seen a challenge, and the solutions are really exciting.

So I think it’s a really good time for us to be having this discussion. We’re gonna do a quick round of introductions, and then we’ll dive straight into a discussion before handing it over, for a bit of a demonstration as well and opening up for Q&A. 

So first of all, Rob, if you could, take the microphone for a quick introduction.

Rob Mello: Awesome. Rob Mello, part of NTT Data. Global head of network solutions and architecture.

Joe K.: Thanks, Rob. Andre?

Andre van den Berg: I’m Andre van den Berg. I head up our delivery center in The Czech Republic based in the lovely city of Prague. Not too far away from you, Joe. I’ve been in IT frontline operations for more than twenty years. So configuration management and CMDB accuracy is something that I deal with on a constant basis.

Joe K.: Nice. Seb?

Sebastien d’Argoeuves: Hello, everyone. I’m Sebastien d’Argoeuves, a solution architect at IP Fabric. Before joining IP Fabric, I was wearing a different hat as a network engineer and also dealing a lot with, like everyone else, CMDB accuracy. It always was a key challenge.

Joe K.: You guys are working with some of the world’s largest, most critical enterprises on a daily basis. Rob, could you get us started and just give us a bit of the view?

How Big is the CMDB Accuracy Problem? 

Rob M.: CMDBs are just fraught with issues and challenges. They’re major, they’re persistent, and oftentimes they’re underestimated problems for enterprises. You can look back to many, many, many different studies over the past two, three, four years. All of them come to the same conclusion: CMDBs failed to deliver accurate, reliable, and actual data. Oftentimes, this really has an undermining of IT operations, how you could drive automation, and enable compliance efforts.

I think a Gartner study last year noted that over 75% of CMDB initiatives actually failed to deliver expected outcomes due to poor data quality and data governance. And similarly, ServiceNow who live, eat, and breathe CMDB, noted that about eighty percent of all CIs and many CMDBs are outdated because of missing attributes or incorrect links. 

The thing I wanna point out too is CMDBs aren’t just a database. Right? A lot of people think it's just a static thing, but it's really the foundation for your process and your operational frameworks. 

• Incident management: Driving troubleshooting and root cause analysis. 
• Change management: Introducing changes, managing releases, deploying version controls. 
• Asset management: Tracking the life cycle of every asset to get the most value from planning, design, implementation, and management to disposal. 
• Compliance auditing: Reporting to meet exponentially rising regulatory demands. 

The bottom line is: if the CMDB is inaccurate, these processes will all break down, and it creates a cascading operational waterfall of risks and challenges and gaps.

Joe K.: Heavy. The problem’s been around for the last twenty years, probably even longer…

Why Is It Important to Fix CMDB Accuracy Now? 

Rob M.: The point is we should have changed before, but I think when you really take a look at what the world we’re living in, IT complexity and the velocity of change are driving at an accelerated rate. Adopting the cloud, enabling more SaaS-based solutions, implementing microservices, enabling containerization, the number of CIs… The speed of change continues to increase. Having an outdated, fragmented CMDB data becomes a huge liability.

Technical debt’s something to consider, too. We continue to struggle with technical debt, but the challenge of legacy configuration creep continues to grow. Many organizations actually delay CMDB maintenance until later because they think they need to focus on other priorities and initiatives. And what happens is data becomes stale, inconsistent, duplicated, and the reality is the longer that you wait, the larger the cleanup overhead is. People and organizations don’t realize how much of a cleanup effort it may be.

All the while, risk windows continue to widen. So the more that you have a misconfigured or an unknown dependency, that can cause more downtime, outages, security breaches, which then more audit compliance, paying of demands and fines. If you improve your CMDB accuracy, you’re assuring your operational teams and your processes and your technology and tool stack is actually up to date and secure. 

And then we have strategic initiatives like cloud migrations. Every enterprise in the world is going through some sort of cloud migration today. Or going through some level of service rationalization or cost optimization. If you don’t have accurate infrastructure and service maps from your CMDB, or your CMDB is broken, these initiatives are going to be difficult. 

More and more sectors are demanding proof of asset infrastructure management. Proof of change control, configuration, and visibility. I was working with a client last week where they needed to show changes to code and command line changes within a configuration item, as well as a config to prove it back to an auditor. 

If you continue to go down this path of inaccurate CMDBs, operations will suffer. You might see longer incident resolution times because you don’t know what’s there, or what’s been impacted. Mean Time To Innocence (MTTI) is stretched longer and longer. You may see a higher risk of change-induced outages because if you can’t assess true dependencies, or have untracked legacy devices, you’re not being able to understand how to support that.

Then there’s obviously the cost of support and maintenance. Many organizations think they have a good view of their maintenance strategies, and are optimizing the maintenance cost by utilizing assets as best they can, making sure they’re not redundant services.

All this has a big impact on planning and decision making. How can you keep up with the rate and the change of the market and be competitive in your vertical industry if you don’t have trusted data they can source?

If you can’t keep up with all this, it means slower time to market for business changes and IT. The bottom line is: enterprises need to have a rich, valued, and accurate CMDB to drive the change that they need.

Joe K.: That’s really good. I’ve picked up on a few things within the notes, particularly where you’ve said “CMDBs aren’t just a database.” You’ve mentioned this delayed maintenance because people have got other priorities. The longer you leave a CMDB, believing it’s not a priority, the larger the impact. You’ve mentioned the potential impact operationally, too. So knowing that it goes beyond the list of assets, interdependencies, and understanding your service. There’s obviously a critical gap in how people organize teams, how they invest, how they organize, prioritize. That’s got massive impacts on service delivery.

Andre, if you could give us a bit of insight from your view…

What Are Common Mistakes Involving CMDB Accuracy? 

Andre V.: I think Rob touched on quite a number of points already, but if I can talk about two recurring patterns that I see is, the first is ownership ambiguity. Nobody explicitly owns the CMDB accuracy. Network team thinks infrastructure is doing it. Infrastructure thinks network’s doing it. It just falls into a gap. Without accountability, it just decays over time.

I think the second recurring pattern is dependency mapping. We’ve touched on this quite a few times already, but it’s critical. Organizations tend to focus on cataloging devices. “I’ve got 500 firewalls. I’ve got 200 switches.” But they miss the actual service of dependency mapping. And in incident response, that that’s critical.

You need to know: if this device fails, what breaks, what’s connected to what? And most CMDBs don’t have that information. Or the information is wrong. It requires constant discovery and maintenance to get a CMDB correct. 

CMDBs are hard. I mean, make no joke. It’s a hard thing to get right. And if a crisis hits and you don’t understand your dependencies, response time just explodes. This is a real thing we see in operations daily.

Joe K.: What are some of the implications that you’re seeing across these big organizations that need your help? What are some of the implications you’re seeing across the organization where this isn’t properly addressed?

Andre V.: What I’m seeing at scale is there’s a trust problem that cascades. When your CMDB is unreliable, teams stop using it. Say a team builds their own little repositories of spreadsheets. How often have you seen an export of a CMDB into Excel, and you start cleaning it up? These things live in all types of repositories all over your organization. There’s different wikis and then there’s tribal knowledge. You've got critical instruction knowledge living in people’s heads. Now you’ve got all these different sources and no single source of truth. And then if you decide to outsource to a new MSP, this becomes catastrophic.

We’ve seen organizations where they effectively set themselves back 12 months or even longer because the incumbent provider can’t trust in your inter-documentation. Reverse engineering the network costs time and an excessive amount of money.

What Rob also touched on is that new initiatives—like AI and automation and agentic AI—need reliable sources of data. And you can’t start those initiatives if you can't trust your CMDB, which would be the root for that data.

Joe K.: But everyone is rushing ahead trying to start those initiatives, aren’t they? 

Andre V.: They’re starting out without fixing the problem that needs to be the base.

Joe K.: I listen to a lot of podcasts at the moment. They’re waiting for the AI bubble to pop, and they’re saying it’s only going to take a few of these big enterprises to say, “Actually, we’re going to pull back our AI investments because we’re just not seeing the ROI possible.” I can imagine this being one of the foundational elements that people aren’t taking seriously. They’re trying to deliver the value on a baseline of poor data quality.

Andre V.: However, you can use AI to assist in your CMDB. You need to fix the source even if you fix the source with AI.

Joe K.: Interesting. Maybe that’ll pop up in the questions once we’ve, once we’ve finished the demo. Andre, you say that at the delivery level, you’re seeing a cascading lack of trust, which is a huge burden for operational processes. Rob, I know with your position as VP of Solution Architecture, you’re speaking quite often to the C-level and leadership that are looking to drive an organization forward. Are you seeing ramifications at leadership level in the same organizations that are struggling with trust at the operational level?

Rob M.: Yeah. There’s a fear and a clear lack of ownership. So it’s a fear of losing ownership, and it’s a fear of “We need to be an integrated culture organization.” We see network integrating security with SaaS initiatives. We see development operation teams needing to integrate together.

But if we don't have these sources of truth, how do teams integrate together? You're just continuing to exacerbate that problem of siloed teams trying to operate on their own. They’re not the issue here because they don't trust the data. But then organizations continue to drive the projects without really working and integrating them holistically. And that bubbles up to the exec level. Having an organization that can really enable and execute these massive cloud transformations or network modernization initiatives, you have to have that leadership aligned. You have to have the organizations integrated together to work and function.

What Can Organizations Do To Fix CMDB Accuracy?

Joe K.: It all feels a little bit overwhelming and fear monger-y. It’s a good reason that we’ve brought Seb along to show us that it doesn’t necessarily need to be. 

But I think one thing I will stress here is, as I mentioned at the very outset of the call, is that I’ve been speaking to a European bank. The first step was NetBox integrations driven by their automation team. They know they need to move fast with automation, so they needed a source of truth, but couldn’t trust their CMDB. So they’ve done something in one of these “repositories,” as Andre mentioned. 

The next step is building a network digital twin for their CMDB, and making sure these systems are updated. And then they can start leveraging the next level up of reporting based on this clean data to start tackling the operational level trust issues. 

And then we start seeing the leadership programs—SD-WAN migrations, cloud migrations—which, in the past, may have had a six-month window for due diligence, data collection, documentation, analyzing, and more. Can we trust the service provider? Is that consultant really telling us the truth?

All of that stuff disappears because they’ve built this foundational integration. What I’m gonna ask Seb to show us is one piece of the picture. How do you take this accurate data and put it into ServiceNow within the CMDB? All of these topics that we’ve discussed, they’re addressable steadily over time by working with the right partners to build the right road map so you can eat the elephant one bite at a time.

So, Seb, I’ll hand it over to you, and you can show us how to bite an elephant one bite at a time. No pressure.

Seb D.: You better be hungry then. This is a quick demo of IP Fabric and our extension with ServiceNow. What I’m going to use is one demo environment that we have. It’s a virtual lab. What you can see in this screen is one of the snapshots. So in this situation, we’ve got two.

You’ve got one that was the same network before a change and the one that you've performed after a change. Maybe you want to see what has changed between those two snapshots. We can compare the diagrams. What this would highlight is things that were not present before. The key part I want to focus on is the fact that two devices were not present before. And now that we’ve done the new snapshot, we can see that they've been added to the network. So that’s kind of the main part where we’ve got the network change. There are always changes happening. And now what happens is we’ve added new devices. But has it been reflected in the CMDB correctly?

We’re going to look at it from this extension, which helps by doing the synchronization with ServiceNow. And I also have an instance of ServiceNow in here where I’ve already got a number of devices, and this would be the state of my CMDB at a given moment in time.

So now that we’ve got the app running, I just need to synchronize it. The only thing that I’m doing with this extension is I’m synchronizing it with my ServiceNow instance. And on the other side, because I’ve run it from IP Fabric, it’s already aware of the snapshot that I have. Again, each snapshot is a picture of the network.

So the first run that we’re going to do is to compare what we have in the new snapshot, or the one that we’ve done after the change. I’m going to do it as a dry run because I don’t want to write anything to ServiceNow at the moment. It’s going to compare the inventory that we have in IP Fabric—the things that we’ve discovered from the network devices—and show me the comparison between what we have already in ServiceNow.

Now what you’re already able to see here is that we’ve got a number of differences that we spotted, and we can go through that in detail. But we’ve got three devices that IP Fabric has seen, which are not present in ServiceNow, five in ServiceNow but not in IP Fabric, and four differences.

So I could drill down, find more detail, and I’m going to focus especially on one in here where it’s a common mistake that, unfortunately, I’ve seen many times before. We found this device, and it’s not present in ServiceNow. Plus the two that we know we’ve added after the change.

Now we've got three new devices that we’re going to push into ServiceNow. Similarly, you can get more detail the other way around, where maybe you’ve got devices that are present in your CMDB, but maybe they’re not reachable.

We know that this device was present before and after, but, for example, you can see what is different in this one is the login IP. We see that the information we have is different from the information we have in ServiceNow. So in that case, this is going to be overwritten, and we’re going to update the information in ServiceNow. After we do that, I’m just going to push the change, and then we’ll move to ServiceNow to see what information we can see in that. 

Now I have 97 devices. I know this one takes a few extra seconds to get new devices, and now I’ve got a few more devices. This is the one I wanted to look at. There is the device that wasn’t present in ServiceNow, but was in IP Fabric. I’ve made it fairly obvious for the eyes that are used to working with CMDBs—we all know that there is a typo. Someone’s going to confuse the zero and the o, which may not seem like much. But when you’re starting to work with a CMDB, that cell number becomes critical because it’s the unique ID for your device.

Now the impact for that is: if you’ve got the wrong cell number, your maintenance contract may not correctly reflect what you’re paying the maintenance for, which means you're potentially not covering the devices that you have. Then it’s probably going to cause some sort of issues later when you’ve got a problem with the device, or you need to do an RMA.

In that situation, someone has entered the one with the four o’s, where the correct one was the one with the zeros. So the only difference we see in here is the date, where now this one is no longer the most recent, and the correct one is this one.

What’s important with the current extension is that IP Fabric is not going to remove entries from the CMDB because that needs to follow a correct process. The goal is not to decommission or remove something from that CMDB, but to have now the accurate information. 

If I go back to the diagram, it’s representing the relationships between devices in ServiceNow. You’d find the same in other CMDBs. You can use this to know if there’s an impact or a change affecting one device, or if there’s anything else that's going to be affected by this change. 

We’ve built a relation map between the devices. So now it means if I look at one device, I know that the information I’ve got in here is up to date because I’m running the sync on a regular basis.

But I can also start using the dependent view to know that if a given device is affected, then the other network devices that are around it could also be affected. This is where we started, but obviously this needs to go further to then be able to map to the CI. In the server, that could be connected to your switches to have the full mapping between an application all the way to the network. I’d know that if I’m doing a change on that device, here’s what the business impact would be. 

Joe K.: Thanks, Seb. I’m just gonna recap that last piece: The current state of the CMDB integration that we’ve just shown there is assets as well as dependencies at the network level. Then we do have customers that are populating the server and storage information using other tooling. There are also elements within the IP Fabric roadmap across the beginning of next year about application awareness within network digital twins. So how do you map those applications into your network infrastructure? 

We’re gonna wrap up shortly, but first open up for some potential Q&A. I’ll see if we’ve got any questions in the queue. If you’ve got any “Q,” we should have the “A,” hopefully.

Q&A

What’s the First Step to Improve CMDB Accuracy? 

Andre V.: I think as a start, you need to assign an owner. Someone needs to own CMDB accuracy, and then you need to decide what you want to do. Your data could be 100% accurate, but if there’s no value to it, then it’s pointless. You got an accurate CMDB, but it’s not functional. So I think ownership, making sure that the data that you want to implement is valued. Plus owner service mapping, dependencies, that type of stuff.

Joe K.: How are you seeing the different approaches to ownership? I know you said before when you raised this bottleneck. It’s the network and infrastructure teams pointing at each other and no one really owns it. Are you seeing the ownership sit successfully in either organization? Is it better if ownership is assigned to one?

Andre V.: I think the ownership of the CMDB does not necessarily sit in those teams. It is a function of your cross-functional services as a configuration manager. That person will be responsible for the accuracy of the CMDB. Because as Seb showed there, there’s a delta that was created. Whose responsibility is it to sort out that delta? Is it NetOps? Is it infrastructure? It’s the configuration manager’s duty to sort that out. And you will find that in a lot of organizations. It’s someone’s secondary job perhaps. 

Joe K.: In the ideal world, is there an internal alignment documented on the importance of this? There's the value (e.g. “which attributes are we gonna track?”), and then an assigned cross-functional person or team that' s able to hold people to account.

Andre V.: Yes. It lives outside of network and infrastructure teams. It’s a function that sits across all those teams, hence the word “cross-functional” in this case.

What Metrics Should Be Used to Track Your Progress with CMDB Accuracy?

Rob M.: So from a metrics standpoint, completeness is one. Accuracy, freshness. How frequently your CMDB is updated and maintained. Then you can get into levels of version control and things on that layer, but I keep you those top three metrics.

Andre V.: I think one very important one is if there’s still tribal knowledge about critical infrastructure left in your organization, then you have failed. So if there’s someone in your organization that knows about a certain part of your network or environment and it’s not in the CMDB, then you have absolutely failed. I think that’s probably one of the critical ones that front-end operations rely on. 

Rob M.: I completely agree. Ownership is number one. Metrics is number two. Then the only thing I’d add on to that is what we just demoed: having a tool that drives network verification observability is paramount. You have that source so you can actually enable a more dynamic, federated CMDB and move away from the archaic Excel spreadsheet world that a lot of people live in.

Joe K.: A nice final point there. That does actually lead to a couple of the questions that were raised during the demonstration set. One of them was asking whether the synced fields are customizable…

How Flexible is the IP Fabric Integration with Your CMDB? 

Seb D.: So at the moment with the current state of the extensions, the one I was showing is set in the code.There is no customizable field of if you wanted to bring specific information. I know we’ve mentioned NetBox as an example where the data was going from IP Fabric to NetBox. It’s a lot more customizable where you can have a lot more data that would be pushed. So that’s something that can be further improved.

Joe K.: That’s if a user was looking to use our extension and plugin capability that already exists. But I'd say a very large number of our customers that have this integration built with ServiceNow, they’ve done it with the support of a trusted partner. So the flexibility is complete, and you can design and build that integration as required.

There was one more question, and this was going back to your point, Andre. It may be opening up a can of worms just as we’re ready to wrap up…

Is There an AI-based Approach for Managing CMDB Accuracy?

Andre V.: Absolutely. I think that configuration management is a process. If you’ve got the switch where the application’s plugged into or the service is plugged into, that data is not necessarily inside of IP Fabric. But you can then create an agent in that part of the process to look at what is on that switch, go look at the applications that live there, and even, perhaps. produce that mapping for you. But that’s just a step in the process. You need to define the process to be able to get to those steps. 

Most processes can have some part of a genetic AI in it, and this is absolutely one of them. But you need to have the process first. You can’t just start plugging in AI.

Joe K.: That’s the end of the questions that we've got through the chat, so I would suggest we wrap up there. So thank you to Rob and Andre and Seb. 

As a quick wrap up, we’re seeing the adoption of network digital twins rise very rapidly these days, and we’re seeing the maturation within the market where people aren't seeing this data—this platform—as a standalone tool. They’re saying, “Okay, so now we’ve made our complex network understandable, observable, available in a structured data format. What should we be doing next?”

Integrations, new dashboards, leadership leadership level insights. There’s quite a wide range of integrations that we’re seeing, and new opportunities that are arising. And the strategic partnership that we’ve got with the guys at NTT Data is the finishing part to the puzzle to help organizations get the best from this network data. 

Anyone that’s within the audience today that wants to have a follow-up session, reach out to your NTT Data account team or reach out to your IP Fabric account executive or the solution architecture team, and we’ll be able to get the right stakeholders together to do a more detailed session. We’ll help you build that roadmap to an accurate CMDB, make sure it’s integrated, so you can leverage it to deliver that business value.

So, again, I’ll say thank you, gents, and then we’ll wrap up.

“Unlock CMDB Accuracy: The Hidden Key to Cost Savings, Automation, and Risk Reduction” is now available on demand.

Ready to re-build trust in your CMDB? Our expert team is here to guide you through it. Reach out, and we’ll contact you to set up a personalized demo.