What I will cover:
- Why the physical layer is where most CMDBs quietly lose their integrity
- Why a healthy CMDB score does not necessarily mean a trustworthy CMDB
- What that inaccuracy costs — and which team feels each cost
- Why AI and automation depend on a CMDB that reflects reality
- How an accurate 2D and 3D digital twin transforms confidence in the CMDB
- Where to start
Every enterprise has invested heavily in building a Configuration Management Database. Whether it sits inside ServiceNow CMDB, BMC Helix or another platform, the ambition is always the same: to create a single source of truth for the organisation’s technology estate.
In almost every organisation, the CMDB is not trusted when it comes to the location data for physical assets.
The physical environment continues to change every day. Servers are installed and removed. Network equipment is upgraded. Power feeds are modified. Cabinets are reorganised. Components are replaced. Temporary changes become permanent ones.
The technology evolves continuously.
The physical record rarely does.
The physical layer is where the CMDB quietly begins to drift.
For logical infrastructure, most enterprises are in reasonable shape.
Discovery tools continually refresh virtual machines, operating systems, cloud resources, applications and software relationships. Much of the logical estate updates itself automatically, making it relatively easy to maintain confidence in the data.
The physical estate is entirely different.
No discovery tool can reliably tell you which rack an engineer moved a server into during an emergency maintenance window. It cannot confirm that a power feed was swapped, that a patch panel was reconfigured, or that equipment was decommissioned but never removed from the record.
The reality is that very little physical work is ever captured at the point it happens. Engineers are solving operational problems, not completing administration. They are standing in hot aisles, behind cabinets, in plant rooms, up ladders.
The consequence is subtle.
The CMDB does not suddenly become wrong; it simply becomes a little less accurate every day, because a server moves, a network card is replaced, a UPS battery is changed, a cabinet is reconfigured, a switch is removed.
None of those changes appears significant in isolation, yet collectively they create something much more serious: a CMDB that no longer reflects the physical estate it is supposed to describe.
Why CMDB health scores create false confidence.
Most organisations measure the health of their CMDB by tracking completeness — whether the mandatory fields are populated and the relationships are mapped. Completeness is not the same thing as accuracy.
Take a configuration item that reads:
It appears perfectly healthy. Every required field has been completed and the relationships are intact. The governance reports look fine. But what if the server is no longer in Rack 12? What if it was relocated during an emergency project six months ago? The CMDB cannot answer those questions, because it assumes that yesterday’s physical record is still today’s reality.
The CMDB being inaccurate is not the problem. This is.
A record that is slightly out of date is not, in itself, something to lose sleep over. What matters is everything downstream that treats it as true — and each of those things sits on a different desk.
The greatest impact is not usually felt during a major incident. It happens quietly, every single day, and nobody notices because everything still appears to be working.
Felt by IT operations and support.
Start with the everyday. An engineer needs to get hands on a device to perform a hard reboot, and the rack and U position in the record turn out to be wrong. Somebody walks the floor. A fifteen-minute job becomes an afternoon. None of it is ever logged as a fault, because nothing failed. It simply took 4x longer than it should have, and it will do so again next week.
Felt by facilities and M&E.
Then the building. An electrical shutdown is planned against a record that cannot say with certainty what is actually fed from that circuit, so the work is done cautiously, out of hours, with more people than it needs. A server is decommissioned and nobody fits the blanking plate, so cold air passes straight through the gap and the cooling works harder for nothing. IT knew about the change. Facilities found out late, or never.
Felt by capacity planning.
Then capacity. Today’s data centres are constrained far more by power than by floor space, and accurate power planning depends entirely upon knowing what equipment is actually installed, what it draws, where it is located and how it is connected. When the physical record is inaccurate, planning happens against assumptions instead of facts. Rack capacity appears available when it is not. Cooling calculations become estimates. New deployments introduce constraints that only become obvious once engineers arrive on site — and by then the project has a date on it.
Felt by change management.
Then change. Every Change Advisory Board depends on relationship data. Before approving work, change managers ask a straightforward question: what depends on this? The answer comes directly from the CMDB. If the physical relationships are incomplete or outdated, the assessment itself becomes unreliable. A change that appears low risk disconnects an application nobody realised depended on that switch. Power is isolated from equipment thought to be redundant. A fibre is removed because the record suggested nothing important was using it. The engineering was not wrong. The information it relied upon was.
Felt by IT security.
Then security. A vulnerability is announced and the team needs to locate every affected device. The record produces a list, and the list is not the estate. Equipment that is not accurately described cannot be patched, cannot be decommissioned and cannot be accounted for. That is a security exposure before it is ever a data problem.
Felt by finance and procurement.
Then the contracts and the books. Maintenance and support renew against an asset count nobody has verified, so the business keeps paying for infrastructure that was decommissioned two years ago. When equipment is bought there is a CapEx expense, amortisation, and an OpEx expense to run the equipment. The amortisation is straightforward in principle — a straight line from the day it is bought to the day it is decommissioned — but capturing the associated OpEx against each asset is where it falls down: the cost of every fix, repair, service visit and the energy it draws. Get that wrong and the replace-or-keep decision is made on partial numbers. That is a subject in its own right, and one I will come back to separately.
Felt by risk, audit and compliance.
Then the day something fails. Manufacturers ask for maintenance history before honouring warranties. Insurers ask for service records before approving claims. Auditors ask organisations to demonstrate exactly what assets existed, where they were located and what interventions were carried out. The CMDB should answer every one of those questions. Too often it cannot — not because the maintenance was not completed, and not because engineers failed to do their jobs, but simply because the physical work was never captured when it happened. At that point nobody is asking whether the work took place. They are asking you to prove that it did. Those are two very different things.
Felt by sustainability and reporting.
And now the reporting. Energy consumption, carbon reporting and ESG disclosures increasingly rely on information originating from the physical estate. If the CMDB cannot accurately describe what equipment exists and where it is consuming power, organisations inevitably fall back on estimates based on manufacturer specifications rather than measured operational reality. That may have been acceptable when ESG reporting was largely internal. Today those figures are certified to boards, customers, regulators and investors.
Notice where all of that lands. The slow reboot is operations’. The overnight shutdown is facilities’. The stalled deployment is capacity planning’s. The outage is change’s. The unpatched device is security’s. The renewed contract is procurement’s. The unprovable warranty claim is risk’s. The certified carbon figure is the sustainability team’s.
Not one of them sits on the budget line of whoever keeps the CMDB running. Every one of them depends on it. And none of them is in a position to fix what makes it wrong, because the problem is not inside the database. It is out on the floor, where the work happens and the record does not move.
AI will only ever be as intelligent as the data it receives.
Every technology conference this year contains discussions about autonomous operations, AI-assisted change management and intelligent automation. All of those technologies share exactly the same dependency. Trusted data.
AI agents do not question the CMDB. They assume the information is correct.
If the physical estate drifted away from the record two years ago, an AI agent simply reaches the wrong conclusion more quickly than a human would, and at greater scale. Automation is not inherently risky because it makes decisions. It becomes risky when it makes those decisions using inaccurate information.
Before organisations place AI agents at the centre of operational decision making, they need confidence that the physical estate being described actually exists exactly as the CMDB believes it does.
This is where the digital twin changes the conversation.
For many people, a digital twin sounds like an attractive visualisation. In reality, it is worth far more than that. A verified 2D and 3D digital twin becomes continuous evidence that the CMDB reflects the physical world.
Instead of reading that a server occupies Rack 12, an engineer can see it. Instead of trusting a cabinet diagram drawn three years ago, operations teams can navigate an accurate three-dimensional representation of the room before dispatching anyone to site. Capacity planners can immediately understand available rack space, power distribution and cooling constraints. Change managers can visualise physical dependencies before approving work. Auditors can compare records against a representation that has been validated from the physical environment.
Every one of those teams is finally looking at the same thing.
The conversation changes from “we believe the data is correct” to “we can demonstrate that it is.”
The CMDB stops being a database of configuration items. It becomes a trusted representation of the estate itself.
Where to start.
The instinctive response is often to launch a CMDB improvement programme. In my experience, that is the wrong place to begin. Improving records without improving how physical information is captured simply creates a cleaner version of the same problem.
Instead, choose one business-critical asset. Then answer two questions.
Can you confidently describe its exact physical state today?
Can you produce a complete history of every installation, move, service visit, repair and change performed on it during the last twelve months?
If you can answer both within an afternoon, your physical data capture is probably working well. If you cannot, and most organisations cannot, you have identified the real problem.
It is not that the CMDB has failed. It is that the physical information feeding it can no longer be trusted.
Closing the gap.
This is precisely the problem Spire™ was designed to solve.
Rather than expecting engineers to remember to update the CMDB after completing physical work, Spire captures installations, moves, changes, maintenance, repairs and decommissions at the moment they happen, by whoever is doing the work, including the third parties who do not work for you. Every intervention becomes part of the asset’s permanent history and continuously enriches the information held within the CMDB. Your service management platform does not move. Nothing gets replaced. The physical layer underneath it simply becomes true.
Combined with an accurate 2D and 3D digital twin, organisations gain something they have rarely had before: confidence that their system of record genuinely reflects the estate they operate.
Planning becomes more reliable. Changes become safer. Audits become easier. Maintenance becomes provable. Capacity becomes visible. AI becomes trustworthy.
Ultimately, the value of a CMDB has never been measured by how many configuration items it contains. It is measured by a much simpler question.
*When the business depends on it, can you trust that it reflects reality?
Tell me what you find. That is a better first conversation than a demo — for you and for me.
Related reading from the CMDB & Asset Management series:
- Your CMDB has become stale and untrusted. Here is what it costs. (Colocation)
- How telcos can monetise the estate they already own (Telecoms)
Martin Docherty (DCIS®) works on data centre asset management at Assetspire.