Data platform techniques: an architecture fit assessment

1. Executive summary

Practices are not products, and assessing them with a product rubric is how organisations end up adopting a pattern that was never going to survive contact with their staffing. So the axes here ask different questions: how much ongoing discipline does this demand, can you back out of it, and — the one nobody asks — what does it look like when it is done badly? Because most of these will be done badly. That is not cynicism; it is the base rate.

The short version. Analytics engineering is the only unambiguous Adopt: it scores well on every axis, it is genuinely mature, and it fails gracefully. The metrics layer is an Adopt where the pain is real; data contracts I keep at Trial, because the discipline they demand is organisational rather than technical, and that is the kind most teams discover they do not have. Lakehouse-native serving is the most durable idea here and the least reversible, which makes it an Assess rather than an Adopt. And medallion architecture is the interesting one.

Data mesh is the one I score hardest, and I want to be fair about why. Its diagnosis is correct: a central data team really does become a bottleneck, and the people who understand the data really are in the domains. But the prescription is a reorganisation wearing an architecture diagram. It scores 1.8 on time to value and 1.6 on discipline — the two lowest numbers here — because you cannot ship it; you can only slowly become the kind of company it assumes you already are. Hold for most organisations, and take the good ideas (domain ownership, data as a product, a self-serve platform) without the reorg. Those ideas survive perfectly well on their own.

Medallion scores 2.6 on graceful failure, and data mesh 2.2 — the two worst numbers on this page. I want to be precise about medallion, because the pattern is not bad. It is over-applied. Bronze/Silver/Gold is producer-centric: it describes stages of pipeline refinement, not the consumer's business model. Applied thoughtfully it is a useful convention. Applied by default, because Databricks and Fabric both recommend it in their getting-started docs, it produces three layers of ceremony around data that needed one — and when the discipline lapses, the layers collapse into a single unmanaged zone with three times the storage bill and a lineage diagram nobody trusts. I have cleaned up that project more than once.

2. Positioning

These five are not independent, and pretending otherwise is how they get adopted in the wrong order. Analytics engineering is the substrate — the others assume you already version, test, and review your transformations, and adopting any of them without that is building on sand. Medallion is a layout convention for the tables analytics engineering produces. The metrics layer sits downstream of those tables and defines what the numbers mean. Data contracts point upstream, at the producers who keep breaking you. Lakehouse-native serving is about where the tables physically live and who can read them.

The column that should decide your adoption order is the last one, and it is the one nobody puts on a slide.

Data mesh sits slightly apart from the other five, and it is worth being explicit about how. Analytics engineering, medallion, metrics, contracts, and lakehouse serving are things a platform team can adopt on a Tuesday. Data mesh is not — it is a claim about who should own data, and you cannot adopt it unilaterally any more than you can unilaterally adopt a new org chart. That is why it is on this page at all: teams keep treating it as an architecture they can build, and it is not one. My longer argument is in Data Mesh: what actually works and what doesn't.

3. Radar criteria — the reasoning

Problem fit

Analytics engineering 4.7 — untested, unreviewed SQL is a real and universal problem. Data contracts 4.5 and the metrics layer 4.4: both target pain that is specific, expensive, and immediately recognisable to anyone who has lived it. Lakehouse-native serving 4.2. Medallion 3.6 — it solves a real problem (the swamp), but it is frequently adopted where that problem does not exist yet. Data mesh 3.4: the bottleneck it names is real and painful; the reason it doesn't score higher is that most teams reaching for it have a 6-person data team and a coordination problem, not the 200-person scale where the diagnosis actually bites.

Evidence & maturity

Analytics engineering 4.8 — a decade of practice and overwhelming evidence. Medallion 4.4: enormously deployed, and recommended as the default lakehouse layout by Databricks, Microsoft Fabric, and Azure alike, which is both the evidence and part of the problem. Metrics layer 3.8, data contracts 3.6, lakehouse-native serving 3.6 — all three have good case studies and no settled consensus. Data mesh 3.4: seven years of discourse, a canonical book, and a startlingly thin public record of organisations that finished one and would do it again. The successful cases I can point to were already federated before they had the vocabulary.

Time to value

Medallion 4.4 and analytics engineering 4.2 pay back fast — weeks. Lakehouse-native serving 3.0. Metrics layer 2.8: the work is mostly organisational agreement about what a number means, which is slower than any implementation. Data contracts 2.4, because you are not shipping software, you are changing how another team behaves. And data mesh 1.8, the lowest on the page: the unit of delivery is a reorganisation, measured in years, and there is no version of it that produces value next quarter.

Low discipline required (inverted — higher means it demands less)

The axis that predicts failure better than any other. Analytics engineering 3.4: CI enforces most of it for you, which is why it survives staff turnover. Lakehouse-native serving 3.2. Metrics layer 3.0. Medallion 2.8 — nothing enforces the layer boundaries except a convention and someone's vigilance in code review. Data contracts 2.2: a contract is only as real as your willingness to break a producer's build over it, and most organisations discover they are not willing. Data mesh 1.6 is the lowest score anywhere on this page — it requires every domain to sustain engineering standards indefinitely, with no central enforcement by design. The discipline isn't in a CI pipeline you control; it's in other people's headcount plans.

Reversibility

Analytics engineering 3.8, medallion 3.4, metrics layer 3.6, data contracts 3.0. Lakehouse-native serving 2.6 — once you have deleted the copies and rebuilt serving around reading the lake in place, going back means rebuilding the copies and the pipelines that maintained them. Data mesh 2.2: you can revert an architecture; reverting a reorganisation costs people, and the ones who left because you moved them into a domain team do not come back.

Tooling support

Analytics engineering 4.8 — dbt and SQLMesh are mature and everywhere. Medallion 4.6: every lakehouse vendor ships a quickstart for it, which is exactly why it gets adopted without a decision. Lakehouse-native serving 3.8, metrics layer 3.6 (still fragmented, and BI-tool support remains the constraint), data contracts 3.2 — the tooling is improving and this is still mostly process. Data mesh 3.0: the self-serve platform layer it depends on is buildable today, which is the good news and also the trap, because the platform was never the hard part.

Governance impact

Data contracts 4.7 — the highest here, and deservedly: an enforced contract is the only one of these five that prevents a class of incident rather than detecting it. Metrics layer 4.5: one definition of revenue is a governance artifact as much as a technical one. Data mesh 4.0 — federated computational governance is a genuinely good idea, and the part of the proposal I would steal outright. Analytics engineering 4.3, lakehouse-native serving 3.8, medallion 3.4 — layer names are not governance, though they are frequently sold as such.

Scale behaviour

Data contracts 4.5 and the metrics layer 4.2 both get more valuable as the organisation grows — the problems they solve are superlinear in team count. Analytics engineering 4.4, lakehouse-native serving 4.4. Data mesh 4.6 is the highest here and it is the honest half of the argument: it is the only practice on this page designed for the failure mode of a 200-person data organisation, and above a certain size the centralised alternative genuinely does stop working. Medallion 3.8: it scales, and each additional layer multiplies pipeline surface area, so the cost scales too.

Graceful failure (inverted — higher means it degrades more gently)

The most useful axis on this page, because everything here will be under-maintained at some point. Data contracts 4.2: an unenforced contract is useless but harmless — you are back where you started. Analytics engineering 4.0, metrics layer 3.8, lakehouse-native serving 3.4. Medallion 2.6: when the discipline lapses the layers collapse into a single unmanaged zone, and now you are paying triple the storage and running triple the pipeline steps for a swamp with better branding. Worse than never having started. And data mesh 2.2, the worst on the board: a half-adopted mesh gives you N inconsistent domain stacks, no central team with the authority to fix them, and the original bottleneck — now with a coordination tax on top. The failure is not a system you can roll back; it is an org you have to re-merge.

Durability

Lakehouse-native serving 4.7 — this is where the entire industry is going and I would design new pipelines around it. Analytics engineering 4.6, data contracts 4.5, metrics layer 4.4 — all four are durable ideas. Data mesh 3.6: the vocabulary — data products, domain ownership, self-serve platform — has outlasted the movement and is now just how people talk, which is a real legacy even where the reorg never happened. Medallion 3.4: the strongest objection to it is not that it is wrong but that it is producer-centric, describing pipeline refinement stages rather than the consumer's business model, and the data-products argument that organises around meaning rather than engineering convenience is gaining ground for good reasons.

4. Radar scorecard

How these scores are arrived at — the rings, the 0–5 scale, and the evidence rules — is written up in the radar methodology. This table and the chart below are generated from one file, scorecards.json: the source of truth, machine-readable, and kept separate so two copies of the same numbers cannot drift apart between editions. Last reviewed 2026-Q3.

Comparator scores (same axis order) — Medallion architecture: 3.6 / 4.4 / 4.4 / 2.8 / 3.4 / 4.6 / 3.4 / 3.8 / 2.6 / 3.4. Metrics layer / headless BI: 4.4 / 3.8 / 2.8 / 3 / 3.6 / 3.6 / 4.5 / 4.2 / 3.8 / 4.4. Data contracts: 4.5 / 3.6 / 2.4 / 2.2 / 3 / 3.2 / 4.7 / 4.5 / 4.2 / 4.5. Lakehouse-native serving: 4.2 / 3.6 / 3 / 3.2 / 2.6 / 3.8 / 3.8 / 4.4 / 3.4 / 4.7. Data mesh: 3.4 / 3.4 / 1.8 / 1.6 / 2.2 / 3 / 4 / 4.6 / 2.2 / 3.6.

5. The radar

Ten technique axes. Two are inverted so higher is always better: Low Discipline and Graceful Failure. Read the dents rather than the totals — analytics engineering is the roundest shape here; data contracts collapse on discipline and time-to-value while topping governance; and data mesh is the starkest shape of all, peaking at Scale (4.6) and bottoming out at Low Discipline (1.6) and Time to Value (1.8). That silhouette is the whole argument. Click any name in the legend to toggle it on or off — comparing two shapes at a time is far more legible than comparing four.

6. Workload-specific analysis

7. Reference architecture

These five compose, and the order matters. Analytics engineering underneath; layers as a convention on top of it; contracts pointing upstream at the producers; metrics downstream at the consumers; and the lake underneath everything so the engine stays replaceable.

graph LR
  PROD["Upstream producers"] -->|"schema + SLA"| DC["Data contract
enforced in producer CI"]
  DC --> ING["Ingest"]
  ING --> B[("Bronze
raw, immutable")]
  B --> S[("Silver
conformed, tested")]
  S --> G[("Gold
business marts")]
  AE["Analytics engineering
dbt: version, test, review"] -.->|"builds"| S
  AE -.->|"builds"| G
  G --> ML["Metrics layer
one definition"]
  ML --> BI["BI"]
  ML --> APP["Apps / AI"]
  LAKE[("Open table format
Iceberg / Delta")] -.->|"stores all three"| B
  LAKE -.->|"read in place"| ENG["Any engine"]
  DC -.->|"breaks their build"| PROD

What a data contract looks like when it is real rather than decorative — note that the only line that matters is the last one:

# A contract is an organisational instrument wearing a YAML costume.
# Everything above `enforcement` is documentation; `enforcement` is the contract.
name: orders
owner: platform-checkout          # a team, not a person who left
version: 2.1.0

schema:
  - name: order_id
    type: string
    nullable: false
    unique: true
  - name: revenue_cents
    type: integer                 # not float. ask me how I know.
    nullable: false
  - name: updated_at
    type: timestamp
    nullable: false

sla:
  freshness: 15m
  completeness: 0.999

# Breaking changes require a major bump and a deprecation window.
compatibility: backward

enforcement:
  # This is the whole practice. Without it the file above is a wiki page.
  ci_gate: true                   # producer's PR fails on violation
  on_violation: block_merge
  # Consumers get told before it lands, not after their dashboard is wrong.
  notify: [data-platform, analytics-eng]

8. POC plan (4 weeks)

Practices don't POC the way products do — you cannot trial a discipline in a sandbox, because the thing you are testing is whether your organisation will sustain it. So the four weeks look different:

• Week 1 — name the pain, or stop. For each practice, write the incident it would have prevented, with a date and a cost. If you cannot name one, you are adopting it because a conference talk was persuasive. That is the most common failure mode here and the cheapest one to avoid.
• Week 2 — find the owner. Every practice on this page needs a name attached: who defines a metric, who arbitrates a contract breach, who says a table belongs in Silver. No owner, no practice — you will get the cost and not the benefit. This week kills more adoptions than any technical finding, and it should.
• Week 3 — pilot on one real domain, end to end. One domain, all the way through, with the enforcement switched on. For data contracts that means actually failing a producer's build. If that conversation goes badly, you have learned the most important thing available for the price of one awkward meeting.
• Week 4 — decide layer by layer. Re-score this table for your context. For medallion specifically, decide the number of layers deliberately: justify each one by what it does that its neighbours don't. Two is a common right answer. Three is a common inherited answer. Write down which you chose and why.

9. Final recommendation

Adopt analytics engineering unconditionally. Adopt the metrics layer where you can name the incident it would have prevented. Trial data contracts and medallion — deliberately, not by default. Assess lakehouse-native serving and design toward it.

Analytics engineering is the only one here I would adopt without a conversation. It scores well on all ten axes, the tooling is mature, the payback is weeks, and — crucially — CI enforces most of the discipline for you, so it survives the departure of the person who introduced it. It is also the substrate the other four assume, so adopting them first is building on sand.

Data contracts and the metrics layer are both genuinely valuable and both mis-sold. They are organisational instruments with a technical surface, not technical solutions with an organisational surface, and that is why they score lowest on discipline and time-to-value while scoring highest on governance. The test for both is the same: is there a named owner, and will you enforce it against someone who outranks you? If yes, they pay back enormously and get better as you grow. If no, you are building theatre, and theatre costs money.

Medallion deserves its Trial rather than an Adopt or a Hold, and the nuance is the point. The pattern is sound; the defaulting is not. It arrives pre-recommended by every lakehouse vendor's quickstart, which means most teams adopt three layers without deciding to, and inherit the worst failure mode on this page: when the discipline lapses — and it lapses — the layers collapse into one unmanaged zone while you keep paying triple for storage and pipeline steps. Decide your layers on purpose. Two is frequently right. And notice the deeper critique: medallion organises data around engineering convenience rather than business meaning, which is a trade worth making consciously and not by inheritance.

Lakehouse-native serving is the most durable idea here and the hardest to undo. Design new pipelines toward it, keep the copies until the engine has proved itself on your workload, and treat the catalog as the seam that keeps your options open.

Data mesh is a Hold, and it is the only entry here where I would push back on someone senior who wanted it. Not because the diagnosis is wrong — a central team really does become a bottleneck, and domain experts really do understand the data better than the platform team does. It is a Hold because the prescription is an organisational change you cannot ship, cannot pilot honestly, and cannot reverse cheaply, and because the failure mode is the worst on this page: a half-built mesh leaves you with N inconsistent domain stacks, no central authority to reconcile them, and the original bottleneck still in place with a coordination tax on top. Below about a hundred people in data you almost certainly have a coordination problem rather than a scale problem, and a mesh converts one problem into two. Take the vocabulary and the good ideas — domain ownership, data as a product, federated governance, a self-serve platform, all of which I'd steal outright — and leave the reorg on the shelf until your org is already moving that way for its own reasons. My longer version of this argument is in Data Mesh: what actually works and what doesn't.

Re-assess all of these next quarter — practices move slower than products, but the data-products critique of medallion is gaining ground, and that is the one most likely to change.

References

Practices have weaker evidence bases than products, and honest assessment means saying so. Most of what follows is argument rather than measurement — I have included the strongest case against medallion alongside the vendor guidance that recommends it, because reading only one of those is how the default gets inherited.

Scores are my own architect-level judgment for the stated use case, calibrated to mid-2026 — not a vendor ranking. These are practices, not products. The axes are re-cut accordingly and are NOT comparable with any product assessment. Re-score against your own POC numbers before you commit.