It is two in the morning and a customer-facing application is down. The on-call engineer opens the CMDB, finds the server and sees an owner who left the company a year ago. The database the application depends on is not recorded at all. What follows is a round of phone calls, a search through shared spreadsheets and a debate about who is responsible for what. The incident drags on, and the next morning someone says it again: “You can’t rely on the CMDB anyway.”
We often see the same pattern. The configuration database exists, it costs real effort to maintain, and still nobody trusts it. So people keep their own records in spreadsheets, wikis or their heads. That closes the loop: the less the CMDB is used, the less it is updated, and the less it deserves to be trusted. Behind all of this are tired people who rebuild a picture of the infrastructure from scratch every time something breaks.
Why the usual fixes don’t last
The typical response is a clean-up project. A team spends weeks reviewing records, the data looks good for a while, and six months later it is back where it started. The problem is not one bad import. It is the way data is created and the way it ages.
- Manual entry without checks. Several people create items in different ways, and nobody verifies whether the result makes sense.
- No history. When a value is wrong, there is no way to find out who changed it, when, or where it came from.
- More than one truth. The organisation keeps a primary CMDB in one tool and operational data in another. Without a reliable link, the records drift apart.
- No feedback loop. Inconsistencies surface at the worst possible moment: during an incident.
A better way to think about data quality
Trust in a CMDB does not come from perfection. It comes from transparency. People will rely on data when they can see where it came from, when it was last confirmed and what is wrong with it. We recommend building on four principles:
- Automate wherever you can. Discovery and imports beat manual copying.
- Every change has an author and a source. Version history is the foundation for tracing errors and for audits.
- Check quality continuously. It is far better to find an inconsistency on a quiet Tuesday afternoon than during a night-time outage.
- Be clear about the primary record. If another CMDB is the system of record, it must be unambiguous which item matches which.
How Eywo Stratum handles it
Eywo Stratum works with 34 item classes, from business services and applications through databases, virtual and physical servers, IBM Power, containers and storage to network and OT devices. You can populate it in several ways and combine them:
- through the discovery API, which scanning and inventory tools feed,
- by importing CSV or Excel files, typically during rollout or migration,
- by creating items manually where nothing else can capture them,
- by synchronising with a primary CMDB such as ServiceNow or SMAX via external IDs, so it is always clear which record corresponds to which.
Every change to an item creates a new version. The history shows who made the change, when, exactly what changed and where the data came from: discovery, import, synchronisation or a person. When a value turns out to be wrong, its origin can be traced in moments.
On top of that sit data quality checks. Stratum flags inconsistencies and incomplete records so the team can fix them as part of normal work rather than under the pressure of an incident. Over time, the CMDB becomes the first place people look, because they know what they will find there.
Conclusion
A CMDB nobody trusts is not really a technical problem. It is a problem of trust, and trust cannot be mandated. It can only be earned: through automated population, transparent history, continuous checks and a clear link to the primary record. The reward is an operation where the on-call engineer finds the answer in the data at night, not on a colleague’s phone.
CMDB management, version history, imports and data quality checks are part of the Standard edition; synchronisation with a primary CMDB via external IDs is available in the Enterprise edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.