olivlawolivlaw

From books

Lesson 7 · The data mesh moves ownership of data to the domain that produces it; the platform and the rules stay shared.

Zhamak Dehghani · Data Mesh Principles and Logical Architecture · 2020 · Data Mesh Principles and Logical Architecture, martinfowler.com (2020) — cele patru principii, în ordinea din articol2 minutes read
“Domain-oriented decentralized data ownership and architecture. Data as a product. Self-serve data infrastructure as a platform. Federated computational governance.”Zhamak Dehghani · Data Mesh Principles and Logical Architecture · 2020 · Data Mesh Principles and Logical Architecture, martinfowler.com (2020) — cele patru principii, în ordinea din articol

A data product has an owner, a schema, an SLA and an address — otherwise it is just a table.

The problem the data mesh solves is organisational: the central data team becomes a bottleneck and does not know the semantics of twenty domains; when an order "was cancelled" means something different in logistics than in billing, the central team finds out last. The first principle moves ownership to the domain. The second requires what the domain publishes to be a product: a dataset with a schema, an owner, an SLA, documentation, an access address — discoverable, trustworthy, interoperable. The third, the self-serve platform, is what makes the first two possible: teams publish without each building their own infrastructure. The fourth, federated computational governance, says the shared rules — what counts as PII, which formats, which identifiers — are code checked automatically, not a committee. The trap: a mesh without a platform is twelve incompatible warehouses with a new name. And scale matters: for a company with a single data team, a well-modelled central warehouse is the right answer, not a scaled-down mesh.

The card says who becomes the owner. The next step is why: ownership is not just a task, it is knowledge. Whoever produces the data understands what it truly means. When an order being "cancelled" means one thing in logistics and another in billing, no central team can guess that correctly. It is like asking a translator to render a legal contract without ever having seen one. Moving ownership to the domain moves the semantic decision to where the meaning lives. The central team does not vanish; it simply stops being the bottleneck through which every question of meaning must pass. But once each domain owns its own meaning, a new question appears: what exactly should it publish, so that others can trust it?

Passage 1 ended on the question of trust. Dehghani's answer is that a domain doesn't publish a dataset; it publishes a product. A product has a user, a promise, and an owner. A schema, documentation, an access address, and an agreement on how fresh the data is. Think of a rental apartment: you don't just get a key, but a contract, a landlord to contact, an accurate listing. Without these, every consuming team must call someone and ask what each column means. That rebuilds the bottleneck through another door. Treating data as a product means the logistics team no longer answers phones; it answers with a clear catalog. But a good product needs a shelf to sit on. Where does that shared shelf come from?

Why it matters Most "mesh" failures are platform failures: ownership was decentralised before there was anything shared to publish on.

DomainownershipData as aproductSelf-serveplatform
Federated governance is what keeps the three circles overlapping rather than merely adjacent.
Open on YouTube ↗

← Back to the feed