On-Demand Webinar · 1 hr 3 min

Connecting Your Data Mesh with DataOps

A data mesh organizes data work into decentralized domains, but it says nothing about the operational processes behind the architecture: how you orchestrate, test, develop, and deploy within and across domains. Chris Bergh works through what a data mesh and DataOps each are, how they fit together, and what keeps a mesh from turning into a mush. Recorded May 2021; updated August 2026.

Presented by Chris Bergh

What you'll learn 8 points
  • Data mesh is presented as an organizing principle for data systems rather than a technology: work is split into discrete domains, each domain works autonomously, teams stay with the domain they know, and the focus is a data product with a customer.
  • Most companies are organized by data processing capability or task type, which puts a wall between every step. A single change then has to be coordinated across several teams, and that is what slows delivery down.
  • Data mesh is really an organization mesh: full end-to-end ownership of a domain goes to one cross-functional team of five to nine people, on the microservices model where one team owns development, test, deployment and operation.
  • A domain interface answers five questions, each of which can be a URL: the Where (how to find and access the data securely), the What (a description of the data, such as a catalog page), the When (processing results, timing, test results and status), the How (steps, code, config, toolchain and pipeline) and the With (the raw data or upstream domain it consumes, ideally immutable).
  • Domains coordinate through six link types: two domain queries covering freshness and test results, two process linkages that hand off control and parameters, event linkage, data linkage on a shared table, and development linkage covering whether a domain can be recreated and changed in development with a path to production.
  • The commercial pharma example maps three domains to product lifecycle phases: non-personal promotion at launch, physician during growth, and payer in the mature phase, each with its own data sources and its own cycle time.
  • Mastering shows why domains need separate layers: there are one million physicians in the US but a company physician master of only 40,000, and that work is done by a team working independently of the warehouse and self-service layers.
  • Data mesh addresses data and architecture but not the operating process, so a mesh still needs orchestration across domains, production testing, and a way to change one domain in development without breaking the ones downstream.

Slides

44 slides

Questions from this session

What is a data mesh?

A data mesh is an organizing principle for data systems, borrowed from domain-driven design in software. Work is divided into discrete domains, each domain team works autonomously and stays with the data it knows, and each domain treats its data as a product with real customers. It is a response to centralized systems failing and skill-based roles being too slow to answer customer needs.

What does a data domain contain?

A domain contains five things: the data, the artifacts created from it such as models, views, reports and dashboards, the code that acts on the data such as pipelines and toolchains, the team that creates, updates and runs it, and the metadata including catalogs, lineage, test results and processing history. Domains aligned with sources hold mastered entities and raw facts; domains aligned with consumption hold integrated data, star schemas and aggregated views.

What makes a good data domain?

Seven properties. The domain should be trusted, usable by the team's customer, discoverable, understandable and well described, secure and permissioned, and driven by URLs or APIs so it can interoperate with other domains. Seventh, it should give the customer one place to report a problem, get updates on the fix, and ask for new insight that reaches production quickly.

How do domains in a data mesh coordinate?

Each domain runs its own update processing on its own toolchain, triggered by schedule, by order of operations, or by an event such as new data arriving. Above them sits a master DAG, a DAG of DAGs, that runs them all. Between domains there are queries about freshness and test results, process handoffs with parameters, events, shared tables, and development links for recreating a domain safely.

Why does a data mesh need DataOps?

Data mesh concentrates on data and architecture and says little about the operating process, which is where a mesh actually breaks. A code change or a new data set in one domain can affect everything downstream, so the mesh needs orchestration across domains, production testing and monitoring, and encapsulated development environments that let a team change one domain locally while global governance and control still hold.

What does the commercial pharma data mesh example look like?

US commercial pharma analytics splits into three domains matched to the product lifecycle: non-personal promotion, meaning email, website visits and radio ads, which matters most at launch; physician, meaning doctor sales, claims and anonymized patient data, which matters most during growth; and payer, meaning plans, rebates and formulary, which matters most in the mature phase. Each domain has its own sources and its own cycle time.

Where to go next