Running Well Architected Reviews That Change Things

The Well Architected Framework is five pillars, reliability, security, cost optimization, operational excellence, performance efficiency, and it is either a genuinely useful engineering instrument or a compliance ritual, depending entirely on how you run it. Today: making it the former.

Pillars Are Tradeoffs, Not Checkboxes

The framework’s actual insight is that the pillars tension against each other and every architecture is a chosen position among them. Zone redundant HA on the PostgreSQL post is reliability purchased with cost and write latency. The firewall inspecting all egress is security purchased with operational complexity and throughput. Scale to zero on Container Apps is cost purchased with cold start performance. A review that produces a hundred findings with no tradeoff analysis has misunderstood the exercise; the valuable output is explicit, recorded positions: this workload targets 99.9 not 99.99 because the revenue impact does not justify the second region, signed by the product owner, revisitable when the business changes. Half the WAF’s value is forcing those sentences to exist.

Running the Review

The format that works: one workload at a time, never “the platform” in the abstract; two to three hours with the people who operate it, not just the architect who drew it; the Azure Well Architected Review assessment in the portal as the question spine, filtered to the pillars that matter most for this workload right now, because sixty questions across five pillars in one sitting produces fatigue, not insight. Prepare with data, the review lands differently when the reliability questions sit next to last quarter’s incident list, the cost questions next to the amortized trend from this week’s FinOps posts, and the security questions next to the Defender secure score and attack paths from September. The output contract is fixed before the meeting: every finding becomes either a backlog item with an owner and a size, an accepted risk with a name attached and a review date, or a dependency on the platform team logged in their backlog, and nothing becomes a wiki page of concerns. Prioritize with the same expected value logic as the FinOps optimization projects: impact against effort, ties broken toward reliability for revenue path workloads.

Making It Continuous

The annual review theater fails because architecture decays daily. The continuous version distributes the framework into the machinery this series has built: Azure Policy and the module defaults encode the security and reliability baseline so new resources start compliant; Advisor, which is essentially automated WAF findings, feeds its recommendations into the same triage rhythm as cost anomalies; the service level objectives and alerting from the Monitor post are the reliability pillar’s living instrumentation; and the design review template for new work carries one section per pillar with a sentence each, forcing the tradeoff conversation at the moment it is cheapest. Reserve the workshop format for three triggers: onboarding a workload to production, after a serious incident (the review and the postmortem cross pollinate perfectly), and when the business context shifts, new compliance scope, new scale target, new cost pressure. Run this way, the framework stops being an audit you pass and becomes the shared vocabulary in which the estate’s decisions are argued, which is the most an architecture framework can honestly achieve.

Cheers
Osama

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.