How the Architecture Radar works

What this radar is, and what it isn't

It is one architect's current judgment about where to point a client's next platform build, published with its reasoning attached. It is modelled on the ThoughtWorks Technology Radar — the rings and quadrants are theirs, and the debt is worth acknowledging plainly.

It is not a vendor ranking, a benchmark, or a survey. There is no panel, no methodology committee, and no weighting formula that turns ten numbers into a verdict. Those things sound more rigorous than they are: a weighted average of ten axes produces a number that is precise, comparable, and meaningless, because the axis that decides your build is the one that fails you, not the one that averages well. Nothing here aggregates the axes into a total score for exactly that reason.

The rings: what Adopt, Trial, Assess and Hold mean

Rings are about confidence and commitment, not quality. A Hold item can be excellent software. The ring answers one question: what would I do if a client asked me about this on Monday?

Two things people misread. Hold does not mean "rip it out." It means don't start here — an existing, working system is a different question, and migration cost is real. And Adopt is not permanent. Things move outward as well as inward; a technique that was an Adopt in 2024 can be a Trial in 2026 because the ground under it shifted, and if nothing ever moves outward the radar has become a scrapbook.

The quadrants

Four, borrowed wholesale from the ThoughtWorks model, and they answer "what kind of thing is this?":

• Techniques — ways of working. Medallion architecture, data contracts, semantic turn detection.
• Tools — things you install and operate. dbt, Airflow, Dagster.
• Platforms — things you build on. Snowflake, Databricks, ClickHouse.
• Languages & Frameworks — what you write against. SQL, Spark, LiveKit, Pipecat.

The boundaries leak, and I don't pretend otherwise. Is Databricks a platform or a tool? Is dbt a tool or a technique? I place things by how you decide about them: you evaluate a platform, you adopt a technique, you install a tool. When a thing is genuinely both — dbt is a tool that carries a technique — it can appear in two quadrants with different rings, because those are different decisions.

The Data and AI split

Every entry is tagged Data or AI, and the filter on the radar is there because most people arrive with one of those two problems, not both. The tag is assigned by what the technology is for, not by what it is built with: ClickHouse is Data even though people run vector search on it; MCP is AI even though it's a protocol. Where something genuinely spans both, it goes where the decision usually gets made.

How the axes get chosen

This is the part that differs most from other radars, and the part worth being explicit about. Each assessment gets ten axes chosen for its category, and axes are only comparable inside a category.

My analytics assessments — ClickHouse, Doris/StarRocks, Snowflake/Databricks/Fabric — all share one rubric, so you can read them onto the same chart and the numbers mean the same thing:

But applying that rubric to a voice agent platform would be theatre. "What is the Lakehouse Fit of LiveKit?" is not a question, and answering it 3.0 to fill the cell would be worse than not asking. So the voice assessment re-cuts the axes for voice (latency and turn-taking, telephony, model flexibility…), the orchestration assessment for orchestration, and the techniques assessment for practices. Each says so at the top. Scores are never comparable across assessments with different axes, and every such page states that in its own scope note rather than leaving you to infer it.

Two axes in the techniques assessment are deliberately inverted so that higher is always better on every chart: Low Discipline (how little ongoing rigour a practice demands) and Graceful Failure (how gently it degrades when nobody maintains it). A radar where some axes are good-high and others good-low is a radar nobody can read at a glance.

The 0–5 scale

The scale is about architecture risk for the stated use case, not about features.

Scores carry one decimal, and I want to be honest about what that decimal is and isn't. It is ordering, not precision. The difference between 4.3 and 4.4 is "I think this one is slightly ahead", not a measurement — nobody should defend a tenth of a point. The difference between 4.5 and 3.5 is a real, defensible claim about production risk, and I should be able to point at evidence for it. If a decision in your organisation turns on a tenth of a point on this page, the decision is not actually about the technology.

A useful sanity check I apply to my own numbers: almost nothing scores 5. Across every assessment here, the highest is 4.8. A 5 means "proven at target scale with low architecture risk" and very little clears that bar honestly. A page full of 5s is a page written by someone who hasn't operated the thing.

The evidence rules

This is the part that makes the rest worth reading, and the part I have to enforce on myself hardest.

Evidence, inference, assumption — labelled separately

Every score traces to one of three things, and they are not the same: evidence (a doc, a release note, a benchmark, a paper), inference (a conclusion I drew from evidence), or assumption (a judgment about your context — team size, skills, appetite). Assumptions get flagged in the text where they matter. When I score Dagster's ops burden, I am assuming a competent-but-not-specialist platform team, and that assumption changes the number by a full point either way. Saying so is the difference between an assessment and an opinion.

Sources are ranked, and vendors are read for mechanism

The preference order: peer-reviewed papers → official documentation → release notes → engineering blogs → independent benchmarks → GitHub issues → case studies → marketing. Vendor engineering blogs are evidence about how a thing works and marketing about whether it's good; I use them for the former. Where a claim is about performance, a reproducible benchmark beats an announcement. Where two vendors publish comparisons of each other, both are worth reading precisely because the disagreements point at the real trade-offs — and both are labelled partisan.

Every link is checked, and dead ones get removed

A citation nobody can follow is decoration. Links here are checked mechanically, and I have found real problems doing it: a citation I had reconstructed from memory that turned out not to exist, and a source domain that had gone NXDOMAIN since it was written. Both were removed rather than quietly left in. Worth knowing if you build your own check: vldb.org returns HTTP 200 with an HTML page for a missing PDF, so a status-code check passes on a paper that isn't there. Verify the content type.

The same bar for everyone

Comparators are scored on the same evidence standard as the target — no grading the favourite on a curve. When a platform appears in two assessments, its vector is identical in both: Snowflake's ten numbers in the cloud-platforms assessment are byte-for-byte the ones published in the ClickHouse assessment. That is enforced mechanically, not by memory.

Where the numbers live

Every score on this radar comes from one file — scorecards.json — and the scorecard table and interactive chart on each assessment are generated from it. This is deliberate. The numbers used to live in three places per page (a table, a static diagram, a chart), which is three chances to disagree with yourself, and I had them drift. One source, generated output, no drift.

It's machine-readable on purpose. If you want to argue with a score, take the JSON.

graph LR
  U["Use case
stated up front"] --> AX["Choose 10 axes
for the category"]
  EV["Evidence
docs, papers, releases"] --> SC["Score 0-5
target + comparators"]
  AX --> SC
  AS["Assumptions
labelled, not hidden"] -.-> SC
  SC --> J[("scorecards.json
single source of truth")]
  J --> TB["Scorecard table"]
  J --> CH["Interactive radar"]
  SC --> RING["Ring: Adopt / Trial
/ Assess / Hold"]
  RING --> RAD["The radar"]
  POC["Your POC numbers"] -.->|"should overrule this"| RING
  Q["Quarterly review"] -.->|"entries move"| RAD

The review cadence

Quarterly, and every entry carries the quarter it was last looked at. This edition is 2026-Q3.

A radar without a date is an opinion with no shelf life. In this field a call that was right four quarters ago can be actively wrong now — the ClickHouse lakehouse score moved on new evidence within a single edition, and the dbt vendor-risk score changed because of a merger, not because of any code. A quarterly stamp lets you discount an entry by its age instead of trusting it indefinitely, which is the correct thing to do with someone else's judgment.

What moves an entry between editions: new evidence, a release that closes a gap, a change in who owns the project, or my own experience running it somewhere. What does not move it: a funding round, a rebrand, or a conference keynote.

What each assessment contains

Every full assessment follows the same nine sections, so you can skip to the one you need: an executive summary and verdict; positioning; the per-axis reasoning; the scorecard; the radar; workload-specific analysis; a reference architecture; a four-week POC plan; and the final recommendation with references. The POC plan is not filler — it is the part that says go and measure this yourself, and every assessment ends by telling you to overrule it with your own numbers.

Known biases

Every methodology page should have this section and almost none do. Mine, as best I can name them:

• I am one person. No panel, no vote. The upside is a coherent point of view; the downside is that my blind spots are the radar's blind spots, with nothing to catch them.
• I have run some of these and only read about others. Things I have operated at 3am get scored more harshly on ops burden, because I know where the bodies are. That is a real asymmetry and it probably flatters the tools I haven't been burned by.
• I bias toward boring. Operational calm and hiring pools weigh heavily in my scores. If you are a startup optimising for capability over stability, weight my Ops and Ecosystem axes lower and my Performance axis higher.
• My context is enterprise data and AI platforms — regulated industries, multi-team, migration-heavy. That is the client shape I see, and the "typical" use case at the top of each assessment reflects it. If you are a five-person team, several of these verdicts flip.
• Recency. A technology I assessed this quarter gets more careful treatment than one I have carried forward. The review cadence is the mitigation; it is not a cure.

How to disagree with this radar

Usefully, and in roughly this order. Start with the use case at the top of the assessment — if it isn't yours, the scores aren't either, and that resolves most disagreements before they start. Then check the assumption behind the axis you object to; if I assumed a platform team you don't have, the number is wrong for you and the page should say which assumption it rests on. Then bring evidence: a release note, a benchmark, a production war story. A score I can't defend against a real source should move, and the quarterly cadence exists so that it can.

What won't move a score: a vendor's marketing page, a Gartner square, or a claim that a thing is popular. Popularity is not evidence of production fitness — see the star counts on the code knowledge graph tools, where a three-month-old project has 89,000 stars and several hundred open issues.

The ring and quadrant model is adapted from the ThoughtWorks Technology Radar, whose FAQ is worth reading on why a radar is a point of view rather than a survey. The scoring rubric, the axes, and every judgment here are my own.