The tooling landscape

Layer 1, drawing and versioning the model. The category covers everything from free browser-based diagram tools to commercial data modelers to the diagram-as-text formats that live in a code repository. They are cheap, and the choice barely matters. What matters is one property, and it is the property most teams do not check: can the diagram be regenerated from the actual database rather than maintained by hand?

A hand-maintained diagram is accurate on the day it is drawn and decorative thereafter. It does not fail loudly. It quietly stops matching reality, one shipped change at a time, and the first person to trust it is misled precisely because it looks authoritative. That is the honest observation to hold on to: a diagram nobody regenerates is a lie within a quarter, and a lie you have paid for and printed. So the question to ask about any candidate is not what it can draw, but what it does on the Tuesday after somebody adds a column.

Layer 2, transformation and testing. This is the layer worth real attention, because it is the only one that can make a bad change fail rather than merely be visible. The convention it carries is more valuable than any product in it. The widely used shape, popularised by dbt and now the default across the industry, is three layers of models held as version-controlled code:

• Staging. One model per source table, doing nothing but renaming, casting and cleaning. Boring on purpose, and the boredom is the feature: it means source changes are absorbed in exactly one place.
• Intermediate. The joins and reshaping nobody wants to write twice. This is where grain changes happen, deliberately and once, instead of being re-derived in every report.
• Marts. The tables consumers actually query, each with a declared grain. Bazaar's marts are one row per merchant per day, one row per date and hour, one row per day: three grains, three questions, no ambiguity.

On top of that sits the piece worth the most to you as an approver: the model contract. A contract declares what a model promises - which columns exist, of what type, at what grain, never null - and turns a breach into a build failure rather than a conversation. That is the difference between documentation and governance. Documentation can be wrong without anything happening. A contract cannot.

Layer 3, the catalog or metadata layer. The problem is genuinely real: in most organisations the owner, grain and freshness of a table are tribal knowledge, which means every question routes through the same two long-serving people, and their departure is a business risk you have not written down. The category runs from open-source metadata platforms to the catalog features now bundled into warehouse and BI products. Again the product choice matters less than one property: how much of the catalog populates itself?

Lineage, schemas, freshness timestamps and query popularity can be harvested automatically. Ownership, grain sentences and business meaning cannot. So a catalog is a machine for making the automatic part free and the manual part visible, and its failure mode is entirely about the manual part. An empty catalog is worse than no catalog: it trains the whole team that looking things up there is a waste of a click, and that lesson takes years to unlearn. Fund a catalog with a named backfill for a defined slice, or do not fund it yet.

Layer 4, the semantic layer. One metric, one expression, one grain, one caveat, read by every consumer. Session a3 argued why this must live as data rather than as a wiki page; this is the purchase decision that follows. The category includes standalone semantic or metrics layers, the semantic modelling built into some BI platforms, and the increasingly common pattern of holding definitions as a governed table in the warehouse itself, which costs nothing in licence and quite a lot in discipline.

The evidence that it pays is unusually crisp on this course's own data. Bazaar's semantic layer is 13 metric definitions, each with an expression, a grain and a caveat. Given the same tables and the same questions, an AI analyst scored 0 of 20 standard business questions without those definitions and 20 of 20 with them. Nothing about the data changed. That is the honest business case for layer 4, and it is a stronger one than any demo, because it is a measurement rather than a promise.

The trap is sequencing. A semantic layer is a place to put agreements. If you have no agreements, it becomes a place where disagreements look official, and the fact that they are now centralised makes them harder to notice rather than easier. What to fund specifically so that natural-language querying works is session a6, and it is worth taking before signing anything in this layer.

Two adjacent categories will be pitched to you in the same conversations, and it is worth knowing why they are not on this list.

• Data quality and observability tools. These monitor for anomalies, volume drops and freshness misses. Valuable, and genuinely different from layer 2: a testing layer asserts what must be true and fails the build, while an observability tool watches what usually happens and alerts on surprise. Buy the first one first. Alerts on a model with no contracts produce a stream of notifications that nobody can act on, and the team learns to close them.
• Orchestration and pipeline tooling. Scheduling, dependencies, retries, backfills. This is the operational layer beneath everything here, and it is a different course entirely. Modeling decisions do not depend on it, and it will not fix a single problem on this page.

Both are frequently sold as solutions to modeling problems. Neither is. The test is the same one you apply everywhere else: name the human failure it enforces against. Observability enforces against nobody noticing. Orchestration enforces against things not running. Neither enforces against a metric meaning two things, which is the problem you actually have.

Ask for these to be written down and owned before you approve anything. They are not risks. They are the actual scope of work, and the licence is a rounding error against them.

• Layer 1, ERD tooling. Adoption cost is a regeneration habit. Somebody must make the diagram an output of the database rather than a drawing, and design reviews must start from the regenerated version. If your candidate cannot regenerate, the adoption cost is a permanent manual chore, which is another way of saying the artifact will be false by the next quarter.
• Layer 2, transformation and testing. The highest adoption cost of the four, and the one most worth paying. Everyone who edits transformation logic has to move into version control, accept a review step, agree on the staging and intermediate and marts convention, and write tests for models they already trusted. Weeks of friction, and after it a broken change fails in the build instead of in a stakeholder meeting.
• Layer 3, catalog. The bill is the backfill, and it is always underestimated because the harvestable parts arrive instantly and look like progress. Owner and grain and business meaning for every table that already exists is human work, and it must be scoped as a named piece of work for a defined slice, not as a hope.
• Layer 4, semantic layer. The bill is a series of arguments, held once and in public. Every contested metric has to be settled before it can be encoded, and a few of those settlements will disappoint someone senior. Bazaar's 13 definitions look tidy on the page; the work in them is not the syntax, it is deciding that revenue means one thing.

Any artifact that requires a human to remember something in order to stay true will stop being true, and the timescale is a quarter rather than a year. This is not a comment on anyone's diligence. It is arithmetic: updating is unrewarded, invisible when done and invisible when skipped, and it competes with work that has a deadline.

So when a proposal contains the phrase "and the team will keep it up to date", treat it as a defect in the proposal rather than a commitment. There are only three acceptable answers. The artifact is generated automatically, so staleness is impossible. Or a specific person owns it as a named responsibility with a review cadence you can point at. Or you accept that it will be stale and stop calling it a source of truth. All three are legitimate. The fourth option, which is hoping, is the one that has already failed in your organisation at least once.

• Standardise conventions before buying tools. Naming, grain sentences, the staging and intermediate and marts layering, who may change a table: all free, all portable, all survive every migration you will ever do. A tool bought before the convention exists gets used four different ways by four different people, which is exactly the situation you were trying to fix, now with an invoice. Say it as: "what would we standardise on if we had no budget at all? Let us do that first, and then see what is left."
• Buy where the tool enforces something a human keeps forgetting. This is the whole positive case. Tests and contracts enforce that a promise is kept. A semantic layer enforces that one word means one thing. Regenerated diagrams enforce that the picture matches the database. A tool that only makes good behaviour possible is competing with a busy quarter, and the busy quarter wins. Say it as: "what does this make impossible that is currently merely discouraged?"
• Skip anything whose value depends on people updating it manually. Not because documentation is bad, but because an unmaintained artifact presented as authoritative is worse than an absence. Either the update is automatic, or it is a named person's job with a cadence, or you stop calling it a source of truth. Say it as: "who fills this in, in which week, and what happens if they do not?"

Notice that all three rules are questions rather than positions. That is deliberate: they let you decline a request without contradicting the person's technical judgement, which is usually correct about the tool and usually wrong about the sequence.

Building your own is a real option in two of the four layers and a bad idea in the other two. One question per layer settles it:

• Layer 1, ERD. "Can we generate this from the database we already have, and is that good enough for a design review?" Very often yes, using nothing but a script and an existing diagram format. Genuinely build, and expect it to cost a couple of days.
• Layer 2, transformation and testing. "Are we prepared to maintain a dependency graph, a test runner and a contract checker as internal products, forever?" Almost always no. This category is mature and the conventions are industry-standard. Adopt, do not build. Every homegrown version of this becomes one person's unmaintained framework.
• Layer 3, catalog. "Do we need search across many teams, or do we need one honest table of owners and grains?" If the honest answer is the second, a governed table plus a scheduled harvest of schemas and freshness gets you most of the value at close to zero licence. Buy when the number of teams, not the number of tables, is the problem.
• Layer 4, semantic layer. "Do our consumers read definitions from one place, or does each tool hold its own?" You can absolutely start by building: a governed table of definitions in the warehouse, with expression, grain, owner and caveat. That is exactly what this course ships as 13 definitions, and it was enough to take an AI analyst from 0 of 20 to 20 of 20. Buy when you need enforcement at query time rather than agreement at design time.

The pattern across all four: build where the artifact is small and the value is agreement, buy where the value is enforcement at runtime and the maintenance never ends.

Hold this list up in a budget review. Every line is a legitimate reason to defer, and deferring is not the same as neglecting.

• ERD tooling - if one person can draw the whole model on a whiteboard from memory and two others would agree with it. Buy nothing; take a photo and put it in the repository.
• Transformation and testing - if exactly one person writes all the transformation logic and there are no downstream consumers outside their team. This is the shortest deferral on the list, because it expires the moment a second person joins.
• Catalog - if a single spreadsheet of tables, owners and grain sentences would fit on one screen and stay current. Write that spreadsheet. It is the same value at zero cost, and it also tells you when you have outgrown it.
• Semantic layer - if you have fewer than roughly a dozen metrics that matter and nobody is currently disagreeing about any of them. Write the definitions as a governed table first. If they hold for two quarters, you have your answer about whether you needed a product.
• Any of the four - if the grain and caveat workshop from session a3 scored badly. That score is a diagnosis of missing agreement, and no product in this market sells agreement.

The prompt, read aloud: "Four layers on the board. For each one, tell me what we own, and tell me what it makes impossible. Not what it helps with. What it makes impossible. Then for every empty layer, tell me the thing we have actually observed that says we need it."

What a good answer sounds like: "Layer 2 we own: transformation logic is in version control with tests, and a change that breaks a declared column fails the build, so that is genuine enforcement. Layer 1 we have diagrams, but they are drawn by hand and last updated in February, so I would put that in the paid-for-not-adopted column. Layer 3 is empty, and the signal is real: the same three people get asked who owns a table roughly weekly. Layer 4 is empty and I do not think we have the signal yet, because nothing is currently disagreeing."

The failure modes to listen for:

• Product names instead of enforcement. "We have the enterprise catalog." That answers a procurement question, not this one. Ask again: what does it make impossible? Silence there is the finding.
• A benefit standing in for a signal. "It would give us better visibility." A benefit is what a vendor says. A signal is something that has already happened, that you can date. Keep asking until you get an event.
• Wanting layer 4 first. Extremely common, because it is the layer with the best demo and the clearest link to AI ambitions. The gentle version of the pushback: "if we encoded our metric definitions tomorrow, would the room agree with them?" If not, you are about to make a disagreement official.
• Picking three layers for one quarter. Each has a behavioural adoption cost, and three simultaneous behaviour changes is three abandoned initiatives. Insist on one, and name the person.
• "We have all four already." Then the honest follow-up is why the last metric argument happened, and which layer failed to prevent it. There is always a recent one.

The prompt: "Four questions before we talk about the product. Which of the four layers is this? What does it make impossible? Which convention does it assume we have already agreed? And who fills in the manual fields, in which week?"

What a good answer sounds like: "It is layer 2. It makes it impossible to ship a change that drops a column another team has declared a dependency on, because the build fails. It assumes we have agreed a layering convention, which we have not, so I would want two weeks on that first. There are no manual fields; the contracts are declared alongside the code that people already have to touch." That is a strong answer, and note that it includes a delay the requester volunteered.

The failure modes to listen for:

• An answer about the roadmap. "The next release will add contracts." You are being asked to buy an intention. Decide on what exists today.
• A demo answer. "Let me show you." The demo will be good; that is its purpose. It will not answer question three, which is the one that decides.
• No manual fields claimed at all. Nearly always untrue in layers 3 and 4. Ownership, grain sentences and caveats cannot be harvested from anything. If the answer is "it is all automatic", the person has not used it with real data yet.
• Urgency attached to an AI initiative. "We need this before we can launch the AI analyst." Sometimes true and worth acting on, and session a6 is where that case gets made properly. But the accuracy came from 13 definitions with grain and caveat, not from a purchase order, and it is worth knowing which one you are being sold.

Most tooling requests you decline will be technically correct. The person is right that the tool solves a real problem; they are wrong about the sequence, and telling them they are wrong about the tool will cost you the next honest recommendation they might have made.

So decline on the gate, not on the merit. "This is a good fit for layer 4 and I want it. Gate 1 says we have not agreed what revenue means, so a semantic layer would encode the argument rather than settle it. Settle the metric definitions this quarter and bring the same request back with them attached, and I will approve it." That is a yes with a sequence, it names what has to be true, and it is a genuinely stronger position than either approving or refusing.

It also has a side effect worth having: the next request arrives already mapped onto the four layers, with the convention question answered. Once that happens, this session has done its job and you can stop running the script.