Data mesh and data governance solve the same problem from opposite directions. Data mesh distributes data ownership to domain teams—retail banking, wealth management, operations. Governance creates central standards and control. When both approaches collide in production, you need a resolved conflict model, not a compromise.
Introduction
I’ve spent the last five years watching organizations attempt to implement data mesh architectures, and the same conversation happens in every engagement: “We want domain autonomy, but we need enterprise governance.” That tension isn’t a failure to plan—it’s the fundamental design problem nobody talks about candidly.
At its core, data mesh assumes domain teams own their data and the systems that serve it. Governance, the discipline I’ve practiced across financial services and government, assumes a central authority maintains standards. These aren’t opposing philosophies; they’re operating at different scales. The collision happens when you try to run both at full strength simultaneously.
The financial services sector makes this concrete. Retail banking owns customer checking accounts, deposits, payments. Wealth management owns investment portfolios, advisor relationships, allocations. Both need to serve the same customer. Both need audit trails. Both need to meet HIPAA and SEC regulations. Neither should wait for a central committee to approve a schema change. And yet, if retail banking decides to restructure how it tracks account owners, wealth management’s lineage breaks.
This article maps three real collision points and shows how to resolve them using what I call light-touch governance—central standards that enable domain autonomy rather than constrain it.
Metadata Standards: Mandate Without Ownership
The first collision surfaces the moment you ask: “What is a customer?”
In a mesh, retail banking owns the customer data product. It defines what fields represent a customer, how they’re validated, what formats they use. Wealth management consumes that data product. But wealth management also owns its own customer data—advisor relationships, account hierarchies, net-worth calculations—that retail banking may consume.
The governance instinct here is to centralize metadata: a single data dictionary, one version of truth, enforced schemas across the enterprise. The mesh instinct is: each domain defines its own schemas; consumers adapt.
The collision is this: if wealth management adopts retail banking’s customer schema blindly, it loses flexibility when it needs to represent advisor-managed accounts (where multiple clients may share decision-making). If it maintains a separate schema, lineage tracking becomes impossible, and audit teams can’t trace a customer record across both domains.
I’ve found the resolution lies in metadata standards that constrain the interface, not the implementation. Retail banking publishes its customer data product with a guaranteed schema: unique customer ID (UUID format), email (RFC 5322), account status (enumerated set: active, suspended, closed). These are non-negotiable—they’re the contract between domains.
But retail banking owns the entire implementation. It decides if email is stored in a single column or split. It chooses the database technology. It owns the change log. Wealth management does the same for its own data products.
The central governance function publishes a metadata standard that says: “All data products must expose entity keys as UUIDs and document lineage in a shared metadata repository.” This is a small, specific constraint. It’s not a data dictionary. It’s a protocol.
Operationally, this means a central metadata team (two to three people, not a department) maintains a data product registry—not the data itself, just the registry. Each domain team publishes their data product’s schema, owner, SLA, and lineage. Retail banking says: “We own the Customer data product, refreshed hourly, consumed by Wealth Management and Operations.” Wealth management says: “We own the Advisor data product, refreshed daily, consumes Customer from Retail Banking.”
The registry becomes the source of truth for what exists and how it connects, not how to implement it.
Cross-Domain Lineage: Tracing the Chain Without Choking on It
The second collision emerges immediately: if retail banking changes its customer schema, how does wealth management know?
In a centralized governance model, a change committee reviews schema changes. Consumers are notified. Impacts are assessed. The change is deployed with coordination. This works when you have 5 data products. It becomes a bottleneck at 50.
In a pure mesh, domains change autonomously. But lineage—the trail from raw data through transformations to insights—breaks unless you have a way to track it. And when HIPAA auditors ask “who handled customer PII,” you need to answer in seconds, not days.
The collision: centralized lineage tracking (where? how often? who maintains it?) versus distributed ownership (who even knows when lineage changes?).
In financial services, I’ve seen this break real audit processes. Wealth management built a portfolio risk report that consumed customer income data from retail banking. Retail banking’s upstream data source changed—the bank acquired another institution, merged customer records—and retail banking updated its pipeline. Wealth management’s report silently degraded because it was matching on a field that no longer existed. The auditors found it six months later. Nobody could trace when the lineage broke.
The solution is real-time metadata event streaming, not batch reconciliation. Each domain team publishes metadata change events to a shared event stream the moment they change a schema, add a transformation, or update a lineage dependency. Wealth management subscribes to retail banking’s metadata events.
Operationally, this looks like: retail banking uses Apache Atlas (or Collibra, or custom tooling) to track its lineage internally. When a schema change is promoted to production, Atlas emits an event: {source: "retail_banking", dataset: "customer", change: "email_field_added", timestamp: "2024-01-15T14:32:00Z"}. Wealth management’s data platform subscribes to this event stream. If it consumes the customer dataset, its monitoring system flags the schema change, and a wealth management engineer reviews whether it impacts their models.
The central governance function operates the event stream infrastructure and sets the schema for metadata events. It does not review changes; it ensures domains can communicate changes.
This is radically different from centralized change management. No approvals. No handoffs. Pure asynchronous notification.
Compliance Burden: Who Owns the Controls?
The third collision is the sharpest: regulatory compliance.
In financial services, HIPAA requires encryption, access logging, and audit trails for any system handling customer health information. If a wealth management system stores health status (to assess long-term care needs for planning), HIPAA applies. SEC regulations require data retention policies. Retail banking must archive transaction records for seven years; wealth management must archive investment recommendations for six.
The governance reflex: central compliance team owns the controls. Encryption is enforced at the infrastructure layer. Retention policies are centralized. Audit trails flow to a central repository.
The mesh reflex: each domain owns its compliance posture for its data products. Wealth management implements HIPAA controls because it owns the health data.
The collision is immediate: if encryption happens at the infrastructure layer, wealth management can’t opt into stronger controls without changing central architecture. If each domain implements controls independently, you end up with 30 compliance implementations, each with different bugs, and no enterprise audit trail.
I’ve seen this paralyze organizations. A financial services firm I worked with had wealth management and retail banking separated by a regulatory firewall (different legal entities). Wealth management needed HIPAA controls; retail banking didn’t. Central IT said: “We’ll deploy HIPAA to everyone.” That cost $2M and took nine months. Wealth management could have implemented it in their domain in two months for $400K. But the central team had no way to audit or assure a decentralized implementation.
The resolution is compliance as a data product. Central governance publishes compliance controls—encryption policies, retention schedules, audit log schemas—as specifications, not infrastructure. Domains implement the controls using domain-specific technology.
Here’s how it works: central compliance (working with internal audit and legal) publishes a specification document: “HIPAA Health Information Retention Policy v2.1: All datasets marked pii_type=health_status must be retained for [duration], encrypted with AES-256, with access logs sent to the central audit repository using the schema [schema]. Compliance verification: domains must provide quarterly attestations using [audit template].”
Wealth management owns the implementation. It uses whatever database technology it chose. It implements encryption. It logs access. Quarterly, it submits an attestation—signed by a wealth management data steward—confirming it meets the spec.
Central governance spot-checks a sample of domains (10–15% annually) using internal audit. That’s it. No central infrastructure, no handoffs, no bottleneck.
This shifts compliance from an operational burden to an accountability model. Each domain is responsible. Central governance sets expectations and assures adherence.
Operationally, this requires a small central compliance data governance team (three to five people) that publishes specifications quarterly, maintains an attestation registry, and coordinates spot audits with internal audit. Domains embed a compliance owner (part of the data steward role) who owns the implementation and attestation.
I’ve found this scales to hundreds of data products where centralized infrastructure-level compliance doesn’t.
Light-Touch Governance: What It Actually Means
These three resolutions share a pattern: light-touch governance is not “no governance.” It’s governance that operates at the protocol level, not the implementation level.
Governance sets the rules of the road. Domains drive on them.
In practice, this means a small central team (5–8 people for a large organization) that:
- Publishes metadata standards (registry schema, lineage event format, compliance specification templates)
- Operates shared infrastructure (metadata event stream, data product registry, attestation tracking)
- Audits and escalates breaches (spot checks, incident response, governance exceptions)
What it does NOT do:
- Approve schema changes
- Review data product designs
- Own or manage data infrastructure
- Enforce technical standards (technology is a domain choice)
- Centralize compliance controls
The teams that fail at this hybrid model usually do so because they try to centralize at the wrong level. They create a central data architecture team that approves designs (implementation level). They create a central metadata team that owns the data dictionary (implementation level). They create a central compliance team that enforces encryption (infrastructure level).
Then they get frustrated that mesh teams move slowly. Of course they do—they’re waiting for central approvals.
The organizations I’ve seen succeed treat governance as a layer above implementation. The central team says: “Use any database you want, as long as you expose your data product schema via the metadata registry and log access via the audit schema.” Domains have freedom. Central governance has visibility and assurance.
Bottom Line
Data mesh and data governance don’t collide if you separate protocol from implementation. The central function publishes what must be true (metadata standards, compliance specifications). Domains own how to make it true. This resolves the three sharpest conflicts: metadata standards become interface contracts, not data dictionaries; lineage tracking becomes asynchronous event streams, not change committees; and compliance becomes domain-owned implementations of central specifications, not centralized infrastructure.
Light-touch governance is harder to design than either pure centralization or pure autonomy. It requires small, skilled central teams and domain teams that take ownership seriously. But it’s the only model I’ve seen that works at scale in regulated industries where autonomy and control must coexist. The financial services example—retail banking and wealth management moving fast while meeting regulatory requirements—only works if the governance layer stays thin and focused on protocol, not implementation.
Frequently Asked Questions About Data Mesh and Data Governance
What’s the difference between data mesh governance and traditional enterprise data governance?
Traditional governance centralizes decision-making and control. Data mesh governance decentralizes implementation but centralizes protocol—the rules that enable domains to interoperate. The difference is subtle but critical: traditional governance says “the central team approves your schema”; mesh governance says “your schema must follow this metadata standard.”
Can a domain ignore central governance if it’s implementing mesh?
No. Domains own implementation, but they’re accountable to central protocols. If you declare a data product but don’t register it in the metadata registry, it’s not visible to consumers and auditors. If you handle PII but don’t implement the central compliance specification, you’re in breach. The difference is that compliance is verified through attestation and audit, not pre-approval.
Who should run the central governance function in a mesh?
A small team of 5–8 people, reporting to the Chief Data Officer or Chief Information Officer. They should include at least one person with compliance background, one with metadata/integration experience, and one with audit or internal control experience. They should not include domain architects—that’s a conflict of interest.
How do you prevent domains from implementing conflicting lineage standards?
By publishing a lineage event schema before domains build integrations. The schema specifies what fields are mandatory (source dataset, target dataset, transformation logic, owner, timestamp) and what optional fields domains can add. Domains then emit events that conform to this schema. The central team operates the event stream; it does not interpret or approve the events.
What happens if a domain wants to change a data product that other domains consume?
The domain publishes the change as a metadata event. Consuming domains get notified via the event stream. The consuming domain assesses impact and may request an extension period if they need time to adapt. But the producing domain is not blocked by a change committee. If the change is truly breaking and impacts multiple domains, the cCDO may escalate to a data leadership forum, but that’s for visibility, not approval.
Is light-touch governance just decentralization without accountability?
The opposite. It distributes accountability clearly: each domain is accountable for its data product quality, metadata accuracy, and compliance posture. Central governance is accountable for maintaining protocol standards, auditing adherence, and resolving cross-domain disputes. Accountability is clearer because responsibility is explicit at each level.
How do you scale light-touch governance as the organization grows?
By maintaining the ratio of central governance to domains at roughly 1:50–1:100. If you grow to 200 data products, you add one or two people to the central team—not five. You don’t add process; you add tooling and automation (metadata scanning, automated audit report generation, compliance checklist templates).
What’s the biggest risk of light-touch governance?
Assuming “light-touch” means “hands-off.” Organizations that adopt mesh governance and then starve the central function of resources end up with chaotic metadata, unmapped lineage, and compliance gaps. The central function needs to be small, but it needs to be expert and well-funded. Underfunding it is more expensive than centralized governance because the cost is paid in remediation, not prevention.