Most organisations treat data quality as a project — a one-time effort to clean up bad data, implement validation rules, and declare victory. Six months later, quality has degraded back to baseline because the underlying operational conditions that produced bad data haven't changed.
The cleanup cycle
Data quality degrades continuously. Source systems change schemas without notice. Business rules evolve faster than transformation logic. Edge cases accumulate. Manual data entry introduces errors at a steady rate. A cleanup project addresses the current backlog but does nothing to reduce the rate at which new problems appear.
Monitoring, not projects
Treating data quality as an operations problem means building the same capabilities you'd build for application reliability: continuous monitoring, alerting on anomalies, defined response procedures, and regular review of trends. Quality checks run on every pipeline execution, not quarterly. Anomalies are triaged and resolved within SLAs, not added to a backlog.
The most effective pattern is circuit breakers — automated gates that prevent data with known quality issues from reaching downstream consumers. This is uncomfortable at first because it makes problems visible immediately, but it's far better than silently propagating bad data into business decisions.
Quality needs owners
Data quality without ownership is data quality without accountability. Every critical dataset needs a named owner who is responsible for its quality, receives alerts when quality degrades, and has the authority to pause consumption when problems are detected. This is a cultural change as much as a technical one, and it requires executive sponsorship to succeed.