Name: Unlock CMDB Accuracy: The Hidden Key to Cost Savings, Automation, and Risk Reduction
Uploaded: 2025-11-13T16:02:31.623Z
Duration: 33 min 15 s
Description: Unlock CMDB Accuracy: The Hidden Key to Cost Savings, Automation, and Risk Reduction

Transcript for "Unlock CMDB Accuracy: The Hidden Key to Cost Savings, Automation, and Risk Reduction": So for everyone that's joined, 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 a discussion and a technical demonstration focused on CMDBs and the constant problem of accuracy challenges. I've I've been speaking with one of our team just over the last couple of days about one of the big European banks that is they've integrated already their network assurance deployment into an instance of NetBox for automation. They're now integrating ServiceNow CMDB to get that asset governance as a 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 as I've ever seen a challenge, and 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 a discussion before handing it over, for a bit of a demonstration as well and opening up for for q and a. So first of all, Rob, if you could, take the microphone for a quick introduction. Awesome. So thank you. Rob Mello, part of NTT Data, so global head of network solutions and architecture. Perfect. K. Okay. Thanks, Rob. André? Thanks. Thank you. I'm André. I head up our delivery center in The Czech Republic based in lovely city of Prague, not too far away from you, Joe. And, I've been in IT frontline operations for more than twenty years. So configuration management and CMDB is is something that I deal with on a on a constant basis. Thanks. Nice. Thanks, André. Seth? Hello, everyone. So Sebastien. I'm a solution architect at IP Fabric. And before joining IP Fabric, I was also wearing different hat as a network engineer and also dealing a lot with, like, everyone else, the same DB accuracy. Was, always a key challenge. Perfect. Thanks, Seb. K. So, guys, Rob, André, you guys are working with some of the world's biggest, most critical enterprises on a daily basis. Rob, could you get us started as an and just give us a bit of the view on how big is the the problem we're talking about here with the accuracy of CMD bits? Yeah. Sure. So CMDBs are just fraught with issues and challenges. They're major, they're persistent, and oftentimes they're underestimated problems for enterprises. I mean, 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 to the business due to poor data quality and data governance. And similarly, ServiceNow who, you know, they they live, eat, and breathe CMDB, they noted that about eighty percent of all CIs and many CMDBs are outdated because of missing attributes or they're incorrectly linked. 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 to execute. Incident and problem management are a 100% reliant and dependent upon accuracy seem to be should drive root cause analysis. How you introduce changes, how you do release management and deploy, version controls, critical. Asset management, so how do you track the life cycle of every asset to get the most value from planning, design, implementation, management to disposal? You need a CMDB to track that. Obviously, compliance, auditing, regulatory demands keep growing exponentially, so the reporting for that needs to be underpinned by a strong solid CMDB. Security configuration tracking. Bottom line is if the CMDB is inaccurate, these processes will all break down and and it creates a cascading operational waterfall of risk and challenges and gaps. Heavy. The the problem's been around for the last twenty years, probably even longer. What is it about the here and now? Why why is now the the time to change time to fix this? Yeah. The point is we should have changed before, but really, I think now when you really take a look at what the world we're living in, IT complexity and velocity of change constantly constantly keeps driving at a accelerated rate, adopting cloud, enabling more SaaS based solutions, implementing microservices, enabling containerization, the number of CIs, the speed of change continue to increase. Having an outdated fragmented CMDB data becomes a huge liability. Technical debt, yes. We continue, you know, 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 bigger the cleanup overhead is and people and organizations don't realize how much of a cleanup effort it may be. Another point is risk windows continue to widen. So the more that you have a misconfigured or an unknown dependency, that can trigger more downtime, trigger outages, trigger security breaches, which then trigger more audit compliance, paying of demands and fines, validating and improving 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. Right? Cloud migration. Every enterprise in the world is going through some sort of cloud migration today, going through some level of service rationalization, cost optimization. If you don't have accurate infrastructure and service maps from your CMDB or your CMDB is broken, these initiatives are gonna be completely handicapped. Again, regulatory compliance pressures, again, more and more sectors are demanding proof of asset infrastructure management, proof of change control, configuration and visibility. I I mean, I was working with a client last week where they need to show changes to code and command line changes within a configuration item and a config to prove it back to an auditor. And if you continue to go down this path of integrated CMDB, operations is gonna suffer. Longer incident resolution times because you don't know what's there, what's been impacted. So getting to mean time to innocence becomes stretched longer and longer. Higher risk of change induced outages because if you can't assess true dependencies of your assets or have untracked legacy devices, you're not being able to, you know, understand how to support that. Yeah? Then there's obviously the cost and support and maintenance. So how many organizations have a good view of their maintenance strategies and optimizing the maintenance cost with, you know, utilizing assets as best they can, making sure they're not redundant services. And then obviously, all this has a big impact from, 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? And with all this, if you can't keep up with all this, it means slower time to market for business changes and IT, you know, becomes an impediment. And the bottom line is really we need to have a rich, valued, and accurate CMDB to, you know, harness all this and really put every enterprise at the forefront to drive change that they need. No. That's really good. I I've I've picked up on a few things within the notes, particularly where you've said this isn't it's not just a database. You've mentioned this delayed maintenance because people have got other priorities. The longer you leave this believing it's not a priority, the bigger the impact. You've mentioned the potential impact operationally to of of unknown dependencies. So knowing that it goes beyond the list of assets, interdependencies, and understanding your service. So the valued idea of valued CMDB is obviously a critical gap in how people organize teams, how they invest, how they organize, prioritize, and that's got massive impacts on service delivery. Andre van den Berg, if you could give us a bit of insight from from your view. Where do you see customer service delivery level bottlenecks or missteps or assumptions when people are thinking about, CMDB at at the service level? I think Rob Mello 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. They do it. Network team thinks infrastructure is doing it, infrastructure thinks network's doing it, and it just falls into a gap. Without key accountability, it just decays over time. I think the second is dependency mapping. I think we we've touched on this quite a few times already, but it's actually critical. Organizations tend to focus on cataloging devices. I've got 500 firewalls. I've got 200 switches. But there must actual service dependency mapping. And an 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. All 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 it's a hard thing to get right. And if a crisis hits and you don't understand your dependencies, response time just explodes. And this is a real thing we see in operations staling. And and what are the some of what are some of the implications that you're seeing across these big organizations that that need your help, NTT Data? What are some of the implications you're seeing across the organization where this isn't properly addressed? think what I'm seeing at scale is there's a trust problem that cascades. When your CMDB is unreal unreliable, teams stop stop using it. I mean, say they build their own little repositories of spreadsheets. How often have you seen an export of a CMDB into Excel and you start cleaning it up? And these things lives in all types of repositories all over your organization. There's different wikis and then there's tribal knowledge, which is probably the most important flaw of a of a failed human to be is you got critical instruction knowledge living in people's heads. Now you 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 or even longer because the incumbent or the new provider can't trust in your inter documentation. And then after reverse engineer this this the network and this costs time and excessive amounts of money. And I think what Rob Mello also touched on is these these initiatives like your AI and automation, agentic AI that needs reliable sources of data. And you can't start those initiatives if you can't trust your CMDB, which would be the the root for that data. But everyone everyone is rushing ahead trying to start those initiatives, Yeah. aren't they? They're starting out there without fixing the problem that needs to be the base. Yeah. 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 gonna take a few of these big enterprises to say, actually, we're gonna 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 aren't people aren't taking seriously. They're trying to deliver the value on a baseline of poor data quality. However, you can use AI to assist in your CMDB. fixing as such. So it's a it's a little it's a but you need to fit you need to fix the source even if you fix the source with AI. Interesting. Maybe that'll pop up in the questions once we've, once we've finished the demo. So you you say that, Andre van den Berg, at the delivery level, you see, cascading lack of trust, which is a a huge burden for all of the processes that are ongoing. Rob, I know with your position in 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 trust at the operational level? Yeah. It's it's it's interesting. Right? It's it's a fear and lack of of ownership. So it's a fear of losing ownership, and it's a fear of we need to be an integrated culture organization. Right? We see network integrating security with, like, SaaS initiatives. You see dev development operation teams need to integrate together. If we don't have these sources of truth that are trusted enabled, how do teams integrate together? And it becomes you're discontinuing exacerbate that problem of siloed teams trying to operate on their own, make sure that they're not the issue here because they don't trust the data, and then continue to drive the projects without really working and integrating them holistically. And that bubbles up to the exec level. You know, 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. No. It's just really it's, I'd I'd say we've we've spent ten minutes on this, and it feels a little bit overwhelming and fear mongery, which is the good reason that we've brought Sebastien along to show us that it doesn't necessarily need to be. But I think one thing I will will stress here is, as I mentioned at the very outset of the call, I've been speaking to a 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 their source of truth, couldn't trust the CMDB. So they've done something in one of these repositories almost, as Andre mentioned. But the next step is the network assurance into CMDB and making sure there's true up between these systems. 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, the ideas of tribal knowledge. And then we start seeing the leadership programs, SD WAN migration, cloud migration, that in the past may have had a six month window for due diligence, data collection, documentation, analyzing, and, like, 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 answer Sebastien to show the demo of is one piece of the picture. It's how do you take this accurate data, how do you put it into ServiceNow within the CMDB. But 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 and piecemeal it so you can eat the elephant one bite at a time. So, Sebastien, I'll hand over to you, and you can show how to bite an elephant one bite at a time. No pressure. I mean, you better be hungry then. Alright. I'm going to start sharing my screen as soon as this works. And so for this quick demo of, I guess, IP Fabric and the integration with ServiceNow, What I'm going to use is one demo environment that we have. So it's a virtual lab. What you can see in here in in this screen, so it's 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. So one quick way where maybe you want to see from the network what has changed between those two snapshots, we can use the the the comparison of the diagram. So what this would highlight is things that so what we're seeing in red is things that were not present before. So in that change, and 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 network change. There is always changes happening. And now what happens is we've added new devices, and now there is the question where someone has done that network change. Has it been reflected to the CMDB correctly? And this is where we're going to look at it from this extension that we have that kind of helps doing the synchronization with ServiceNow. And I also have, if I can find it, yeah, I've got 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 now that we've got the the app running, I just need to synchronize it. And for that, should remember me partially. So now 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, which each snapshot again is a picture of the network. So the the first run that we're going to do in term of doing the the synchronization is I just want to say to to compare what we have in the the new snapshot, so 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, and it's just going to be tell me, compare the inventory that we have in IP Fabric, so things that we've discovered from the network devices, and show me the comparison between what we have already in ServiceNow. And now what you're already able to see in here is that we've got a number of differences that we spotted, and we can go through the 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, and we'll look into it. But this is the one where we're saying we 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 into ServiceNow. Similarly, you can get more detail of the other way around where maybe you've got devices that are present in your CMDB, so in that case, ServiceNow, but maybe they're not reachable. So IP Fabric doesn't see them. Today, I'm not going to focus too much on that. And this one where what is different? So 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 where that was referenced in ServiceNow by IP Fabric as done the discovery in the new snapshot, and 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 in ServiceNow. So now that we've done that, I'm just going to push the change, and then we'll move to ServiceNow to see what information we we can see in that. That might take a few seconds. Okay. So now I had 97 devices. I know this one takes a few extra seconds to to get new devices, and now I've got a few more devices. The one I wanted to look at and it we we see it right there is that device where we could see that it was present already even though or it it was one that IP Fabric had and was going to add because we couldn't see it in ServiceNow. And I've made it kind of, like, fairly obvious maybe in here for the the eyes that are used to work with the CMDB, and 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 having what you're paying the maintenance for, which means potentially you are not covering the devices that you have. And then it's probably going to cause some sort of issues later when you've got a problem with the device, you need to do an RMA. So in that situation, someone has entered the one with the fours 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, where the correct one is this one. So in that situation as well, what's important with the current extension, IP Fabric is not going to remove entries from the CMDB because that needs to follow a correct process, and the goal is not to decommission or remove something from that CMDB, but to have now the accurate information in your. The the other thing that we wanted to show in the few minutes we've got left is what we were showing earlier. If I go back to the to the diagram, it's representing relationship between devices where in ServiceNow, and you'd find the same in other other CMTPs. You want to know that if there is an impact or a change affecting one device, you'd like to understand what's the change, what else is going to be affected by that change. So what we've done as well as part of this integration is to start building, a relation 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 device, this is the other network devices that are around it and could be affected. That was the idea of this is where we started, but, obviously, this needs to go further to then be able to map to the CI as in the server that could be connected to your switches to have the full mapping between an application all the way to the network to know that if I'm doing a change on that device, what business impact. Yep. Thanks, Sebastien. There's some background noise just interrupting your microphone, but I I believe that's everything that you wanted to cover in the demonstration. Yep. Yeah. Yeah. It was. Yeah. Yeah. Perfect. Thanks, Sebastien. So just I'm just gonna recap that last piece just because there's the the slight audio interruption. The the current state of the CMDB integration that we've just shown there is assets as well as dependencies at the network level, and then we do have customers that are populating the server and storage information using other tooling, but there is also, elements within the IP Fabric road map across the beginning of next year about application awareness within network assurance. So how do you map those applications into your network infrastructure? Well, thank you, Sebastien, for the demo. We're gonna wrap up shortly, but first open up for some potential q and a, which I'll just drop out of here, see if we've got any questions in the queue. To anyone in the audience, feel free to drop your, messages into the into the chat if you've got any q and a there. Well, if you've got any q, we should have the a, hopefully. K. I've got one or two here just coming through. I guess this this first question, I'll I'll pose it to you, to you, Andre, and then Rob can add some color if he if he sees fit. Like we said, big picture implications all the way up the stack, but, realistically, this is a this is a ground surf like, a surface level foundational aspect. So people are saying big challenge. How do we actually get started? What are some of the considerations and first steps that we can take for improving a CMDB? Andre, do you wanna take that one? I think as a start, you need to assign an owner. Someone needs to own the accuracy they thereof. And then you need to decide what you want to do. I I think if you look at the data, and I think there's another question about success metrics is you need to complete the valued attributes, not just if your data could be a 100% accurate, but if there's no value to it, going back to Rob's value, then it 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, owner service mapping, dependencies, that type of stuff. And now I think that that's a good start. But you need to ownership, I think, is probably the most important way of. And where were you seeing how are you seeing the different approaches to ownership? I know you said before when you raised this bottleneck and this this limitation that sometimes it's the network and infrastructure teams pointing at each other and no one really owns it. Are you seeing the ownership sit as successfully in either organization? You're seeing ownership better if it's assigned to one? I think the ownership of the CMDB does not necessarily sit in those teams. It is a function of maybe your cross functional services as a configuration manager, that person will be responsible for the accuracy of the CMDB. Because as Sebastien showed there, there's a delta that was created now. Whose responsibility is it to sort out that delta? Is it NetOps? Is it infrastructure? Is it it's the configuration manager's duty to sort that out. And you will find that in a lot of organizations, that is someone's secondary job perhaps. It's back to the ownership part. Yeah. And so the the ideal world you would suggest then is there is an internal alignment documented on the importance of this. There is the value, like, which attributes are we gonna track, and then an assigned cross functional person or team or function that is able to hold people to account. Your suggestion is that that's a a good way to to implement that Yes. within an organization. It it lives outside of those those teams. It's a function that sits across all those teams, hence the word cross functional in this case. Yeah. Yeah. So that's good. And then you you did spot the other question. There was the the the question about, which I guess fits in well to getting alignment and making sure people understand how valuable it is. Leadership metrics when tied to CMDBs, What sorts of metrics do you guys see that are worth tracking, to assess progress against this this CMDB challenge? Rob, if you wanna come off mute, you can you can take that one. Okay. Sorry. Yeah. So from a metrics I mean, completeness is one. Accuracy, freshness, so how frequent is it updated and maintained. Those are the key metrics. Right? That's, you know, starting fundamental there. Right? And then you can get into levels of version control and and things to that layer, but I I keep you those top three metrics. I think one very important one as well is is if there are 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 one in front end operations is is relying on Yeah. And then adding on to the question, I think 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. So 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. Yeah. It's a nice nice final point there. And that does actually lead to a couple of the the questions that were raised during the demonstration set. One of them was whether the the synced fields are customizable. I can we set which values are synced and which are not how flexible is the integration when you're building with the CNDB? Yeah. So at the moment with the current state of the extensions, the one I was showing is kind of is set in the code. There is no, customizable field of if you wanted to bring specific information. But I was I know we've mentioned NetBox as an example is the or integration with NetBox where the data was going to be from IP fabric to NetBox is a lot more customizable where you can have a lot more data as well that would be pushed. So that's something that can be further improved. And that's that's if a user was looking to use our extension and plug in 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 the ServiceNow practice of a trusted partner. And so the flexibility is is complete. Like, you can you can design and obviously build that integration as required. And then there was one more, and this was going back to your point, Andre, but this is maybe opening up a can of worms just as we're, we're overrunning and ready to wrap up. There was a question. Is there an AI based approach to improve automation for managing CMDB? Absolutely. I think that configuration management is a process. If you, for example, like Sebastien showed there, you you've got the switch where the application's plugged into or the service plugged into. That data is not necessarily inside of of 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, perhaps produce that that mapping for you. But that's just a a step in the process. You need to define the process to be able to get to those steps. So it's an AI based approach. Absolutely. 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. I see. It's a good close office, that one. That's the the end of the questions that we've got through the chat, so I would suggest we we wrap up there. So thank you to Rob. Thank you to Andre van den Berg as ever. Thank you to Yousef for the demo. As a as a quick wrap up, we're seeing the adoption of network assurance 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 seeing, 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 a there's a a quite a wide range of integrations that we're seeing and new opportunities arising. And the strategic partnership that we've got with the guys at NTT Data is the the finishing part to the puzzle to help organizations get the best from this network data. So 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, help you build that road map to how would you make your data accurate, how do you get it integrated, and then how do you start to properly leverage it to deliver that business value. So, again, I'll say thank you, gents, and then we'll wrap up. Thank you very much. Thanks, you. Speak to you soon.