Architecture Review & Case Studies
The purpose of architecture review is not to bless a diagram. SEI ATAM-style evaluation asks whether decisions satisfy quality-attribute scenarios, expose risks, and make tradeoffs explicit. A strong review helps teams move with confidence because it connects drivers, decisions, risks, and feedback. A weak review becomes a presentation ritual where hard questions arrive after implementation.
Senior reviews are scenario-driven. Instead of asking whether a design uses the right pattern, ask how it behaves under change, load, failure, misuse, growth, migration, and operation. The review should surface assumptions and decide which assumptions need evidence. The outcome is not always approval or rejection. Often it is a refined decision, a small experiment, a missing owner, or a staged migration plan.
Review Inputs
A useful review package is concise. It should include context, goals, non-goals, key quality scenarios, domain boundaries, data ownership, integration contracts, deployment topology, security and privacy concerns, operational model, alternatives considered, risks, and open questions. The package should be small enough that reviewers can read it before the meeting.
The most important input is the decision frame. What decision is being made now? What options are still open? What is irreversible? What evidence exists? What evidence is missing? Without this frame, reviews drift into personal preference and pattern advocacy.
Case Study: Marketplace Checkout
Consider a marketplace where buyers purchase from third-party sellers. The business drivers are conversion, payment correctness, seller independence, fraud control, and expansion to new regions. The quality scenarios include: checkout remains available during recommendation failure; duplicate payment is impossible; tax and compliance rules vary by region; fulfillment can lag but must be visible; fraud review may pause risky orders; support can explain order state.
A naive design might make checkout synchronously call pricing, tax, inventory, payment, fraud, fulfillment, notification, and analytics. It looks straightforward but creates a fragile latency chain. A better design might keep pricing, inventory reservation, and payment authorization in the critical path while publishing order events for fulfillment, notifications, analytics, and support projections. Fraud decisioning may be synchronous for high-risk baskets and asynchronous for low-risk monitoring, depending on business policy.
The review questions would include: Which rules must be immediately consistent? What is the latency budget? What happens when fraud is unavailable? How are duplicate payment attempts prevented? Can support see eventual states? Which team owns the checkout outcome? What event schemas are contractual? How are regional tax rules introduced without redeploying every service?
Case Study: SaaS Tenant Isolation
Consider a B2B SaaS platform moving upmarket. Enterprise customers require SSO, audit logs, role-based access, tenant-specific retention, data export, and stronger isolation. The key architectural question is not “single tenant or multi tenant?” It is what level of isolation each quality requires: identity, authorization, data storage, encryption keys, noisy-neighbor control, deployment, and operational access.
One design may keep shared application services but introduce tenant-scoped authorization, row-level security, per-tenant encryption keys, tenant-aware rate limits, and audit trails. Another may isolate high-value tenants into dedicated databases or clusters. The tradeoff is cost and operational complexity versus risk reduction and enterprise fit.
The review should ask: What tenant data can appear in logs, caches, analytics, and support tools? Can one tenant’s load harm another tenant? Who can access tenant data operationally? What is the migration path from shared to dedicated isolation? Which isolation decisions are contractual and which are implementation details?
Case Study: Legacy Modernization
Legacy modernization is rarely a rewrite. Rewrites are tempting because they promise a clean future, but they often fail because the old system encodes business rules nobody fully remembers. A safer architecture usually creates a strangler facade, extracts capabilities gradually, synchronizes or migrates data with reconciliation, and measures behavior equivalence.
The architectural challenge is coexistence. The old and new systems must share identity, routing, data, reporting, and operational support during migration. The design needs a decision for each capability: keep, wrap, replace, extract, or retire. It also needs a kill plan for migration scaffolding so the strangler does not become another permanent layer.
Review Outcomes
A review should end with decisions, risks, owners, and next evidence. “Looks good” is not an outcome. Better outcomes include: approve the decision with documented tradeoffs; run a spike to validate latency; require a contract test before launch; split a boundary differently; add an operational control; defer service extraction; or create a migration checkpoint.
Architecture review is a learning loop. The best teams revisit decisions after incidents, scale changes, onboarding pain, security findings, or major product shifts. The review is not a gate at the beginning. It is a way to keep the architecture connected to reality.
Practice
Run a capstone review for one of the case studies or for a system you know. Prepare a one-page review packet with drivers, quality scenarios, boundaries, data ownership, runtime view, security view, tradeoffs, risks, and fitness functions. Then write the review outcome as an ADR with a review trigger.
References & Further Reading
- SEI: Architecture Tradeoff Analysis Method Collection (Carnegie Mellon University/SEI, standard copyright)
- ISO/IEC/IEEE 42010: Architecture Description (standard copyright)
- The C4 Model for Visualising Software Architecture (CC BY 4.0)
- Architectural Decision Records (ADR community site, CC BY 4.0 where noted by project pages)