In this chapter
- Six steps in dependency order, scoped to one subject area.
- What each step produces, and who has to be in the room.
- The test that says a step is finished, and the anti-pattern that kills it.
- Why the sixth step feeds the first instead of ending the work.
Nine chapters of argument come down to something you can start on Monday, with the people you have and the platform you already bought. This is not a program and not a migration. It is one subject area and six steps, each one producing what the next consumes, with an integration layer standing at the end of them.
Scope is the first decision you make, and it is the one teams most often get wrong. Pick a single subject area, Customer or Order or Product, and walk it the whole way through. One governed subject in six weeks teaches you more than a charter in six months, and it leaves something running when you are done.
Read the sequence as dependencies rather than calendar slots. Steps 1 and 2 run in parallel: your modelers can agree on what a customer is while your engineers import the source metadata, and neither side waits on the other. Step 3 is the first step that needs both.
Figure 10.1: read the sequence as dependencies, not calendar slots. This
pass’s decisions are the next pass’s context.Step 1: Agree the language, and only for this subject
Start by writing down the entities and their definitions in business terms, the synonyms the business already uses, the relationships as sentences, and a business key for each entity, or an explicit note that nobody can name one. Book the meeting before you open the tool, because the meeting is the model. Then add chapter 3’s naming rules as ordered steps somebody can execute, not as a style preference nobody enforces.
Keep the room small: a modeler running the method, a steward who owns the standard, and the business expert who owns the meaning.
Chapter 3’s demo meeting shows why that hour is not optional. Two lines connect Customer and Club Partner on the source diagram, and they are not one relationship drawn twice. One says which club a customer registered with; the other says which customer is that club’s contact person. The glossary now carries them as separate entries.
You are done when each relationship reads aloud as a sentence the business would say, and the business expert agrees it is true. The way this fails is the enterprise-wide glossary program: a year of workshops, a taxonomy nobody consumes, and no subject area finished.
Step 2: Capture the sources, then profile them
Two artifacts come out of this step, and they are not the same thing. The register holds one entry per source along with its capability profile: what it can be asked, how it exposes changes, what it refuses. The inventory holds the tables and columns, imported on stable identifiers so a rename does not orphan everything downstream, and reviewed as a diff that somebody approves.
Once both exist, profile the data, because the schema is a claim and the data is the witness. Capture nullability, distinct counts, real formats, and candidate keys, keeping the observations apart from the rulings: unique in today’s extract makes a column a candidate key, not a key.
The engineer runs this work, but book the source system owner’s hours now rather than on the day their absence blocks a mapping.
You are done when you can answer “what can this source not tell us” for every source in the register. The way this fails is trusting the schema as the truth about the business. The demo source declares both club relationships as foreign keys, and that constraint metadata cannot say which one is membership and which one is the contact person. Only step 1 can.
Step 3: Map one subject end to end
This is chapter 2’s bronze-to-silver handshake, finally on somebody’s calendar. The work is to bind the physical estate to the agreed language, source table to entity and source column to attribute, with every decision carrying its decider, its date, and its reason.
Treat disagreement as an outcome in its own right. A proposal you reject with a recorded reason is worth nearly as much as one you accept, because it stops the same wrong suggestion coming back next quarter. For the same reason, publish the mapping as the deliverable rather than as working notes: your build, your testing, and your next auditor all run on it.
All four disciplines sit in this room. The engineer knows what the columns hold, the modeler holds the target language, the steward owns the standard, and the business expert settles the meaning.
You are done when a governed attribute traces back to every column that populates it, across every system that feeds it. The way this fails is a mapping spreadsheet with a deadline and no owner, finished once and stale by the following sprint.
Step 4: Choose the shape, in writing
Weigh chapter 6’s factors against your own situation: how often your sources change shape, what your auditors actually ask for, what your team can already run at three in the morning, and what each shape costs to query on the platform you own. Once you have an answer, write the decision down along with those factors, the date, and the names of the deciders.
Underneath that decision sit the rulings that make it work: which business keys the estate counts by, which system wins when two disagree, how much history the business owes, and where each split boundary falls and why. The architect proposes those rulings, but the stewards and the business rule on the keys.
You are done when the rationale exists where the next engineer will find it, in the catalog rather than in a slide deck in somebody’s downloads folder. The way this fails is choosing by religion, or by the last conference somebody attended, and then defending that choice for three years because nobody ever wrote down what it was for.
Step 5: Stand up the templates and their contract
This is where the machine starts earning its keep. You need a pattern for each kind of object, and you need your conventions declared as metadata rather than buried in code: naming rules, system columns and the role each one plays, hash definitions, and data-type mappings. On top of that, you need bindings that say which pattern serves which object, along with the declared context a render depends on.
Prove it against real metadata before you trust it. On the demo dataset, a single source table of 5 columns generates a landing table of 7, a staging table of 8, and a persistent staging table of 11. Nobody typed the extra columns or chose their names. The load timestamp, the record source, the hash difference, the effective-date pair, and the current-row flag all come from the declared conventions, which is why they arrive identically named on every table those conventions touch.
Name the template author while you are at it. In most teams nobody holds that role, so the patterns end up being whatever the last contractor left behind.
You are done when you change one naming pattern and every generated name moves with it. The way this fails is hand-editing generated output, which quietly turns a generated object back into a maintained one and tells nobody downstream.
Step 6: Generate, validate, govern, and commit
Build the layer as a reviewable artifact set with a pass or fail on every file, not as a script that writes straight into a schema. Point chapter 9’s validation rules at it, tuned so every finding is actionable. Then put the whole model on branches, with diffs a reviewer can read, a commit gated by the rules, and a history that survives a delete.
Only one person needs the reviewer role, and that person is named. Everyone else keeps their day job, which is the point: the machine does the repetitive work, and the team keeps meaning, standards, and approval.
Watch what survives generation. In the demo dataset, the foreign key naming the club’s contact person is still there in persistent staging, re-pointed at the persistent staging copy of the customer table. What the business explained in step 1 is still a relationship four layers down, because somebody recorded it rather than leaving it to be re-derived.
You are done when you can answer “who accepted this, and when” for any object in the layer. The way this fails is a catalog nobody can diff.
The people part. The chapter is the staffing plan, so treat this box as the calendar. Four meetings carry the six steps. The language meeting is a weekly hour or two for the modeler, the steward, and the business expert, running until the subject area is agreed. The source interview puts the engineer and the source system owner together, one table at a time, booked the week the source enters the register. The mapping review gathers all four disciplines in a standing slot, until the subject is bound. The shape decision is one meeting the architect prepares and the stewards rule in. Steps 5 and 6 add no meeting at all: they need a named template author and a named reviewer, whose work shows up in pull requests anyone can read.
Metadata to capture. Every box in this book collapses into one scorecard, and you can score a subject area against it in an afternoon. Start with entities, definitions, synonyms, relationships, business keys, and executable naming rules. Add the source register with capability notes, the inventory on stable identifiers, the approved import diffs, the observed profiles, and the candidate keys held apart from rulings. Record mappings with deciders, dates, and reasons, the rejections included, and the shape decision with its rulings underneath. Declare conventions as metadata: naming patterns, system columns, hashes, type mappings, bindings. Carry provenance at column grain, written at derivation, and classification and ownership on the attributes. Close with governance requirements and the actions they gate, the rule catalog, and the audit trail. Anything there you cannot point at is the next thing to capture.
Why is the second subject area faster than the first?
The six steps are a loop, not a waterfall. Step 6 does not end the work, it feeds step 1, because the decisions you recorded on this pass become the context the next pass reads. A mapping you accepted turns into the standard the next proposal is measured against, and a naming rule you settled generates the next hundred names without anyone reopening the discussion. Your decisions do not exit the process once you have made them: they become it.
That is why the second subject area moves faster than the first and the tenth is routine, and why none of it needs a platform migration or a new budget line to start.
Regardless of stack. Read back through the six steps and count the platform decisions: there is one, in step 4, and even there only the economics of the factor table moved. Every platform will tell you to land your data and let its AI do the rest, but the rest assumes a language somebody agreed, sources somebody profiled, a mapping somebody signed, a shape somebody chose, conventions somebody declared, and a history somebody can read. No vendor supplies those, and none forbid you from building them: AI proposes, a person decides, and every step runs on governed context you control.