Every analytics leader knows the moment: a senior executive questions a figure in a board pack, two reports disagree, and the meeting turns from the business decision to an argument about whose numbers are right. Trust, once lost, is slow to rebuild. People revert to their own spreadsheets, and investment in data platforms and AI delivers less than it should.
Our view is that data quality is not a cleanup project. It is an operational discipline, and the most effective way to run it is to apply the practices that transformed software delivery — automation, testing, monitoring and fast feedback — to data. That is what DataOps means in practice.
Why traditional approaches fall short
Many organizations still manage data quality reactively. Issues are discovered by business users, logged as tickets and fixed downstream, often by patching a report rather than correcting the source. Periodic cleansing projects improve things temporarily, but the same problems return because the processes that created them have not changed.
At the same time, data estates have grown more complex. More sources, more pipelines, more consumers and now AI systems that consume data at scale mean that manual quality management simply cannot keep up.
The core practices of DataOps
DataOps is not a product. It is a set of practices that together make data delivery reliable:
- Version control for everything — pipeline code, transformation logic, configuration and infrastructure definitions
- Automated testing — checks on schema, freshness, volume, uniqueness, referential integrity and business rules, run every time data or code changes
- Continuous integration and deployment — changes promoted through environments with automated checks, rather than edited directly in production
- Observability — monitoring of pipeline health and data characteristics, with alerts that reach the people who can act on them
- Incident management — clear ownership, triage and root-cause analysis when something goes wrong, just as for any production system
None of these practices is new to software engineering. What is new is applying them consistently to data, with the same expectations of reliability that users have of any other critical system.
Shift quality left
The cheapest place to fix a data problem is where the data is created. That requires working with the teams that own source systems: validating inputs at the point of capture, agreeing on formats and reference data, and making quality expectations explicit.
Data contracts are a useful tool here. A data contract is an agreement between a data producer and its consumers that defines the structure, meaning and quality expectations of a dataset, along with how changes will be communicated. Contracts turn implicit assumptions into explicit, testable commitments, and they give source system teams a clear reason to care about downstream use.
Make quality visible
Trust grows when people can see quality for themselves. Publish quality indicators alongside the data — in the catalog, in dashboards and in the documentation for data products. Show when data was last refreshed, which checks it passed and who to contact with questions.
Track a small set of measures over time:
- The number of data incidents, and the share detected by monitoring before users noticed
- The time taken to detect and resolve incidents
- The coverage of automated tests across critical datasets
- Freshness against agreed service levels for key data products
These measures give leaders a factual view of reliability and show where to invest next.
Quality matters even more for AI
Machine learning models and generative AI solutions amplify data quality issues. A model trained on inconsistent labels will learn the inconsistency; a retrieval system indexing outdated documents will confidently present outdated answers. AI also introduces new quality dimensions, such as the currency and completeness of document collections and the representativeness of training data.
Extend DataOps practices to cover these assets. Test and monitor the content feeding AI systems, version the datasets used to train and evaluate models, and include data checks in AI evaluation pipelines so that a drop in answer quality can be traced to its cause.
Where to start
Pick the data products that matter most — the ones behind executive reporting, regulatory submissions or a priority AI initiative. Put them under version control, add automated tests for the most common failure modes, and set up monitoring with clear ownership. Then expand to the next set.
Within a few cycles, the tone of quality conversations changes. Instead of blame and workarounds, teams talk about tests, alerts and root causes. That shift — from firefighting to engineering — is what ultimately restores trust in the numbers.
Want analytics your leaders can trust? Talk to our data engineering team.
