Designing a data mesh operating model: roles, responsibilities, and boundaries

Designing a data mesh operating model: roles, responsibilities, and boundaries

Simor Consulting | 06 Sep, 2026 | 04 Mins read

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.

Shipping a production AI system?

Find the control gaps before they turn into incidents. Take the AI Production Scorecard for a fast baseline across the seven layers, or book an architecture review and we will turn it into a hardening plan.

Similar Articles

5 AI Workflows Professional Services Firms Can Deploy This Quarter
5 AI Workflows Professional Services Firms Can Deploy This Quarter
10 Jul, 2026 | 09 Mins read

Professional services firms sell judgment, billed by the hour or by the matter. That makes them both the biggest winners and the most cautious adopters of AI. The upside is real: every firm carries ho

Legacy Data Pipeline Modernization Without Rewriting Everything
Legacy Data Pipeline Modernization Without Rewriting Everything
10 Jul, 2026 | 07 Mins read

The pipeline runs every night at 2 a.m. Nobody fully understands it. The original author left in 2019. It is part SAS, part shell, part stored procedures, and part a spreadsheet someone emails in. It

Lightweight MLOps for Mid-Market Teams: Ship Models Without a Platform Engineering Org
Lightweight MLOps for Mid-Market Teams: Ship Models Without a Platform Engineering Org
10 Jul, 2026 | 11 Mins read

A head of ML at a 120-person company told us recently that his team had spent nine months trying to stand up a "proper MLOps platform." They had evaluated three orchestration tools, designed a feature

Building AI-Ready Data Pipelines: Key Architecture Considerations
Building AI-Ready Data Pipelines: Key Architecture Considerations
04 Mar, 2025 | 02 Mins read

Data pipelines built for business intelligence often fail when supporting AI workloads. The root cause is usually architectural: BI pipelines assume bounded, relatively static datasets, while AI syste

Anatomy of an AI Incident: Post-Mortem of a Model Provider Outage
Anatomy of an AI Incident: Post-Mortem of a Model Provider Outage
19 Jun, 2026 | 09 Mins read

On a Tuesday at 2:14 PM, a major model provider began returning elevated error rates for a specific model endpoint. By 2:31 PM, a customer support platform that depended on that endpoint was producing

AI Rollback Patterns: When to Roll Back a Prompt, a Model, or the Whole Release
AI Rollback Patterns: When to Roll Back a Prompt, a Model, or the Whole Release
27 Jun, 2026 | 11 Mins read

Software rollbacks are well-understood. You deploy a new version, detect an issue, and roll back to the previous version. The rollback is atomic: the entire application reverts to the previous state.

The 7-step vector database selection checklist
The 7-step vector database selection checklist
26 Apr, 2026 | 06 Mins read

Most vector database selection failures come down to one mistake: picking the technology before mapping the workload. Teams benchmark embedding search speed on a curated dataset, pick the fastest opti

Build vs buy: a decision tree for AI infrastructure
Build vs buy: a decision tree for AI infrastructure
03 May, 2026 | 06 Mins read

Every AI infrastructure team eventually faces the same argument. One faction wants to build a custom solution because the commercial options do not handle their specific requirements. The other factio

How to design a prompt ops pipeline from scratch
How to design a prompt ops pipeline from scratch
10 May, 2026 | 06 Mins read

Prompt management in most AI teams starts the same way. One engineer writes a prompt, it works well enough, and the prompt gets committed to a config file. Three months later, there are forty prompts

The data quality scorecard: metrics that actually matter
The data quality scorecard: metrics that actually matter
17 May, 2026 | 06 Mins read

Most data quality initiatives fail not because teams lack tools, but because they measure the wrong things. Teams track hundreds of data quality metrics, generate dashboards full of green indicators,

Conference report: key takeaways from Data Council 2026
Conference report: key takeaways from Data Council 2026
23 May, 2026 | 04 Mins read

Data Council 2026 wrapped in Austin last week, and the signal-to-noise ratio was higher than in recent years. The conference has historically been the venue where data infrastructure practitioners — n

A cost optimization framework for LLM inference
A cost optimization framework for LLM inference
24 May, 2026 | 06 Mins read

LLM inference costs follow a pattern that catches teams off guard. The first prototype costs almost nothing -- a few hundred dollars a month during development. The pilot scales to a few thousand. Pro

Migration playbook: batch to streaming in 5 phases
Migration playbook: batch to streaming in 5 phases
31 May, 2026 | 06 Mins read

The case for streaming is straightforward: data that arrives in minutes instead of hours enables decisions that were previously impossible. Fraud detection catches transactions before they clear. Pers

How to audit your AI pipeline for bias -- step by step
How to audit your AI pipeline for bias -- step by step
07 Jun, 2026 | 06 Mins read

Bias in AI systems is not a theoretical risk. It is a measurable property that can be detected, quantified, and mitigated at every stage of the pipeline. The teams that treat bias as an audit problem

The 30-day AI readiness assessment
The 30-day AI readiness assessment
14 Jun, 2026 | 07 Mins read

Organizations that skip readiness assessment before investing in AI tend to discover their gaps expensively. A financial services firm spent four months building a customer churn prediction model only

The death of the dashboard: what replaces BI?
The death of the dashboard: what replaces BI?
20 Jun, 2026 | 03 Mins read

The traditional BI dashboard — a grid of charts that a business user opens every morning to check KPIs — is losing its grip on how organizations consume data. The decline is not dramatic. No one decla

Your first 90 days as a Head of AI Engineering
Your first 90 days as a Head of AI Engineering
28 Jun, 2026 | 07 Mins read

The first Head of AI Engineering at a company inherits one of three situations. Situation one: there is no AI team, no AI infrastructure, and the mandate is to build from scratch. Situation two: there

Data Pipelines for Time Series Forecasting
Data Pipelines for Time Series Forecasting
21 Mar, 2024 | 02 Mins read

Time series forecasting requires specialized pipeline architecture. Unlike standard batch processing, time series work demands strict chronological ordering, historical context, time-based feature eng

The RAG evaluation framework you'll actually use
The RAG evaluation framework you'll actually use
08 Jul, 2026 | 06 Mins read

Most RAG systems are evaluated with vibes. An engineer runs ten queries, eyeballs the results, and declares the system "working." Three months later, a customer reports that the system confidently ret

Why your AI strategy needs a data strategy (not the other way around)
Why your AI strategy needs a data strategy (not the other way around)
11 Jul, 2026 | 03 Mins read

The majority of enterprise AI strategies are built on an implicit assumption: that the organization's data is ready to support AI workloads. The assumption is almost always wrong. Data that is adequat

How to write an AI incident response plan
How to write an AI incident response plan
12 Jul, 2026 | 07 Mins read

AI systems fail differently than traditional software. A traditional software bug produces incorrect output deterministically -- the same input always produces the same wrong output, and a fix elimina

Data Contracts: Building Trust Between Teams
Data Contracts: Building Trust Between Teams
29 Jan, 2024 | 03 Mins read

Data contracts are formal agreements that define the structure, semantics, quality standards, and delivery expectations for data exchanged between teams. They specify schema definitions, SLAs, ownersh

Capacity planning for vector databases
Capacity planning for vector databases
19 Jul, 2026 | 07 Mins read

Vector database capacity planning fails in predictable ways. Teams estimate storage based on vector count alone and discover at 60% capacity that memory consumption is growing faster than disk because

The procurement checklist for AI vendors
The procurement checklist for AI vendors
26 Jul, 2026 | 07 Mins read

AI vendor procurement is where organizations make binding commitments that are expensive to unwind. A three-year contract with a model provider locks you into their pricing, their rate limits, their m

Setting up a model registry: the minimal viable approach
Setting up a model registry: the minimal viable approach
02 Aug, 2026 | 06 Mins read

A model registry is the version control system for your trained models. Without one, teams track model versions by filename, store artifacts in ad-hoc cloud storage locations, and discover which model

Data contract template and negotiation guide
Data contract template and negotiation guide
09 Aug, 2026 | 07 Mins read

Data pipelines break because data producers and data consumers have different assumptions. The producer assumes the consumer can handle null values in a column. The consumer assumes the column is neve

How to run an AI architecture review
How to run an AI architecture review
12 Aug, 2026 | 07 Mins read

An architecture review for an AI system catches design flaws at the cheapest possible stage: before implementation. A data pipeline that cannot handle the expected volume, a model serving architecture

The observability maturity model for AI systems
The observability maturity model for AI systems
16 Aug, 2026 | 07 Mins read

Most AI systems in production operate with observability that was designed for traditional software. Teams monitor CPU, memory, network, and error rates. These metrics tell you whether the server is r

Building an internal AI platform team: org chart and responsibilities
Building an internal AI platform team: org chart and responsibilities
23 Aug, 2026 | 07 Mins read

The decision to centralize AI infrastructure into a platform team usually comes after a period of decentralized pain. Three product teams independently built model serving pipelines. None of them shar

LLM cost calculator: estimating spend before you deploy
LLM cost calculator: estimating spend before you deploy
30 Aug, 2026 | 05 Mins read

Teams approve LLM projects based on per-query cost estimates, then get blindsided by the actual invoice. The gap between estimate and reality is not a rounding error. It is a structural problem: the e

The rise of vertical AI: industry-specific models outperform generalists
The rise of vertical AI: industry-specific models outperform generalists
12 Sep, 2026 | 04 Mins read

The benchmark results from the past quarter are hard to ignore. On tasks spanning legal document analysis, medical coding, financial risk assessment, and manufacturing quality inspection, vertical AI

The LLM cost optimization playbook: 12 techniques that actually save money
The LLM cost optimization playbook: 12 techniques that actually save money
13 Sep, 2026 | 04 Mins read

LLM costs are easy to start and hard to control. A team ships a feature that calls GPT-4, the feature works, users like it, and the invoice climbs 15 percent month over month. The cost is not a proble

Building Synthetic Data Pipelines for ML Testing
Building Synthetic Data Pipelines for ML Testing
24 May, 2024 | 04 Mins read

# Building Synthetic Data Pipelines for ML Testing Synthetic data addresses real ML development problems: privacy restrictions on real data, class imbalance, and edge case coverage. It does not repla

Feature Store Architectures: Building the Foundation for Enterprise ML
Feature Store Architectures: Building the Foundation for Enterprise ML
18 Jan, 2024 | 03 Mins read

Organizations scaling ML efforts encounter a predictable problem: feature engineering work duplicates across teams, training-serving skew causes model failures in production, and point-in-time correct

Time-Travel Queries: Implementing Temporal Data Access
Time-Travel Queries: Implementing Temporal Data Access
02 Oct, 2024 | 03 Mins read

Time-travel queries—the ability to access data as it existed at any point in the past—have become essential in modern data platforms. This capability transforms how organizations approach data governa

Choosing a Vector Database for Production AI Applications
Choosing a Vector Database for Production AI Applications
10 Jul, 2026 | 12 Mins read

You have a retrieval-augmented generation proof of concept that works on a laptop. The embeddings are in a CSV file, the search is brute force, and the demo impresses the steering committee. Now someo