How do you evaluate competing architectural style candidates rigorously rather than by opinion? Describe a concrete method and what its outputs are.

### Why rigour is needed Style debates default to preference because the arguments are about the future and nobody can falsify them in a meeting. The fix is to convert abstract attributes into *scenarios* — statements concrete enough that two people can disagree and then check. ### Scenarios and the utility tree A well-formed scenario has three parts: a **stimulus** (what happens), an **environment** (under what conditions), and a **response measure** (the observable threshold). "The system is scalable" is useless; "peak order rate rises from 500 to 5,000 per second over 12 months while p99 checkout latency stays under 300 ms" is testable. A **utility tree** organises these: the root is overall utility, branches are quality attributes (performance, availability, modifiability, security, deployability), leaves are scenarios, each tagged with two priorities — business importance and technical difficulty. High/high leaves are where evaluation effort belongs. ### ATAM in brief The Architecture Tradeoff Analysis Method (from the Carnegie Mellon Software Engineering Institute) is a structured workshop: present the business drivers, present the candidate architecture, identify its architectural approaches, build the utility tree with stakeholders, analyse the top scenarios against each approach, brainstorm and re-prioritise scenarios with a wider group, analyse again, and present results. Its four output categories are the part worth memorising: - **Risks** — decisions that may not meet a target ("a single shared datastore may not sustain the 5,000/s write target"). - **Non-risks** — decisions confirmed safe *given stated assumptions*; recording the assumption matters, because if it changes the non-risk becomes a risk. - **Sensitivity points** — a decision that strongly moves one attribute (replica count drives availability). - **Tradeoff points** — a decision that moves two or more attributes in opposite directions (synchronous replication raises consistency and durability while lowering write latency and availability). These are the genuine architectural decisions; everything else is detail. Full ATAM is heavyweight. Most teams run a compressed version: half a day with the top five to eight scenarios, using the same four output categories. ### Complementary techniques - **Back-of-envelope maths.** Estimate request rate, payload size, storage growth and fan-out before choosing. Many debates collapse once someone computes that the whole dataset fits in memory on one machine. - **Spikes and prototypes.** Time-boxed experiments against the single riskiest assumption — not a full build, just enough to falsify it. - **Pre-mortem.** Imagine it is 18 months later and the architecture failed; have everyone write down why. Surfaces risks that optimism suppresses. - **Decision matrix.** Candidates as rows, prioritised attributes as columns, honest scores. Its value is forcing explicit reasoning; beware fake precision from arbitrary weights. - **Fitness functions.** Automated, continuously executed checks that a chosen characteristic still holds: a load test asserting a latency budget, an architecture test asserting module dependency rules, a chaos experiment asserting failover time, a budget on startup time or bundle size. This is what converts "we chose this for scalability" from a claim into a verified property, and it is the core idea of evolutionary architecture. ### Pitfalls Evaluating one candidate in isolation produces confirmation, not comparison — always score at least two. Scenarios written only by architects miss operational and business realities, so include operations, security and product people. Analysis can also become its own delay: if a decision is cheap to reverse, prototype instead of analysing. And record the assumptions behind every non-risk, since most architectures fail when an assumption silently expires rather than when a known risk fires.