The Well-Architected Framework isn't a checklist

A typical Well-Architected review goes like this: an AWS Solutions Architect joins a call, shares their screen, and works through the WAF tool question by question. The team answers “yes”, “no”, or “not applicable” for ninety minutes. A PDF lands in someone’s inbox. Three months later, nothing has changed — except the PDF is now buried in a folder nobody opens.

This isn’t a failure of the framework. It’s a failure of the ritual.

The Well-Architected Framework is not a compliance checklist. It’s a structured way to surface the gap between the system you think you have and the system you actually have. That gap is where your next incident lives. That gap is what your on-call rotation is quietly absorbing every week.

When you run a review as a compliance exercise, you get a score. When you run it as an architectural honesty session, you get a roadmap.

Here’s how to do the second one.

Before the review: scope ruthlessly

The WAF tool covers six pillars and hundreds of questions. Trying to answer all of them in a single session produces shallow answers across the board. Shallow answers produce generic recommendations. Generic recommendations don’t get prioritised.

Pick one or two pillars based on where you have the most pain. If your team is regularly woken up at 2am, lead with Reliability. If your AWS bill is growing faster than your users, lead with Cost Optimisation. If you just hired three engineers and can’t explain your deployment process to them, lead with Operational Excellence.

Pillar focus is not scope reduction — it’s depth preservation. You’ll cover more ground by going deep on two pillars than by skimming all six.

Also: include the engineers who maintain the system, not just the engineers who built it. The people who handle incidents know things about the system that aren’t in any architecture diagram. That knowledge is the point of the review.

During the review: treat every “yes” as a hypothesis

Most teams answer WAF questions from memory. Memory is optimistic. When someone says “yes, we have automated backups”, the correct follow-up is: when did we last test a restore?

The discipline that separates a useful review from a box-ticking exercise is treating every affirmative answer as a hypothesis to be verified, not a fact to be recorded. You don’t need to verify everything on the call — but you should flag every answer that’s based on assumption rather than recent evidence.

Build a running list as you go. Two columns: confirmed (we verified this in the last 90 days) and assumed (we believe this is true but haven’t checked recently). At the end of the session, your “assumed” column is your actual risk surface.

This reframe matters because most teams discover that their assumed column is much longer than they expected. That’s not a sign of a poorly-run system — it’s a sign of an honest review.

The questions the tool doesn’t ask

The WAF tool asks good questions, but they’re designed to be system-agnostic. Your system is specific. The most valuable architectural insights usually come from questions the tool doesn’t include.

Some worth adding to any review:

On blast radius: If this component fails at peak traffic, what’s the user-visible impact? Can you degrade gracefully, or does it take down everything?

On cognitive load: Could a new engineer diagnose a production incident in this system without help? If not, what’s missing — observability, runbooks, or both?

On drift: Does your infrastructure-as-code accurately reflect what’s deployed? When did you last run terraform plan or cdk diff against production and get a clean output?

On recovery: Your RTO is documented somewhere. When did you last actually test it? Not simulate — test, against a real failure, with a clock running?

On cost attribution: Can you tell, for any given feature, what it costs to serve per user per month? If not, you can’t make cost-aware architecture decisions.

These questions don’t have yes/no answers. They generate conversation, and the conversation is where the value is.

After the review: triage, don’t catalogue

The WAF tool generates a list of High Risk Items (HRIs). A typical review produces between ten and thirty of them. Trying to fix all of them is how nothing gets fixed.

Triage the HRI list using two axes: likelihood (how probable is this risk materialising in the next six months?) and impact (when it does materialise, what breaks?). High likelihood × high impact items go into the next sprint. Everything else goes into a backlog with an assigned owner and a review date.

The output of the review should not be a PDF. It should be a set of tickets in your issue tracker, with owners, with acceptance criteria, and with a definition of what “fixed” looks like. If a recommendation can’t be expressed as a ticket, it’s not specific enough.

One pattern that works well: for each HRI, write a one-sentence architectural decision that resolves it. “We will implement circuit breakers on all external service calls” is an ADR, not a recommendation. ADRs get implemented. Recommendations get filed.

The cadence that makes it stick

A single annual WAF review is better than nothing. Quarterly reviews are better. But the most effective teams don’t treat the WAR as a periodic audit — they treat the six pillars as a permanent lens.

This means the Reliability pillar is part of your incident retrospective template. The Cost Optimisation pillar is part of your sprint planning when you’re introducing a new service. The Security pillar is part of your PR review checklist for infrastructure changes.

The framework becomes useful when its questions become habits, not when its completion generates a report.

What changes when you run it honestly

Teams that run Well-Architected reviews as compliance exercises accumulate a false sense of architectural confidence. They have the PDF. They answered the questions. The system is well-architected.

Teams that run them as architectural honesty sessions accumulate something more valuable: an accurate picture of where their system is fragile, where their processes are assumed rather than verified, and where the next six months of engineering investment should go.

The framework doesn’t tell you how to build a well-architected system. It tells you how far the system you have is from the system you want. That distance is the roadmap.

Use it like one.