In this chapter
- Bronze ships because one discipline can finish it. Silver needs every discipline at once.
- The involvement grid shows who each layer needs. Its silver column is nearly solid.
- Without an agreed model, silver becomes a rename pass. It holds the same source-shaped tables as bronze with friendlier names, and copying is not integrating.
- Staff the bridges, not the layers. Then record what each one rules.
Every stalled lakehouse program tells the same story in the same order. Bronze, the layer where source data lands as it arrived, ships in weeks, with green ticks on the ingestion dashboard. Silver, the layer meant to integrate those sources into one picture of the business, is scheduled next and never quite arrives. It slips a sprint, then a quarter, then shrinks until what ships under the name isn’t what the diagram promised.
The blame lands on the platform or on the engineers. Both verdicts are wrong. Until you can name what stalls silver, you’ll keep buying bigger platforms to fix a problem that was never technical.
Bronze is the only layer one discipline can finish alone
Count the people it takes to land a source table in bronze. A data engineer builds the ingestion. The source system’s owner explains what the extract emits and which field moves when a row changes. A platform engineer handles storage, identity, and compute. All three sit inside technology, already on your organization chart and bookable this week.
Bronze asks nothing more. There’s no modeling, because the source system already made every structural decision, and no metadata to negotiate beyond what the source publishes. No meeting needs two departments to agree on anything. A team can land two hundred tables without asking anyone what one of them means.
Pure technology work is also exactly what this generation of AI tooling accelerates best. That’s why every tool ships source to bronze first.
Now count the people it takes to publish a governed revenue number in gold, the layer shaped around the metrics your report readers need. A data modeler designs the tables that hold measured events such as order lines (fact tables), decides what one row of each records (its grain), and builds the dimensions every report slices by the same way (conformed dimensions). A steward says which definition is authoritative, and a business owner defines the measure and defends it when departments disagree. An analytics engineer implements it and a semantic model developer exposes it.
Half of that list doesn’t report to you. Most of them are paid for a different day job. That asymmetry, not technical difficulty, decides your running order. Bronze goes first because it’s the only layer one discipline can finish without asking anyone for a calendar slot.
The diagram nobody draws
Every medallion architecture diagram you’ve seen draws technology: three boxes, arrows and a vendor logo. Draw the people each layer needs instead.
Figure 2.1: the involvement grid. Ten roles down the side, three layers across, weighted by how much of each person’s time the layer consumes.Read it by column. Bronze is a narrow band of engineering. Gold is wide but predictable, because everyone already accepts that a published number needs a business owner. The silver column is the one worth staring at, because it’s nearly solid. It’s the only layer where engineering, architecture, modeling, governance, and the business are all core at once.
The silver column predicts your delivery dates.
One staffing error hides at the top of the stack too. Most teams say the reporting team owns gold, because the dashboards read from it. But gold is dimensional modeling: grain, conformed dimensions, a deliberate strategy for history. The reports live above it, on a semantic layer of measures and business-friendly names. Merge the two and you’ve handed the dimensional modeling of your business to whoever built last quarter’s dashboard.
Why does the silver layer stall when the code is easy?
The usual explanation for a thin silver layer is that the transformations are hard. They aren’t. Deduplicating a table, conforming a code list and handling late-arriving records are well understood problems your engineers can solve. Every step the Databricks glossary asks of silver is mechanically easy and organizationally expensive.
What silver needs is a decision. And the people who can make it have the least time. Somebody has to say that billing’s account and support’s login are the same customer. Somebody has to say which system wins when the two disagree, write that ruling down, and hold the line the week two departments count differently.
These are business decisions, not engineering problems. The grid shows who they belong to: the steward who’s half of somebody’s job, the business expert who gives you an hour every two weeks, the modeler shared across three programs.
Three suns and no anchor
In Liu Cixin’s novel The Three-Body Problem, a planet orbits three suns. Three bodies pulling on each other make its sky unpredictable forever. Build bronze, silver, and gold without an agreed model of the business and your lakehouse inherits the same physics.
The project was supposed to start before bronze. Somebody was meant to agree what the business means by customer, order, and account, and write it down before storing anything, as the vocabulary everything else maps to. That written agreement is the conceptual model. It’s the first thing cut, because bronze doesn’t need it.
Silver’s job sounds mechanical (integrate and conform the data) until you ask the only question that matters: conform it to what? With no agreed model there’s no target shape, so each pipeline improvises one. Bronze drags silver toward the source structures, gold drags it toward this quarter’s dashboards, and every engineer’s private guess about what a customer is adds another mass.
The three-body problem’s real lesson is sensitivity. Tiny differences in starting conditions compound until prediction fails. A definition guessed slightly wrong in silver gets joined and aggregated until gold serves two revenue numbers to the same meeting. Nobody can say which is right, because right was never written down.
When the chaos becomes unbearable, data teams do what the novel’s civilizations do and rebuild, with better technology every time and the same missing model. The industry calls that loop replatforming. But it’s the same sky.
Silver quietly becomes a rename pass
From inside, the stall never looks like a stop. The work routes around the missing decisions, because a local answer unblocks the ticket and a meeting doesn’t. The slide still shows a medallion. Underneath, the silver layer holds the same source-shaped tables as bronze with friendlier names, because nobody ruled on which system wins. A patchwork of views glosses over the agreement nobody made. That silver layer is a rename pass.
A rename pass turns your lakehouse into a replication service. You’ve copied your operational systems into better file formats under medallion vocabulary. Copying is not integrating.
The cost lands the first time someone asks a question that spans business units. How many customers do we have, and which of them buy from both product lines? The platform has no answer, because the answer never lived in any system you copied.
None of this is new. Bill Inmon defined a data warehouse in four words: subject-oriented, integrated, time-variant, non-volatile. Three still get built as a matter of course, and integrated is the one the industry quietly let go. Kimball’s conformed dimensions tell the same story from the other direction. Those disciplines didn’t stop being right. They stopped being convenient. The tooling drifted to where everything can be inferred from sources and nothing has to be agreed.
Practitioner essays now call the medallion a communication device rather than an engineering blueprint, and not data modeling at all. Even Databricks’ own summit hosted a session asking what’s wrong with it.
What’s still missing is a method.
Staff the bridges, record the decisions
The reflex fix is a bronze team, a silver team, and a gold team. That rebuilds the silo the medallion was supposed to dissolve, with tickets thrown over two new walls instead of one.
Staff the boundaries instead. Between a source and gold sit four bridges, each carrying a question no engine answers. The people who meet at a bridge to answer its question make up its handshake.
- Source to concept: what does this data mean? The business expert, the modeler and someone who knows the data define the entities and how the business tells one customer from another.
- Concept to bronze: what did we actually land? The source owner and the data engineer agree on schema, keys, how changes arrive, freshness, and what happens when the source changes shape.
- Bronze to silver: integrate to what shape, keyed by what? The engineer, modeler, steward and business expert rule on which records are one customer, which system wins, duplicates and history.
- Silver to gold: served to whom, defined by whom? The modeler, the analytics engineer and the business owner agree on grain, dimensions, measures, and how much history the business needs.
Bronze to silver is the busiest handshake, and the one most programs never schedule.
Silver to gold runs backwards as often as forwards. “I need customer segment as it was on the order date” is a gold requirement only silver can satisfy. With no return path it gets solved inside a report, badly, and again next quarter by somebody else.
Every ruling a handshake makes is a recordable fact, not tribal knowledge. Written down where the work can read them, the rulings from source to concept and from bronze to silver become what silver conforms to. Left in the meeting, they evaporate. The next pipeline guesses again.
You can’t hire the grid, so spend the scarce hours you get on the decisions only those people can make, not on plumbing.
So the silver layer fails for one reason wearing many costumes: decisions nobody was scheduled to make get made anyway, by default, at the keyboard, unrecorded. The fix isn’t a bigger platform or more heroic engineering. It’s agreeing the business language before you store anything, knowing what your sources hold, and recording the mappings between the two.
| The people part | The involvement grid is a meeting schedule, not a hiring plan, so book the steward’s afternoon and the business expert’s hour for the rulings only they can make. |
| Metadata to capture | Record each bridge’s rulings where the work can read them: which records are the same customer and why, which system wins, how duplicates are resolved, and how much history is kept. |
| Regardless of stack | The grid is the same on Databricks, Snowflake and Microsoft Fabric, because no platform choice adds a steward or frees an hour of your business expert’s calendar. |