The Quiet Comeback of the CMDB, and Why AI Just Raised the Stakes

The CMDB did not fail as a concept. It failed in implementation, repeatedly, and the failures got mistaken for proof that the concept was broken.

I have seen it go wrong the same way in organisation after organisation, and it almost always starts with a framing problem: treating the CMDB as a project rather than a practice. Someone gets a budget, a team, and a deadline. They load data. They declare it done. Then they move on, and the data starts ageing the moment nobody is looking after it.

The second failure is scope. Most implementations focused on assets: what hardware and software exists, where it sits, who owns the licence. That is useful, but it is not the point. The value was always in the relationships. What does this service depend on? What else breaks when this component fails? If I make a change to this server at 11pm, who is going to notice, and how badly? An asset register answers the first question. A proper configuration model answers all of them.

The third failure is ownership. Or rather, the absence of it. Data with no named custodian is data in slow decline. The team who loaded it has moved on. The process that should be refreshing it, change management, incident, problem, was never wired to the model in a way that kept the records honest. So the model drifts, confidence in it drops, people stop consulting it, it drifts further, and eventually someone makes the reasonable decision to stop trusting it at all.

The CMDB earned its reputation as a graveyard of stale data. But the graveyard was the result of neglect, not the evidence of a flawed idea.

There is a smaller, quieter group who never stopped maintaining theirs. I do not think they are smarter. I think they just never made the framing mistake.

I have been fortunate enough to work with a number of those organisations directly, leading large-scale implementations where taking the CMDB seriously was a genuine priority rather than an afterthought. What I saw in each case was a compounding effect: each layer of mapped relationships made the next question easier to answer. You start with your most critical services and suddenly you can see what supports them. You extend to the dependencies of those dependencies and the picture keeps sharpening. The estate becomes legible in a way it simply was not before. That transparency also had a quieter benefit that only became apparent over time: organisations with an accurate, well-maintained configuration model found that external regulatory scrutiny became far less of an ordeal. Evidence that once required a scramble across spreadsheets and tribal knowledge could simply be shown. Compliance became something they already had, not something they had to construct in a hurry.

Their change process consumed the CMDB and also refreshed it. Their incident process used the service map to correlate alerts and was required to flag when the map did not match reality. The data had owners with actual accountability. Discovery tools ran on a schedule and the deltas were reviewed.

And for a long time, that discipline had a name and a face.

Twenty years ago the Change Manager was the most powerful role in any IT organisation. Like them or hate them, everyone respected them. If you wanted to get something done, you made sure the Change Manager was onside. That was not politics for its own sake. It was because the Change Manager held the picture of what a change would actually touch. Their authority rested on exactly the discipline this article is about: knowing the estate and its relationships. When they said no, or not yet, it was usually because they could see a dependency or a risk that someone else had not accounted for. The model in their head, and ideally in the CMDB behind them, was the basis of that judgement.

The role did not stay powerful. As confidence in configuration data eroded, so did the standing of the people whose decisions depended on it. Once the data behind a change decision was suspect, every no became a negotiation rather than a verdict. The same forces that turned the CMDB into a graveyard of stale records also gradually hollowed out the change management function. When the data cannot be trusted, the authority built on it starts to look like obstruction rather than governance.

I find myself wondering whether we are about to see that change. Because what AI automation needs, above all else, is exactly the rigour that role was always meant to enforce.

For most of the last decade, the cost of a poor CMDB was borne by human beings: the engineer who had to phone around at midnight to establish what depended on what, the Change Manager who had to make a judgement call on incomplete data, the service desk analyst who could not tell a customer what was actually broken. Tribal knowledge papered over the gaps. People with years of context compensated.

AIOps platforms, agentic automation, AI assistants acting on your estate: none of them have tribal knowledge. They do not phone around. They do not pause and check with someone who has been here long enough to remember the undocumented dependency. They reason over the service graph, the configuration items, and the relationships between them, and they act on what they find.

Feed an AI system a half-mapped estate and it will make confident, wrong decisions at machine speed. Change impact assessed against dependencies that are not in the model. Incidents correlated against a topology that no longer exists. Automated remediation acting on a component that nobody recorded as load-bearing for three other services. The AI is not making mistakes in the human sense. It is doing exactly what it was asked to do, with the data it was given. The gap is in the data.

The irony is that the same AI wave also makes the CMDB more achievable than it has ever been. Discovery, reconciliation, data quality, the slow and manual work that killed implementations in the past, can now be substantially assisted. Relationships that used to require someone to trace them by hand can be inferred and proposed. Stale records can be flagged automatically. The work is not gone, but it is smaller, and it is less of an excuse.

What does not change is the direction of travel. The organisations that get their configuration data and service relationships right are going to be the ones whose AI investments actually deliver what the vendor slides promised. Everyone else will be automating on top of guesswork, and they will not always know it until something breaks badly.

If your CMDB is somewhere between "technically exists" and "nobody trusts it", the answer is not a transformation programme. It is a smaller set of decisions made clearly.

Pick the services that matter. Start with the ones where failure or change hurts most: those in major incidents, highest change traffic, or first in line for AI tooling. Get those right before expanding.

Map the relationships, not just the assets. Every configuration item in isolation is a fact. The relationships are where the intelligence is: what it supports, what it depends on, who is affected when it degrades. If your CMDB cannot answer those questions, it is an asset register with a different name.

Give the data an owner. Not a tool, not a team in general. A named person with accountability for keeping the model current. This is the one that gets dropped most often and matters most.

Wire it into the processes that keep it honest. Change management verifies against the CMDB and flags discrepancies. Incident management uses the service map and updates it when wrong. Problem management identifies where the model is systematically inaccurate. The CMDB stays alive when the processes that consume it also maintain it.

Scope it right, focus on relationships, assign ownership, close the loop with your operational processes.

I am genuinely interested in whether other people are seeing the same pattern. My suspicion is that the organisations that get their configuration data right will also be the ones that put real authority back behind change and configuration management. Which makes me wonder: will we see the Change Manager re-elevated to the level it should always have remained at? AI needs precisely the rigour that role enforced. If the data has to be trustworthy for the automation to work, someone has to own the discipline of keeping it that way.

If your organisation has a CMDB story, good or bad, I would like to hear it. And if you have spent time in change management, past or present, your read on this would be particularly welcome.