Most data mesh initiatives fail not because the architecture is wrong, but because nobody can answer the question: who owns this data product? When ownership is ambiguous, quality drops, SLAs go unmet, and teams point fingers at each other during incidents. The architecture decision is the easy part. The operating model — who does what, who decides what, and who is accountable when things break — is where data mesh lives or dies.
This post gives you an operating model framework that maps roles to responsibilities with clear boundaries. Not a reorganization plan, but a decision framework you can adapt to your existing structure.
The Core Problem with Centralized Data Teams
Centralized data teams become bottlenecks. Every domain team submits requests to the central team, the central team prioritizes, and the domain teams wait. The central team does not understand the business context of the requests. The domain teams do not understand the infrastructure constraints. Both sides are frustrated, and the data products ship late with quality that satisfies nobody.
Data mesh distributes ownership to the domains that understand the data. This is the right instinct. But distribution without a clear operating model creates a different problem: nobody is responsible for cross-cutting concerns like data discovery, access control, and platform reliability. Each domain builds its own version of these capabilities, and the result is a fragmented mess that is harder to operate than the centralized system it replaced.
The Four Roles
Domain Data Owner
Every domain that produces data products has a data owner. This person is accountable for the quality, timeliness, and documentation of the domain’s data products. They are not necessarily the person who builds the pipelines. They are the person who decides what data products the domain will produce, what SLAs they will meet, and how they will handle schema changes.
The domain data owner sits within the business domain, not in a central data team. They report to the domain leadership. They have the authority to prioritize data product work within the domain’s backlog. Without this authority, the role is hollow — accountable for outcomes they cannot influence.
Prerequisites for this role to work: the domain must have at least one engineer capable of building and maintaining data products. If the domain has no data engineering capability, the role becomes a requestor who depends on a central team, and you are back to the bottleneck model.
Data Product Engineer
The data product engineer builds and maintains the pipelines, transformations, and interfaces for a domain’s data products. They implement the contracts defined by the domain data owner. They are responsible for pipeline reliability, schema evolution, and performance.
This role can be a dedicated position or a shared responsibility within a domain engineering team. The critical constraint: the data product engineer must have access to the source systems within their domain and the skills to build production-grade pipelines. A software engineer who also writes SQL transformations is viable. A business analyst who writes occasional queries is not.
Platform Engineer
The platform team provides the infrastructure that domain teams use to build, deploy, and operate data products. This includes the compute layer, the storage layer, the catalog, the access control system, and the monitoring infrastructure. The platform team does not build data products. They build the platform on which data products run.
The platform team’s SLA is to the domain teams, not to end users. If the platform is slow, the domain teams cannot meet their SLAs to consumers. The platform team needs its own monitoring, its own on-call rotation, and its own incident response process.
The common failure mode: the platform team starts building data products for specific domains because “it was easier to just do it ourselves.” This erodes domain ownership and re-centralizes the work. The platform team must resist this temptation. If a domain cannot build a data product, the answer is to help them build capability, not to build it for them.
Data Governance Lead
The governance lead defines cross-domain standards: naming conventions, classification schemas, access control policies, and quality thresholds. They do not approve every data product. They define the rules within which domain teams operate, and they audit compliance.
The governance lead must have the authority to enforce standards but must not become a gate that slows down data product delivery. The operating model should define which decisions require governance approval and which are at the domain’s discretion. A reasonable split: schema standards and classification require governance approval. Pipeline implementation and transformation logic do not.
Responsibility Matrix
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
Boundary Disputes and How to Resolve Them
The most common boundary dispute is about shared data. Customer data, for example, is produced by the sales domain but consumed by marketing, finance, and product. Who owns the customer data product?
The answer: the domain that produces the authoritative source owns the data product. Sales produces the authoritative customer record. Sales owns the customer data product. Marketing consumes it but does not own a separate version. If marketing needs customer data enriched with campaign data, marketing owns an enriched data product that references the sales-owned customer product as a dependency.
Document every cross-domain data dependency. When domain A’s data product depends on domain B’s data product, both domains need to know about the dependency. The domain data owner in domain A should have a documented SLA expectation from domain B. When domain B changes their schema, domain A must be notified before the change, not after.
Scaling the Operating Model
The four-role model works for organizations with 3-8 data-producing domains. Beyond that, you need intermediate layers.
For 8-20 domains, add domain data stewards who coordinate across related domains. A commerce domain steward might coordinate sales, marketing, and fulfillment data products. The steward does not replace the domain data owners. They facilitate cross-domain alignment.
For 20+ domains, add a data mesh council — a rotating body of domain data owners who meet monthly to resolve cross-domain disputes, approve shared standards, and prioritize platform improvements. The council is not a governance board that approves every decision. It is a coordination mechanism for decisions that affect multiple domains.
Next Step
Map your current organization to the four roles. For each domain that produces data, name the domain data owner and the data product engineer. If you cannot name them, that domain does not have data mesh capability yet, and that is the first thing to fix before writing any architecture documents.