The data team dropped a result set in the channel. A few hundred sample rows. A link to a materialized view. “Here’s the data.” Now go design the solution.

I can’t. Not from this.

A while back I argued that a lightweight entity model is the minimum any team owes the people who have to build on its data. I called a Data Entity Catalog and a Data Flow Map the minimum viable architecture artifact. I thought I was describing a floor. It turns out the floor is optional. Most handoffs I see land somewhere below it.

Why a result set stalls the room

Here is what actually happens next. The solution team stares at forty columns with names like cust_seg_cd and eff_dt_2, opens a meeting to ask what they mean, and the data engineer explains each one from memory. The meeting ends. A week later someone asks about a column that was never in the sample, and the cycle restarts. Nobody is being lazy. There is simply nothing on the table that a design can be built from.

Design does not start from an answer. It starts from a model of the domain: the things that exist, how they relate, who owns them, and where they are going. A result set is an answer to exactly one question that somebody already asked and already forgot to write down. You can read it. You cannot reason forward from it.

The cost is not the delay, though the delay is real. The cost is that the solution gets designed anyway, on a pile of quiet assumptions. Someone guesses that one customer has one account. Someone guesses that the date column is when the event happened, not when the row was loaded. Those guesses do not announce themselves. They surface later as defects, as reconciliation breaks, as a compliance question nobody can answer in the room. In a bank, that is not an inconvenience. That is an audit finding.

A materialized view hides the model

Start with what a materialized view is for. It is a performance artifact. Someone had a query that was expensive to run, so they precomputed it, denormalized it, and cached the result. That is a good engineering decision. It is also the opposite of a design decision.

To make that view fast, the database flattened everything. Joins are gone, collapsed into one wide table. Foreign keys are gone, resolved into repeated values. Cardinality is gone; you cannot tell from the rows whether a customer can hold many accounts or exactly one. Ownership is gone; nothing tells you which system is the source of truth for a given field and which is just carrying a copy. The materialized view took a model and baked it into a snapshot, and baking is not reversible by looking.

Sample data makes this worse, because it looks like it should be enough. You can infer that a column holds integers. You cannot infer what the integer means, what its valid range is, what happens when it is null, or whether two rows with the same value are the same real thing. Sample data shows you shape. Design needs meaning. The gap between those two is the entire job, and the sample quietly pretends the gap is not there.

The domain language is too narrow to design in

When both sides of a conversation only have column names, the vocabulary runs out fast. You can say “the third column looks like a status.” You cannot say “a Customer can have many Accounts, an Account has exactly one primary owner, and a Household groups Customers for statementing.” The first sentence describes a spreadsheet. The second one is a design you can argue about, test, and build on.

This is the part that frustrates me most, because it is invisible while it is happening. Everyone in the meeting is speaking. It feels like communication. But the language is too thin to carry a solution, so the conversation keeps circling the same shallow questions. What is in column seven. Is column nine ever blank. The room never gets to the questions that matter, because the shared vocabulary tops out at the physical layout of one table.

An entity model widens the language. The moment you can name a Customer, an Account, a Transaction, and the relationships between them, you can have the real conversation. What is a Customer here, exactly, and is it the same Customer the fraud system means? That is the same-person-five-systems problem, and you cannot even ask it if your vocabulary stops at column names.

Data sees the store. Design needs the destination.

There is a deeper split underneath all of this, and it is not about competence. It is about which direction each team faces.

Data engineers are pointed at the source and the store. Their job is to land the data reliably, keep the pipeline healthy, and make the query fast. They are measured on whether the data is there and correct. Nothing in that job description asks them to know where the data is going or what decision it serves. So they hand over what they own, which is the store, and they hand it over in the shape they optimized, which is the view.

Solution design runs the other way. It starts from the destination. Who consumes this, what decision does it drive, what has to be true for that decision to be safe. From the destination you work backward to the model you need, and only then to the data that can fill it. The two teams are walking toward each other from opposite ends of the same road, and the handoff happens in the middle, where one side has a store and the other side needs a destination, and nobody owns the translation between them.

That missing translation layer is the actual defect. It is not a data problem and it is not a design problem. It is an organizational gap that both sides are structurally built to ignore.

How to get the model back

You will rarely be handed the artifact you need. So the work becomes getting it built, or building it yourself and getting it confirmed. A few things that hold up in practice.

Ask for the model, not more rows. When the instinct is to request a bigger sample, resist it. More rows give you more shape and no more meaning. Ask instead for the entities and their relationships. If the data team does not have that written down, then you have found the real starting point, and it is worth naming out loud.

Reverse-engineer the view into entities, then confirm. You can often reconstruct a rough model from a materialized view if you treat it as a puzzle. Which columns repeat together, which one looks like a key, where the grain of the table actually sits. Draw that as an entity model and hand it back with one sentence: “This is what I think your data means, correct me.” A wrong diagram gets corrected fast. A blank page gets ignored.

Treat the entity catalog as the floor. This is the piece I described in Architecture Without Architects, and I stand by it as the minimum. For each entity: what it is, who is the system of record, how it is classified, how long it is retained, which regulations touch it. That is not a heavy document. It is a page. It is the difference between a design conversation and a guessing game.

Force the destination question early. Before anyone models anything, get the consumer on the record. Who reads this, what do they do with it, what breaks if it is wrong. The destination constrains the model more than the source does, and it is the one thing the data handoff almost never includes.

Build a shared glossary and defend it. When cust_seg_cd gets a plain-language definition that both teams agree on, the vocabulary widens by one word. Do that thirty times and the narrow domain language stops being the bottleneck. This is unglamorous and it is most of the win.

The honest part

Data teams are not wrong to think in data. They are built to. The materialized view is a genuinely good artifact for what it was made to do, which is to serve a query quickly. Blaming an engineer for handing over a view is like blaming a warehouse for not being a blueprint. The view was never supposed to carry the design.

And sometimes the destination honestly is not known yet. The data exists, someone senses there is value in it, and the solution is a fishing expedition dressed up as a project. That is a real situation, and it is a worse problem than a missing ERD, because no diagram fixes a missing purpose. When that is the case, the useful move is to say so plainly rather than to model your way around a hole where the intent should be.

The gap is organizational, not personal. Somewhere between the team that owns the store and the team that owns the destination, an entity model should be changing hands, and usually no role is accountable for producing it. Naming that absence is more useful than resenting it.

Why this gets more expensive from here

The handoff is about to get a new consumer, and it is less forgiving than any solution team. Agents and language models are being pointed at enterprise data at speed, and a schema without semantics fails them the same way it fails a human designer, only faster and more confidently. Give a model forty cryptic columns and it will produce a fluent, wrong answer and hand it to you with total composure. The entity model, the ownership, the plain-language meaning of each field: that is exactly the context an agent needs to be trusted with a decision. It is becoming the shared language for people and machines at the same time.

So the ERD stops being a courtesy the data team extends when it has time. It becomes the interface. It is the floor, the thing below which no useful conversation happens, and the thing every consumer downstream now depends on. Insisting on it is not process for its own sake. It is the cheapest defect prevention available, paid once, before the guessing starts.

If you liked this, the companion piece is Architecture Without Architects, on the handful of artifacts that get a regulated organization most of its alignment without a large EA team.

I write about enterprise architecture, AI-assisted development, and building in regulated environments. If this resonated, find me on X @orestesgarcia or LinkedIn /in/setsero. I’d like to hear how the handoff looks on your side.