Enterprise architects spend a great deal of time making complexity understandable. They define business capabilities, applications, services, technologies, dependencies, and target states. They establish the structures and standards that describe how the enterprise should fit together.
That said, architectural models are only useful operationally if the data used to run the enterprise reflects them. And that data needs to remain trustworthy as applications change, services evolve, infrastructure moves and ownership changes.
But does the data in your live ServiceNow environment reflect the intended architecture? The CMDB supports change management, incident response, impact analysis, and increasingly automation. If the underlying data quality is not high enough, the consequences can go well beyond inaccurate reports.
Architecture on Paper vs Architecture in Operation
Most large organizations have more than one version of the truth.
There is the architecture shown in diagrams and portfolio tools. There is the data held in the CMDB. Individual systems often have detailed documentation of their own, including architecture and dependencies, but the information needed for operational processes is not always reflected in the CMDB. Then there is the knowledge held by subject matter experts – and the picture people reconstruct under pressure when an incident affects a service that nobody quite understands end to end.
These different views can coexist for years because people find ways around the gaps:
- A good engineer knows which spreadsheet or system document to consult.
- An experienced service manager or change manager relies on another source, but the missing or corrected information never makes it back into ServiceNow.
- When the records do not provide an answer, someone says, “Ask Tim.”
These workarounds can keep things moving today. But they do not scale. When an incident occurs or a change goes wrong, relying on scattered documentation and somebody’s personal knowledge can become expensive very quickly.
Having Data Doesn't Mean You Can Trust It
It's relatively easy to populate a CMDB using Discovery and integrations. You can have thousands or millions of CIs, but that doesn't mean the data is correct or useful for the processes relying on it.
A relationship between a server and an Application Service may exist, but is it still current? Does it represent a production dependency or an old deployment? Is it connected to the correct service? Would somebody be comfortable using it to determine the impact of a change?
The same applies to ownership. An Owner field may be populated, but that doesn't mean the person is still active or even works for the organization. And even if they do, when was the ownership last validated?
The same applies to support groups. A group may be assigned, but does it have the right members? Are those members still active, and do they have the roles needed to perform the work?
A populated field or CI relationship is not the same as trustworthy operational data. The more useful question is:
What needs to be true before we are comfortable using this data to make a decision?
Make Architectural Requirements Testable
Enterprise architects shouldn't be expected to maintain individual ServiceNow records. Equally, CMDB teams shouldn't have to interpret architectural intent on behalf of the rest of the organization.
A more scalable approach is to make the requirements explicit. For example, an organization might decide that every production Application Service must meet requirements such as:
- it is connected to the correct Business Application according to the CSDM;
- its lifecycle status is valid;
- it has an accountable owner;
- its support and managed-by groups have the required active members and roles;
- the required infrastructure and service relationships exist;
- retired applications are not connected to active production services;
- ... and so on.
Not every service will necessarily meet every requirement, and there may be valid reasons for exceptions. The organization should document these exceptions, assign an accountable owner and review whether they remain justified through its governance process. Otherwise, they easily become permanent gaps that nobody remembers approving.
These are not just reporting preferences. They translate architectural and operational requirements into rules that can be tested against live data.
Instead of periodically asking whether the CMDB is "healthy," the organization can then ask much more useful questions:
- Do our production services meet the requirements defined for them?
- Where are the deviations?
- Who is responsible for correcting or validating them?
- Is the situation improving or deteriorating over time?
Data Quality Requires Distributed Responsibility
The CMDB team is rarely in a position to know whether every Business Application, service or infrastructure relationship is correct. And according to our Consumer–Owner–Provider model, they shouldn't be expected to.
Data Consumers define what information they need for their processes and decisions. Data Owners translate those needs into requirements and govern them. Data Providers supply, validate and maintain the actual data.
That knowledge is distributed across the organization. Application owners understand their applications. Service owners understand their services. Infrastructure teams know the technology and its dependencies. Business owners understand criticality and impact, while other teams may have the expertise needed to validate security, regulatory or continuity requirements.
This is why dashboards alone don't solve data quality problems. A dashboard might show 3,000 records with issues or a CMDB health score of 72%. But that doesn't necessarily tell you who can verify the data, who should correct it or how to get the work done.
Good governance needs to connect the people who consume the data, those accountable for defining and governing its requirements, and those who can verify and maintain the individual records.
When those groups are connected, data quality becomes an operational process rather than a periodic clean-up exercise.
Turning Requirements into Continuous Governance
With DCM Blueprints, organizations can define the requirements their ServiceNow data must meet. DCM then audits live records against those requirements and identifies deviations from the agreed model. For practical starting points, explore the CSDM-aligned templates in the DCM Blueprint Library.
Finding deviations is only the first step. The relevant application owner, service owner, technical team or other Data Provider can then be engaged to validate or correct the data.
Instead of being told that "CMDB health is 72%," they can be told:
- These five applications you own do not have the required service relationship.
- These production services are assigned to support groups that have no members or include inactive users.
- These records no longer meet the lifecycle rules defined for this class.
The issue can then be directed to someone who actually knows the data and can do something about it, usually automatically by DCM. This is the important difference between reporting data quality problems and having a process to correct them.
The point is not to create another dashboard. It is to create a repeatable process for keeping operational data aligned with the organization's requirements.
AI and automation make this more important
An AI agent or automated workflow may act on an ownership field that has been wrong for six months or a service relationship that should have been retired long ago. Unless the process has suitable validation or safeguards, it may have no reason to question the data.
The more ambitious the AI and automation goals, the more important the underlying data quality becomes.
This doesn't mean every field in ServiceNow needs to be perfect. The important thing is to understand which data is needed for which decisions and define the requirements accordingly. We explored this connection further in Knowledge26 Reflections: The Real Enterprise AI Challenge Is Trustworthy Data.
The CMDB becomes valuable when it can be trusted
No CMDB will ever represent every detail of a complex enterprise perfectly, and that should not even be the objective. The objective is to make the data that matters for decisions trustworthy enough to act on.
Enterprise architecture defines many of the structures and relationships the organization expects to see. Data Consumers define what they need from that information in their operational processes. ServiceNow holds much of the data they rely on. The challenge is keeping the requirements and the actual data aligned as the organization changes.
When architectural requirements are translated into testable rules and the right people are responsible for maintaining the data, the gap between architecture and operations becomes much easier to manage.
