“The franchise hands out sauces — not raw ingredients, not finished pizzas. The difference between a real self-serve platform and institutional theater comes down to four concrete operational decisions.”
The sauces are on the table. The pizza is missing
Last time I left the mother sauces on the table in the central kitchen. The Business Vault’s Vault Components — product freshness v4.0, customer score v1.5, customer tenure v2.0 — versioned, certified, consumable from any branch. And I left the principle that lets that table grow without breaking what was already on it: Open/Closed, open for extension, closed for modification. Any of the 40 branches can hang a new satellite off the Customer hub without touching anything else. The chain grows without even noticing.
That’s the first principle of the third pillar.
But sauces on a table are not a pizza. And the next question is the one that decides whether the franchise scales with its head on straight or ties itself in knots within two years: how does Ana’s kitchen — and Marlene’s in Chicago, and the new branch’s in Denver — combine those mother sauces with what belongs to their own branch? Without touching the sauces. Without waiting for permission. Without rewriting the common manual.
And then the question that decides whether the platform is genuinely self-serve or just institutional theater dressed up as digital transformation: what four things does a branch need to open, compose its local pizza and serve from the very first customer — without falling into the two dangerous extremes that have been sinking data projects for twenty years?
Today I answer both.
Let’s take it step by step.
Axis 1 — Strategy and Composition over Inheritance
How does Ana’s kitchen combine the mother sauces the central kitchen distributes with what is her branch’s own? The question sounds silly — “she puts them together in a recipe, hits the button, out comes the pizza” — but the underlying mechanics are the difference between a franchise that holds up and one that gets tangled in its own object model within a couple of years.
To see it cleanly, let’s step over to another case for a moment. There’s a branch in Denver — the Mile High City, 1,609 meters above sea level — and another in Rome, 21 meters above sea level. Both make the same classic Neapolitan from the common menu. Same dough, same San Marzano sauce, same mozzarella di bufala, same olive oil. The product the customer gets is indistinguishable.
But the Denver oven and the Rome oven don’t behave the same. Altitude changes how heat behaves — baking at 1,600 meters is not baking at 21. The Denver oven needs thirty extra seconds at the same temperature to hit the same bake profile as Rome’s. If Denver bakes on Rome’s timings, the pizza comes out raw in the middle. If Rome bakes on Denver’s timings, it comes out charred on the outside. The oven’s technical parameter is local. The recipe isn’t.
There are two ways to manage that difference. And the one you pick decides whether the chain scales with its head on straight or ties itself in knots.
In the software design catalog, the first way is called inheritance: the Denver branch inherits from the base recipe “classic Neapolitan” and overrides the “calculate oven time” method to slip in the altitude adjustment. If a branch in Aspen wants its own timings, it inherits again. If one in Cuenca wants its own, it inherits again. Every variant is a new class in a hierarchy that grows and tangles with every branch.
Put like that, it sounds reasonable. It is — for six months. Two years in, when there are 40 branches with their own hierarchies, each with its own inheritance tree, and the central kitchen decides to move the tomato sauce from v3 to v4 — because the supplier changed, or the regulation did — the cascading effects through those hierarchies are unpredictable. One branch stops working because it depended on an accidental behavior of the parent’s old version. Another starts acting strange because it inherited from a parent that inherited from a grandparent with a dead branch. It’s the classic hell of deep inheritance.
The second approach, the one the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) formalized in Design Patterns (1994), is the opposite. It’s called composition over inheritance, and in the book’s canonical wording it goes like this:
Favor object composition over class inheritance.
In plain English: instead of building a rigid hierarchy of subclasses that override behavior, you inject the behavior from outside, as an interchangeable piece that honors a contract. The pizza doesn’t inherit — it composes. The branch declares which Vault Components it will use and declares which local piece it adds on top. That local piece is a strategy — which is what gives the Strategy pattern, from the same Gang of Four book, its name — that honors a defined contract and gets injected without touching any of the shared code.
Applied to the oven: the Denver branch declares which Vault Components it consumes (the same as any other branch), and declares its local Strategy — a function of its own, living in its branch, that takes the altitude and returns the seconds to add to the base bake time. “At 1,609 meters, add 30 seconds to the base time at nominal temperature.” The Rome branch does the equivalent with its altitude: “at 21 meters, add 0 seconds.” Different Strategy, same contract. The composition is declarative: each branch says what it does, not how it does it.
The central system doesn’t need to know anything about the Denver oven or the Rome oven. Each branch declares its composition and the system executes it. If next week a branch opens in Aspen — three thousand meters above sea level — it declares its Strategy and gets to work. All three coexist, all three consume the same mother sauces, and none of them touches the others’ code.
The operational trick of Strategy is that the new piece doesn’t touch existing code. It gets added. Tested. Published. And when a neighboring branch wants to compose its own variant — its altitude, its humidity, its drafts — it looks at Denver’s as an example, but it doesn’t inherit it — it composes its own. Just as simple. Just as isolated.
That is Composition over Inheritance applied to a local product on a shared kernel. And it’s the second of the two software principles that make a self-serve platform operable. The one from the previous essay — Open/Closed — disciplined what gets modified in the common manual: nothing. This one — Composition over Inheritance — disciplines how each branch adapts the manual to its physical conditions: by composing, not inheriting.
🍕 A note before we go on: adjusting the oven for altitude is a technical parameter — altitude is physics; the branch doesn’t get to choose it. But the branch can also make menu decisions — which local pizzas it adds, which neighborhood ingredients it brings in, which customers it cultivates. Those decisions are qualitatively different, and they’re what closes the block in the next parts. The difference between “adjusting the oven for altitude” and “deciding which local pizza this branch serves” is the difference between the third pillar of Data Mesh (which closes today) and the fourth (which closes the block). Self-serve provides the sauces; Data as a Product decides what gets served. Today we’re on the sauce level. In the next essays we’ll get to the menu.
Axis 2 — A self-serve platform without falling into the two dangerous extremes
We’ve reached the close of the third pillar of Data Mesh — the Self-serve Platform — and this is where something needs saying plainly, because it’s the pillar where almost every real implementation I see in large organizations lives at one of the two dangerous extremes.
Extreme 1 — Hand out only raw ingredients
One way to phrase the first risk, in the language of the Data Vault canon: self-service without guardrails destroys trust. It’s what happens when a data platform boils down to “here’s BigQuery, here are the raw datasets, knock yourself out.” The central team provides the infrastructure, the access, the credentials. Whatever each domain does with it is its own problem.
The branches end up rewriting the product freshness calculation each in their own way. One in Boston uses one formula. Another in Chicago uses a slightly different one. A third in Rome invents its own variant because “the products are different here.” The chain breaks into silos. Governance dissolves because every domain is sovereign over its own calculation. And when someone asks, at chain level, “what’s the average product freshness across the whole network?”, the answer doesn’t exist, because every domain measures different things under the same name. Local autonomy has turned into anarchy.
That is exactly what twenty years of Data Vault projects going into production without discipline have produced in real industries. And it’s why Dan Linstedt devotes entire chapters of the DV 2.0 canon to mother sauces, Vault Components and the Business Vault — so that the word “self-service” doesn’t become a synonym for “let every domain make up the shared stuff.”
Extreme 2 — Hand out finished dishes
And from applied architecture, another phrasing of the same limit — this time from the other side: a data platform delivers capabilities, not infrastructure and not finished products. What matters isn’t the SaaS with five terabytes or the canned reports that land in the director’s inbox at nine in the morning. What matters are the capabilities — primitive, reusable, composable operations — that the domain puts together to build its local product.
Whoever lands at the opposite extreme from the first one ends up at “the central team decides what you cook. We’ll send you four canned reports — don’t get clever.” Here the chain goes back to cookie-cutter: every branch with the same menu, zero room for the neighborhood. Operational speed dies. Branches wait on tickets. The pizza with a local neighborhood ingredient doesn’t exist — because it wasn’t in the central catalog, the central team doesn’t prioritize it, and the platform team has a six-month backlog. Autonomy doesn’t exist.
That closes the other side of the same limit. And it’s where almost every classic corporate Data Lake ends up: a central team controlling everything that gets served, a six-month ticket queue, and domains that stop asking for anything because they already know it won’t come.
The well-run franchise as the sweet spot between the two extremes
The two phrasings draw the two sides of the same limit. One from the DV 2.0 canon, the other from applied architecture. And what this series has been building since the start of this second block — the franchise, the mother sauces, the Vault Components, declarative composition — is the operational position that sits in the middle.
Hand out mother sauces — versioned Vault Components with their contract — and let each branch compose its menu. That is the self-serve platform that respects both limits at once: strong governance over what the whole chain reuses (the sauces), full autonomy over what each branch composes (the local pizza). And that’s why it resolves — without having to negotiate between the two voices — what both phrasings identify as risk from their respective sides.
What does it take for that platform to genuinely work? Four elements. Miss one and you’re back at the first extreme or the second — there’s no halfway.
An executable catalog of Vault Components with explicit contracts. “There are some calculations on the wiki” doesn’t cut it. The catalog is executable — each Vault Component publishes its contract (input, output, guarantees, version) somewhere the system can read it. The branch about to compose its recipe can see, before choosing, which Vault Components are available and what they guarantee. No meetings, no emails, no architect in the middle.
A declarative composition mechanism. The branch doesn’t write SQL to combine the mother sauces with its local Strategy. It declares the composition — “this recipe uses these three Vault Components, and my local Strategy does this.” The system interprets the declaration and executes it. The branch doesn’t touch shared code; the shared code is what interprets its declaration.
Inherited traceability. When a branch composes its recipe using Vault Components v3.2, v2.1 and v4.0, the resulting query inherits the traceability of all three. If tomorrow the “product freshness” Vault Component moves up to v4.1, the branch knows — because its composition says “I use v4.0” and the system tells it there’s a new version. If it never migrates, it keeps using v4.0 with the validity stamp from that time. If it decides to migrate, it does so explicitly. Versions aren’t imposed — they’re offered. And when an auditor asks “which version of freshness was that pizza using on March 14?”, the answer is attached to the model, not buried in logs.
Asymmetric certification — of the new Vault Component, not of every local composition. Here’s the nuance that decides whether the platform is real or theater. A branch’s local composition doesn’t need case-by-case approval. Ana opens her branch and starts composing Neapolitans; the Denver branch adjusts its oven for altitude; the Rome branch uses sea-level timings. Nobody asks permission. But a new Vault Component does go through certification before it enters the common catalog — because that one is code the whole chain will consume, that one is kernel, that one deserves a signature.
The asymmetry is deliberate and it’s the heart of the model: strong governance over the mother sauces (anything the whole chain will use the same way), full autonomy over local composition (anything that only affects one branch). That asymmetry is what keeps local autonomy from turning into anarchy and, at the same time, what keeps common governance from turning into a bottleneck. It’s the concrete answer to the two phrasings of the limit that opened this axis: to the first extreme (the guardrails exist — they live in the certification of the shared kernel) and to the second (what gets delivered is capabilities — not infra, not products).
“An operable self-serve platform is not a platform without governance — it’s a platform with asymmetric governance: strict over what the whole chain consumes, absent over what each branch composes.”
When these four elements are in place, the platform is genuinely self-serve. Ana opens the branch at seven and is serving by a quarter to eight. The Denver branch composes with its altitude. Rome with its own. The central team maintains the mother sauces. And the whole chain keeps speaking the same language because the shared kernel is respected without argument.
And that closes the third pillar of Data Mesh. The Self-serve Platform that Zhamak Dehghani defined as one of the four founding principles of the model is not a promise of a service catalog — it’s exactly this: a branch that helps itself to the mother sauces and composes its pizza without waiting on anyone.
“A franchise that scales hands out mother sauces. One that doesn’t hands out recipes or raw ingredients. The balance isn’t an option — it’s the only operable position.”
What’s next
The third pillar — Self-serve Platform — closes here. The sauces are on the table and each branch composes its pizza without asking permission.
But one remains: the dish. What reaches the diner with its menu, its price and its guarantee — not the sauce, not the oven, not the common contract.
And there’s a decision that neither the mother sauces nor local composition cover. At the Chicago branch, Marlene has had a crate of honey gold sitting on the counter for three weeks, mulling over a pizza that’s on nobody’s menu. The central catalog doesn’t carry that ingredient. The self-serve platform doesn’t decide for her. That neighborhood flavor, that menu only her branch signs — that decision is hers. And in the end, it’s what the customer actually eats.
Until the next part.