Every organisation has a data quality problem. The interesting question is why the same problems persist after repeated remediation projects. The answer is usually that the organisation treats quality as a one-off cleanup rather than an operating capability.
Clean data decays
A cleansing exercise improves a snapshot. The source systems continue to change, new records are created, integrations evolve and the definitions drift. Without controls at the point of creation and movement, the data returns to its previous state.
The organisations that sustain quality do not rely on a periodic purge. They define what good looks like, monitor it continuously and have a clear path for correcting the cause rather than only the symptom.
Ownership has to be concrete
“The data function owns quality” is not an operating model. The business domain owns the definition and the acceptable quality threshold; the platform function owns the mechanics of ingestion, validation and monitoring; the system owner owns the source behaviour.
When those responsibilities are not explicit, quality issues circulate between groups. Everyone agrees the data is wrong, but nobody owns the decision about what right means.
Contracts and quality gates
A data contract is a practical agreement between a producer and a consumer. It defines the fields, semantics, freshness, completeness and failure behaviour. It does not need to be a heavy legal document; it needs to be explicit and testable.
Quality gates should sit in the path, not only in a dashboard. A pipeline that accepts a malformed record and reports the problem later creates a downstream reconciliation cost. A pipeline that quarantines the record and alerts the owner contains the problem at the boundary.
Measure what drives action
A quality score of 87 percent is not useful unless it maps to a decision. Better measures are specific: the percentage of referrals missing a mandatory field, the number of customer records with conflicting identifiers, the age of the oldest unresolved exception.
Each measure should have an owner, a threshold and a response. If a measure cannot trigger an action, it is reporting, not control.
What we recommend
- Assign data ownership at the domain level, not only to a central platform function.
- Define contracts for the data that crosses system or organisational boundaries.
- Put validation and quarantine in the pipeline, with a visible exception queue.
- Report a small number of measures that have a named owner and a response.
- Review quality in the same cadence as operational performance, not as an annual project.
Where we disagree
We do not believe buying a data quality tool creates a data quality capability. Tools are useful for detection and workflow, but they cannot resolve ambiguous definitions or assign accountability. We also do not believe all data needs the same level of control; proportionality is part of a mature operating model.
A practical test
Choose the data that matters most to a current decision and trace one record from its source to the report. At every hand-off, ask who owns the meaning, what validation was applied and what happened to the last exception. If the answer is a generic function name, the problem is the operating model, not the pipeline.