We've reached the end of our journey through the data kitchen.
In Week 2, the business (the chef) wrote the Recipe. In Week 3, the Platform stored the raw ingredients in the Pantry. In Week 4, we prepped those ingredients in the mise en place, building independent functions instead of fragile chains.
We have the perfect kitchen. The ingredients are ready, clean and calculated.
But the business doesn't walk into the kitchen to eat out of the prep bowls. The business wants a finished dish. A dashboard, a regulatory report, a predictive model. Something it can consume directly.
And this is where most companies make their last big mistake.
The “Mandatory Combo Platter” anti-pattern
Since the business usually doesn't have the tools to put together its own plate, it asks IT to do it.
“I need a table with customers, their average balances, their active campaigns and their risk score,” says Marketing. “I need the same thing, but with technical provisions and delinquency,” says Risk.
IT looks at the request queue (remember the bottleneck from Week 1?) and makes a decision that seems logical but is lethal: “Instead of building 15 different tables, I'll build one giant table with EVERYTHING. That way everyone eats from it and leaves me alone.”
And so the CLIENTES_FINAL_V3_DEF table is born. It has 500 columns. One plate to rule them all.
It's the culinary equivalent of making one gigantic combo platter with paella, sushi, a burger and chocolate cake, all mixed together, and forcing every customer in the restaurant to order exactly that.
What happens in practice?
- Marketing only uses 12 of the 500 columns. But when it asks for a new one (column 501), IT has to recalculate the entire table.
- Finance finds a bug in the “technical provisions” column. IT halts the table load to fix it. Marketing's dashboard (which doesn't use that column at all) wakes up empty.
- The table takes 6 hours to compute every night because it joins data from 14 different systems in a single monster query.
Trying to make a single dish that pleases everyone is the fastest way to couple the entire company together. If one goes down, they all go down.
But the problem with the one-size-fits-all dish isn't just that it breaks. It's that you can't evolve.
Here's a real case. A company has 130 data sources, one for each business application. All of them feed a shared processing engine with 5 or 6 chained steps before reaching the final table. One day, someone needs to add a new field.
What are your options?
Option A: do it right. You modify all 130 source definitions to account for the new field, and adapt the engine's 5 or 6 steps to propagate it. Cost: weeks of work, regression risk at every step, and coordination that drags in half the IT department. For one field.
Option B: do it “fast.” You reuse an existing field that's “not used anymore.” You change its meaning. Where it used to say “campaign code,” it now holds “customer segment.” The field travels through all 6 steps without a hitch because the structure doesn't change. It works. It ships fast.
But now you have a column called “COD_CAMPANA” that contains customer segments.
Six months later, a new analyst looks at the table. Sees COD_CAMPANA. Assumes it's a campaign code. Joins it to the campaigns table. The numbers don't add up. Loses two days investigating. Nobody told them that field no longer means what its name says.
And the worst part: this doesn't happen once. It happens with every field that gets reused. Over time, the table turns into a palimpsest where column names are fossils of what they once meant, and the real meaning is known only to the three engineers who've been on the project for years. If one of them leaves, the knowledge walks out the door with them.
Sound familiar? Two options: either it costs you an arm and a leg, or you lose all coherence in the table. That's the price of monolithic coupling.
And there's a third problem that's even worse, because it's silent.
On a previous project I ran into the ultimate monolithic table. Hundreds of columns. Everyone ate from it. But it had a trap nobody warned you about: it mixed granularities.
Some columns were at the contract level. Others were at the person level. In the same row. With no marker telling you which was which.
Why is that a problem? Because if a person has 2 contracts, that person shows up in 2 rows. If you sum a contract-level column, the result is correct. But if you sum a person-level column, you're double-counting the balance. And nobody warns you.
Those were the columns we knew about. The ones we knew how to interpret. For the rest, I had to sit down with the business and run queries until we figured out the granularity of every field we needed. “This field — is it per contract or per person?” “I'm not sure, let me check…” Hours of investigation for a table that supposedly had “everything.”
It had everything, sure. But without a 50-page manual, you couldn't use it without risking wrong numbers.
And that manual, of course, didn't exist. The knowledge of which columns you could sum and which you couldn't lived in the heads of two people. If one of them left, the next person would double-count balances without knowing it. And the report would look right. Until someone cross-checked it against another source and the numbers didn't add up.
The solution: the Open Data Buffet
If you have a good mise en place (Week 4), you don't need a mandatory combo platter. What you do is set up an Open Buffet.
The platform exposes all the ingredients, already prepped: the average-balance tray, the risk-score tray, the campaigns tray. Each tray is an independent component of the mise en place.
And now the Chef (the business) walks up to the buffet and builds their own plate.
- Marketing takes average balance, segment and channel. And builds its Data Mart (its data product).
- Risk takes average balance, score and delinquency. And builds its own.
- Finance takes technical provisions, average balance and exchange rate. And builds its own.
Nobody asks IT to plate their dish. The business serves itself.
And since the plates are independent, the decoupling is total. If Marketing decides to add a column to its Data Mart, Risk's Data Mart never notices. If Marketing's calculation fails, Risk's report still comes out perfect. There's no monolithic table tying them all together. Each team has its plate. Each plate stands on its own.
But for the business to serve itself at the buffet, there's a problem to solve.
The Facade: the little buffet labels
If the business walks into the technical kitchen (the data model we built in Weeks 3 and 4), it won't understand a thing.
It'll see tables with cryptic names, hash keys and versioning columns. It's like going to a buffet where, instead of “Bolognese Sauce,” the label reads “Emulsion of Solanum lycopersicum with ground bovine protein at 20% fat, cooked at 90°C for 120 minutes.”
Technically accurate. Inedible for the average diner.
Enter the Facade.
IT builds a view on top of all that technical complexity. A view that reconstructs the original table, but clean. For the business, the Facade is a little label that says “Customer.” When they run a query, they see the tax ID, the name, the address and the balance. Exactly as if it were a traditional flat table. They don't see the internal complexity.
In software engineering this has a name: the Facade pattern. The idea is simple: you put a clean, simple interface in front of a complex system. The user interacts with the interface. The complexity stays behind it. If tomorrow you reorganize everything behind the facade, the user never notices. They only see the label.
To make it concrete: without a facade, the business opens its query tool and sees tables with names like TBL_ENT_CLI_CORE, TBL_REL_CLI_CTR_001, TBL_ATR_CTR_FIN_V2. Columns like SK_HASH_CLI, DT_VALID_FROM, COD_HASH_DIFF. To run a simple query (“give me the customers with a balance over €100,000”) they need to know which table holds the identity, which one holds the attributes, how they join, and which versioning column to use to get the current record.
With a facade, they open their tool and see a table called “Customers.” With columns called Tax ID, Name, Address, Balance, Segment. They run their query directly.
The facade translates between what the business sees and what the kitchen has behind it. And if tomorrow IT reorganizes the kitchen (changes a partition, adds an index, migrates technologies), the facade stays the same. The business never notices.
The technical complexity is there — guaranteeing traceability, reprocessing and versioning — but it's invisible to the consumer. It's the shield that protects the business from IT's complexity. It's what lets the actuary, the controller or the analyst join data with a simple JOIN, without having to know how the kitchen is organized inside.
And there's a detail that isn't obvious: the Facade doesn't just simplify. It also protects. If tomorrow IT needs to reorganize the kitchen internally (add an index, change a partition, migrate technologies), the Facade stays the same. The business never notices. Exactly like in a restaurant: you can remodel the entire kitchen without the dining room changing.
The Pass: no chef sends out a dish without tasting it
Okay. The business has walked up to the buffet. It's seen the clear labels (Facades). It's built its own plate (Data Mart).
Does it dig in now? Does it publish it on the dashboard for the CEO to see?
No.
In a professional kitchen, before the server carries the dish out to the dining room, it goes through “the Pass.” The chef looks at the plate, checks that the sauce hasn't broken, wipes the rim, tastes it and says: “Service!”
No self-respecting chef sends a dish out of the kitchen without tasting it.
In data, this is Quality Control. But careful: a different kind of quality control from the one we saw in Week 3.
In Week 3, the pantry inspector checked the ingredients on arrival: has the format changed? Are records missing? Is the delivery consistent with previous ones? That was receiving control. It's the equivalent of the head cook checking the supplier's packing slips before putting anything in the fridge.
The Pass is something else. It doesn't look at the ingredients. It looks at the finished dish.
Checking that the chicken arrived in good condition (pantry control) isn't the same as checking that the final dish tastes right (plating control). The chicken can be perfect and the dish can come out too salty. The ingredient passes its check and the result fails its own. Two different moments, two different owners, and two different kinds of rules.
The pantry inspector knows logistics: did everything arrive? Is the format correct? Is the delivery consistent with previous ones? But they don't know what the dish should taste like. Only the Chef knows that.
Does what's coming out of this kitchen make sense? Can a cancelled contract have a balance of half a million euros? Can management fees, which are a monthly running total, go down from one day to the next? Can a percentage be 1,500,000?
IT can't answer these questions. IT doesn't know that management fees are a running total. IT doesn't know that a cancelled contract shouldn't have a balance. IT knows pipelines, Spark, dbt. But it doesn't know what the dish tastes like.
The quality of the dish has to be defined by the Chef.
The Magic Question
On our projects, when we sit down with the business to define the quality of a Data Mart, we don't ask them to write SQL. We don't ask them to learn a tool. We ask them a single question:
What would make you distrust this data?
And the business answers in its own language: * “If I see fees going down within the month, something's wrong. Management fees accumulate: they can only go up.” * “If a cancelled contract has a balance of €500,000, I don't buy it.” * “If a percentage is 1,500,000, that's not a percentage. It's an amount in disguise.” * “If 30% of contracts disappear overnight, that's impossible.”
Each of those sentences is already a quality rule. All it's missing is structure.
We give them a simple form. No jargon. No SQL. Just their knowledge: * Which indicator are you watching? * What should normally happen? * Give me a correct example. * Give me a suspicious example. * How much tolerance do you accept? * Who investigates when it fires?
The business fills out the form in five minutes. The technical team turns that form into an executable test that runs every night before the data is published.
If the dish is “too salty” (if the cancelled contract has a balance), the test fires. The system raises an alert sent straight to the owner of that dish. And the dish doesn't go out to the dining room until the Chef reviews it.
Imagine you had someone who tasted every dish before it went out. Who knew exactly what each one should taste like. Who never got tired, never forgot a rule, and checked every single dish every night without exception. Someone — or something — that guaranteed nothing leaves the kitchen without passing inspection.
And most importantly: we don't ask them to define every rule at once. This is iterative. You start with the indicators that hurt the most. And every time an incident comes in (“why doesn't this number add up?”), it becomes a new rule so it never happens again. Over time, the quality shield grows on its own, fed by real experience.
On day one, the chef has a few basic recipes. But every dish that goes out wrong, every complaint from a diner, becomes a lesson built into the system. “Ever since that day, we always check X before serving.”
Living Documentation: the menu that never lies
And here something happens that isn't obvious but, in the long run, is the most valuable thing of all.
When the business's quality rules become tests that run every night, the documentation comes alive.
In the traditional model, the business writes a PDF that says “Cancelled contracts must have a zero balance.” Six months later, company policy changes and a residual balance of up to €5 is allowed for rounding reasons. The data changes. Nobody updates the PDF. Documentation and reality drift apart forever.
In our model, if the data changes, the test fails. The dish is held.
The Chef (the business) gets the alert, investigates and says: “Oh, right, we changed the policy. Up to €5 is allowed now.” And updates the rule on their form. The technical team updates the test with the new rule, and the dish goes out.
See what just happened? The system forces you to keep the documentation up to date. If the business changes and you don't update the rule, the pipeline complains. The rule (the documentation) and the data (reality) are bound together for good.
No more outdated PDFs. No more “only Bob knows how that works.”
Here's a real (anonymized) example. On one project, the documentation said that every record of a certain transaction type had to satisfy a specific rule on one of its fields. The rule was brought into the system as an automated test. The first day it ran, it found more than 20,000 records that didn't comply.
What had happened? The source system had changed its logic months earlier. Nobody updated the documentation. Nobody knew. The data had been breaking, for months, a rule everyone took for granted.
With a manual test, this would have gone unnoticed indefinitely. With living documentation, it surfaced on day one.
That's the difference between data governance that's a PDF on SharePoint and governance that's executable software. The PDF says how things should be. Living documentation tells you how things ARE, every day, and yells when the two stop matching.
Imagine someone — or something — that stood guard over every business rule. That every night compared what the documentation says with what the data says. And that, if they ever stopped matching, didn't look the other way. Someone who never forgets, never gets tired, and never lets a mismatch slide without reporting it.
Coming full circle: “Those who know can finally do”
We started this series five weeks ago talking about the Centralist Paradox: “Those who know (the business) can't. Those who can (IT) don't know.”
Look where we are now. * The business (the Chef) writes the Recipe in its own language (Week 2). * IT (the Platform) builds the Pantry to store and trace the raw data (Week 3). * The Platform runs the mise en place to prep the ingredients without coupling (Week 4). * The business walks up to the Open Buffet, sees the clear Facades, and builds its own Data Mart (today). * The business defines the quality rules (“what would make me distrust this?”), and the Platform runs them before serving (today).
The bottleneck is gone.
IT no longer hand-cranks SQL translating ambiguous Word docs. IT builds and maintains the best kitchen in the world. And the business, at last, cooks.
The numbers
For those who need to justify this to a steering committee:
Without an Open Buffet (monolithic table, everyone coupled): * Time to add a column to the data product: days to weeks (recalculate the entire table, validate that nothing breaks, coordinate with the 15 teams that depend on it). * Impact of a bug: global (if the table fails, every dashboard in every department fails). * Dependence on IT: total (every change goes through the central team's queue).
With an Open Buffet (independent Data Marts, Facades, business-defined quality): * Time to add a column: hours (it only affects the Data Mart of the team asking for it). * Impact of a bug: contained (it only affects the dish with the problem; the rest keep working). * Dependence on IT: minimal (the business builds its plate, defines its rules, and the system executes).
And the number that matters most: trust. When every piece of data leaving the kitchen has passed a quality check defined by the business itself, the conversation changes. It's no longer “I don't trust the data.” It's “the data passed my own rules.” And if something fails, it's not a mystery: it's a specific alert, sent to the specific person, with the specific context to investigate.
Plating isn't a cosmetic detail. It's the difference between a kitchen that serves and a kitchen nobody trusts.
What's next: from restaurant to franchise
So far we've gone through the kitchen from top to bottom: the Recipe, the Pantry, Mise en Place and Plating. We've seen the what and the why of each layer. If you've followed along this far, you have the complete restaurant in your head: a recipe signed off by the business, a permanent and traceable pantry, a decoupled mise en place and plating with executable quality rules. Three tables full every night, a pizza you can recognize from two blocks away, and a kitchen that runs like clockwork.
But it's still three tables. That's the limit.
No matter how well the restaurant is set up, a three-star restaurant doesn't scale. The same chef still makes the pizza. The recipe lives in her head. She knows the pantry with her eyes closed. If tomorrow management decides to open 38 branches in six countries, none of the four pieces — as they stand — can be replicated directly. They work inside the restaurant. Outside, they don't scale.
Starting next week we enter the next block of the series: how that restaurant becomes a franchise. The same Recipe, the same Pantry, the same Mise en Place, the same Plating — but industrialized, with dependencies inverted, with a head office that distributes what's common and branches that compose what's local. The same things you've seen over these five weeks, but designed so the pizza comes out the same in Zurich, Tokyo or Lagos without the chef from Rome having to travel.
The kitchen is set up. Next week we open the franchise.
But before we open the franchise: