Conversations about data quality almost always start the same way: a KPI came out wrong, a regulatory report was rejected, or a new AI project failed not because of model hallucination but because of "dirty data". The root cause is rarely the technology — it is that data quality is treated as a project rather than a programme.
Programme vs project
The project pattern: a team works for two months, performs a round of cleansing, builds a dashboard and disbands. Three months later metrics drift. The programme pattern: measurement, ownership, thresholds, escalation and reporting embed in the organisation's routine — tracked like any other KPI.
The six pillars of the programme
1) Dimensional measurement. Data quality is governed across six measurable dimensions: accuracy, completeness, consistency, timeliness, uniqueness and validity. Each dimension has a concrete formula; numbers replace adjectives like "bad".
2) Ownership. Every data asset (customer table, product catalogue, account records) has a data owner on the business side and a data steward on the technology side. When a threshold is breached, both phones ring.
3) Thresholds and SLAs. Each dimension carries a coloured threshold: green, amber, red. If accuracy on the customer table falls below 95% it is amber; below 90% it is red and managed as an incident.
4) Automation. dbt tests (unique, not_null, accepted_values, relationships) are the first line. Complex business rules go into custom singular tests, or Great Expectations / Soda Core. These tests run in CI/CD and block broken transformations from being merged.
5) Data contracts. Testable contracts between producers and consumers carry schema and semantic expectations. CI shows whether a producer's schema change will break a consumer. This eliminates surprise schema breaks.
6) Reporting and feedback. A monthly data-quality dashboard goes to the executive layer: trend, threshold breaches, the five worst-performing tables, responsible units. Without this dashboard the programme loses political backing.
Maturity model
A programme moves through four levels:
- Level 1 — Reactive. Issues are discovered by end users. Fixes are ad-hoc.
- Level 2 — Monitored. Some tables have automated tests. No defined thresholds, no alarms.
- Level 3 — Managed. Dimensional metrics, thresholds and owners exist for all critical tables. A monthly dashboard reaches the executive level.
- Level 4 — Automated. Data contracts are enforced in CI/CD. Threshold breaches turn into PagerDuty / Opsgenie incidents. Trend reports generate automatically.
Most large enterprises in Türkiye are at level 1-2 in 2026. Reaching level 3 is not a one-shot effort but a year-long planned programme.
A practical 90-day kickoff
Days 1-30: scope definition (5-10 critical data assets), ownership assignment, baseline measurement. Days 30-60: dbt + Soda automation, threshold and SLA definition, first dashboard. Days 60-90: data-contract pilot (1-2 producer teams), monthly executive reporting kicked off.
By the end of these 90 days, the organisation should have replaced "the data is bad" with sentences like "the customer table has 88% accuracy, 94% completeness, 71% consistency".
Three frequent mistakes
Buying a single tool. Adopting Soda or Great Expectations and walking away. The tool helps; without people and process, it does nothing.
Failing to assign owners. "All data is IT's responsibility" is the death sentence of a quality programme. If the owner is not on the business side, breaches are ignored.
Inflating scope. Trying to bring 200 tables in scope on day one. Start with 5-10 critical tables and widen as maturity grows.
Conclusion
A data-quality programme is a balanced combination of technology, governance, people and process. A mature programme makes continuous trust possible across AI, BI and regulatory reporting. The investment in that trust is far below the cost of a single incident.
