Digital Transformation | June 2026
In March 2019, Zhamak Dehghani then principal technology consultant at Thoughtworks published an article on the Thoughtworks website titled “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.” The piece ran to several thousand words and proposed a fundamental rethinking of how analytical data should be owned, produced, and managed in large organisations. Within two years, it had been read hundreds of thousands of times, cited in board-level technology strategies, and spawned a book, a conference track, and a consulting practice. The data mesh was the most contentious idea in enterprise analytics since the original Inmon-Kimball debate.
The Problem Dehghani Identified
Dehghani’s diagnosis began with a structural observation: as organisations grew in the number of business domains, source systems, and analytical use cases the centralised data team became a bottleneck. Data engineers in a central platform team were the only people authorised to build data pipelines, build data models, and publish trusted datasets. Every request from every domain team marketing, sales, finance, supply chain went through the same central queue. The queue was always longer than the team could service. The data team was perpetually behind, perpetually apologising, and perpetually blamed for slowing the business down.
The response organisations typically made hiring more data engineers, buying more ETL tooling, building better data platforms treated the symptom rather than the cause. The cause, Dehghani argued, was the architecture: a centralised model of data ownership that did not scale with organisational complexity. The solution was not a better centralised platform. It was a fundamentally different model of ownership.
The Four Principles of Data Mesh
1. Domain-oriented decentralised data ownership and architecture. The people who generate data the domain teams responsible for orders, customers, inventory, payments should also own the analytical representation of that data. The team that runs the order management system should be responsible for producing and maintaining the “orders” dataset for analytical consumption. Ownership of data production aligns with ownership of the operational system that generates the data.
2. Data as a product. Each domain team’s data offering should be treated as a product with consumers: discoverable, addressable (with a stable API or endpoint), understandable (documented, with clear semantics), trustworthy (with quality SLAs), accessible (to authorised consumers without per-request engineering effort), and interoperable (following shared standards). A “data product” is not a dataset dumped into a lake; it is a governed, maintained, SLA-backed service.
3. Self-serve data infrastructure as a platform. For domain teams to own and produce data products without becoming infrastructure teams themselves, a central platform team must provide the tooling that makes production and consumption easy: the cataloguing system, the access control layer, the monitoring framework, the pipeline templates. The platform team’s job shifts from building pipelines to building the platform on which domain teams build their own pipelines.
4. Federated computational governance. Standards that must apply across all data products data quality expectations, privacy classifications, access control policies, regulatory compliance requirements are set centrally but enforced computationally. Rather than requiring a central team to review every data product, governance policies are expressed as code and applied automatically at production and consumption time.
Data Contracts: The Formal Interface
A key engineering artefact that emerged from data mesh thinking and has since gained independent momentum is the data contract: a formal agreement between a data producer and a data consumer specifying the structure, semantics, quality expectations, and SLAs of a dataset. A data contract is a schema with obligations attached: the producer commits to maintaining the schema, delivering data within a specified latency, and meeting quality thresholds; the consumer commits to handling the data within the contract’s terms and notifying the producer of issues.
Data contracts address a chronic source of data incidents: breaking changes in source data that are not communicated to downstream consumers. When the orders domain team renames a column, changes a data type, or removes a field, every pipeline built on that data silently breaks sometimes days or weeks later, when an analyst notices an anomaly. A data contract makes the interface explicit and breaking changes detectable: automated schema validation at production time would catch a column removal before it propagated downstream.
Where Data Mesh Has Succeeded and Struggled
Data mesh has been adopted in varying degrees of completeness at organisations including JPMorgan Chase, Zalando, Intuit, and numerous others. The implementations that have succeeded share common characteristics: strong executive sponsorship, an existing culture of domain team autonomy, and a central platform team willing to redefine its role from builders of pipelines to providers of infrastructure.
The implementations that have struggled tend to encounter the same failure modes. Domain teams that lack data engineering capacity cannot build and maintain data products without significant support. The principle of domain ownership is undermined when the “domain team” is a small operational team with no analytics capability. Data contracts that are defined but not enforced technically become aspirational documents that are ignored when they are inconvenient. The federated governance model requires both the authority to set standards and the technical capability to enforce them computationally a combination that is difficult to establish in organisations with fragmented technology governance.
References
- Dehghani, Z. (2019). How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh. Thoughtworks Insights.
- Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly Media.
- Thoughtworks Technology Radar (2021). Data Mesh (Adopt). Volume 24.
- Machado, I. et al. (2022). Motivations, Benefits, and Issues for Adopting a Data Mesh Architecture. Proceedings of IEEE CLOUD 2022.
- Kleppmann, M. (2019). Designing Data-Intensive Applications. O’Reilly Media.
- Beauchemin, M. (2022). The Shift Toward Data Contracts. Substack.
- Atwal, H. (2020). Practical DataOps: Delivering Agile Data Science at Scale. Apress.
