I lead Data & AI for a global quick-service restaurant business with more than 60,000 locations worldwide, and what we’re seeing is that organizations are investing heavily in modern data architectures, scalable cloud platforms, and generative and agentic AI. 

Trust in foundational enterprise data, however, remains fragile. Business functions still keep a shadow spreadsheet of the numbers they believe, because they do not fully trust the dashboards in front of them.

When an enterprise rollout of a generative AI use case fails or underdelivers, the investigation usually ends at poor data quality. The instinct is to launch another one-time cleanup. 

A short-lived task force scrubs the data, and the team celebrates the week the dashboards finally agree. The relief does not last. A project ends, and trust has to be maintained after it does.

In my experience, durable data quality depends on two things working together: automated quality monitoring built into the engineering pipeline, and a data governance operating model that gives chief data officers (CDOs) a way to establish clear ownership and accountability. 

What Data Quality Governance Means

Data quality governance connects quality expectations, ownership, controls, measurement, and remediation. When we stood up our operating model, we defined five things:

1. Critical data elements (CDEs): The data that matters most for business decisions
2. A definition of “good enough” for each CDE
3. Business ownership of each data domain
4. A path from detection to remediation for every data quality issue
5. Service level agreements (SLAs) that state how quickly each issue must be resolved

What Good Data Quality Looks Like in Practice

Before extending data to enterprise-wide use cases, business and technology teams should be able to answer four questions:

• Is this data trustworthy?
• Is it within the agreed thresholds? 
• Has its quality declined over time? 
• Which business function owns remediation when it falls outside tolerance?

Good data quality does not require every dataset to be perfect. It means the data is fit for the decisions and processes that depend on it. 

In practice, the organization has confidence in its most important data before that data reaches a dashboard, a model, a regulatory report, or a customer-facing process.

During our store location master data management implementation, we audited our data assets to find which attributes were critical. We concluded that not every attribute needs to fulfil all the criteria listed exactly. Under the operating model, we decided together where exceptions were acceptable and where they were not.

Once an attribute is classified as critical, its quality is managed proactively. Each CDE now carries defined expectations, business validation rules, acceptable thresholds, and a named business owner. 

Because monitoring is in place, we detect issues close to the point where they enter the data. Data lineage, which traces data from its source to where it is used, links each issue to the downstream systems it affects, such as BI dashboards, workflow agents, or machine learning models.

Start With the Assets That Matter Most

Most enterprises assess data health against six standard dimensions of data quality: accuracy, completeness, consistency, timeliness, validity, and uniqueness. 

Not every dimension matters equally for every dataset, and guarding everything equally costs more effort than any team can sustain. 

The better starting point is the business use case. Identify the data that drives critical decisions, operations, customer or employee experience, or competitive advantage, and then decide which dimensions matter most for each element. 

After our audit, the governance model determined which assets needed measurement across all six dimensions. In a quick-service restaurant business, store locations are a critical asset. 

They form the foundation of the analytical infrastructure, and many functions rely on them to measure operations, personalize customer experiences, and make high-value decisions. Customer and marketing data follow the same logic. 

Email addresses and phone numbers are used, alone or combined with other assets, for campaign execution, identity resolution, and customer engagement, so these fields need high completeness and validity. 

Optional fields such as salutation, address line 2, or social media handle can tolerate lower completeness without a material effect on the business.

Earlier in my career, I consulted for a life sciences organization where the standard was far stricter. For clinical trial data and patient identifiers, accuracy, completeness, and validity were mandatory, because defects in that data carry regulatory, scientific, and safety risk.

The principle I took from these cases is that governance effort should be proportional to business impact. 

The more a dataset affects decisions, operations, risk, or competitive advantage, the tighter its controls and monitoring should be. Everything else can run with lighter governance.

Give Every Critical Domain an Owner and an SLA

We also assigned a business owner to each critical data domain and set SLAs for what happens when quality breaches a threshold. 

Our tooling let us observe data as it moved through the enterprise systems, but observing quality in real time solved only half of the problem. 

Once the tooling flagged a CDE as breaching one of the six dimensions, one question remained: who is responsible for fixing it within a reasonable time, without disrupting business operations?

The gap usually comes from how responsibility is divided. Data engineering owns the monitoring, while the business owns the domain. In the early stages of our operating model, nobody acted when quality degraded. 

Everyone waited for someone else, because ownership was ambiguous and no directive or incentive existed. The operating model closed that gap. It documents an escalation path for defects and maps each flawed asset to the downstream system it affects.

The structure that supports this is a hybrid governance model, shown in Figure 1 below. A central governance team sets strategy, standards, and policies, which keeps definitions consistent across brands. 

Each data domain then owns its data and is accountable for meeting those standards. Data quality governance is owned jointly by business and technology, a choice intended to increase adoption and reduce resistance when the model is introduced.

Figure 1: A hybrid governance model: standards are set centrally, and each domain owns its data.

Why Quality Breaks: Silos, Speed, and Translation Loss

In my experience, data rarely degrades because the technology fails. Business meaning gets lost between silos. 

Consider the launch of a new burger, “The Glaze,” in one market. Marketing sees the product through the customer’s eyes, with CDEs such as product hierarchy, campaign name, price, and a limited-time-offer flag. 

Operations tracks make time, the number of items on the burger, and the packaging material. Supply chain tracks the product IDs of the recipe items, cost of goods sold (COGS), the number of bun packs, the pounds of beef patties, and the amount of cheese.

Each set of CDEs is correct for the function that created it. Because no one governed the business logic across the three functions, the engineering team built pipelines that moved the data between systems without the quality checks each CDE needed. 

Gross margin and profitability measures drifted, promotional lift looked stronger than it was, and nobody in the room could explain the gap. The pipelines ran without error, yet the meaning of the data was lost on the way.

Speed makes this worse. Pipelines are built for an urgent request, and monitoring is added later, if at all. Teams then discover schema drift (an unplanned change in the structure of a data source) or an unexpected drop in volume only after an executive flags a broken report. 

That cycle is expensive and exhausting, and it damages the credibility of the data team. The governance operating model gives the CDEs of each function a shared definition and a shared quality standard, so these problems surface earlier.

Key Takeaways

A mature data organization needs more than data observability tooling, which monitors the health of data as it moves through pipelines. 

It needs an operating model in which business stakeholders share accountability for data health, and in which the business meaning of each asset is documented and visible across functions. If you have a free hour after reading this, use it to work through three tasks:

• List your five most critical data assets and confirm that each has a named business owner, and not only an engineering contact.
• Pick one of those domains and write its remediation playbook: who validates the business logic, who deploys the fix, and by when?
• Ask your business partners where they still keep shadow spreadsheets. That list is your real quality backlog.

When business meaning travels intact across systems, critical assets have owners, and remediation follows agreed SLAs, the enterprise spends less time questioning its dashboards and more time using the data.