What is the Well-Architected Framework (the pillars), and how do you use it in a design review?

package com.bank.architecture;

import java.util.List;

public class WellArchitectedReview {

    public enum Pillar {
        OPERATIONAL_EXCELLENCE,
        SECURITY,
        RELIABILITY,
        PERFORMANCE_EFFICIENCY,
        COST_OPTIMIZATION,
        SUSTAINABILITY
    }

    public enum RiskLevel { HIGH, MEDIUM, LOW }

    public record Finding(Pillar pillar, String description, RiskLevel risk, String owner) {}

    public List<Finding> reviewPaymentsService() {
        return List.of(
            new Finding(Pillar.OPERATIONAL_EXCELLENCE,
                "No runbooks for incident response", RiskLevel.HIGH, "Rajesh"),
            new Finding(Pillar.RELIABILITY,
                "Database is single-AZ, no tested DR", RiskLevel.HIGH, "Priya"),
            new Finding(Pillar.COST_OPTIMIZATION,
                "Peak-sized instances running 24/7", RiskLevel.MEDIUM, "Pankaj"),
            new Finding(Pillar.SECURITY,
                "Least privilege and encryption in place", RiskLevel.LOW, "N/A")
        );
    }
}

# Example: Reliability pillar checklist for bank-transfer-service
reliability:
  multi_az: true
  auto_failover: true
  backup_frequency: "every 15 minutes"
  rto: "30 minutes"
  rpo: "5 minutes"
  dr_tested: false  # HIGH RISK -- DR plan exists but never tested
  chaos_testing: false

package com.bank.architecture;

public class PillarTradeoff {

    // For a core payments ledger: consciously spend more for reliability and security
    public static final int REPLICAS = 5;           // Higher cost, higher reliability
    public static final boolean MULTI_AZ = true;    // Higher cost, higher reliability
    public static final boolean ENCRYPTION = true;  // Slight latency, required for security

    // For an internal analytics batch: trade reliability for lower cost
    public static final int ANALYTICS_REPLICAS = 1;     // Lower cost, lower reliability
    public static final boolean ANALYTICS_SPOT = true;  // Much lower cost, can be interrupted
}

 Review Process:

 1. Define the workload and its business criticality
 2. Walk through each pillar's questions with architects and operators
 3. For each question: is the practice in place?
 4. If not, record a finding with risk level:
      - HIGH: could cause data loss or outage
      - MEDIUM: degrades the workload
      - LOW: minor improvement
 5. Produce a prioritized improvement plan
 6. Assign owners and deadlines
 7. Schedule a follow-up review (architecture drifts)

package com.bank.architecture;

import java.time.LocalDate;
import java.util.List;

public class ReviewReport {
    private final String workload;
    private final String criticality;
    private final List<WellArchitectedReview.Finding> findings;
    private final LocalDate reviewDate;
    private final LocalDate followUpDate;

    public ReviewReport(String workload, String criticality,
                        List<WellArchitectedReview.Finding> findings) {
        this.workload = workload;
        this.criticality = criticality;
        this.findings = findings;
        this.reviewDate = LocalDate.now();
        this.followUpDate = LocalDate.now().plusMonths(3); // quarterly review
    }

    public List<WellArchitectedReview.Finding> getHighRiskFindings() {
        return findings.stream()
            .filter(f -> f.risk() == WellArchitectedReview.RiskLevel.HIGH)
            .toList();
    }
}

 Well-Architected Review: bank-transfer-service
 Date: 2024-03-15
 Criticality: Tier 1 (core payments)

 HIGH RISK:
 1. [Ops Excellence] No runbooks for incident response
    Owner: Rajesh | Deadline: 2024-04-01
 2. [Reliability] Database single-AZ, DR never tested
    Owner: Priya  | Deadline: 2024-04-15

 MEDIUM RISK:
 3. [Cost] Peak-sized instances running 24/7, no auto-scaling
    Owner: Pankaj | Deadline: 2024-05-01

 LOW RISK:
 4. [Sustainability] Idle dev environments not auto-stopped

 CLEAN:
 - [Security] Least privilege, encryption at rest and in transit, audit logging enabled

 Follow-up review: 2024-06-15

# WRONG: treating the review as a checkbox exercise
"We did the review, everything is fine."
# No findings recorded, no improvement plan, no follow-up

# CORRECT: concrete findings with owners and deadlines
Finding: DR plan never tested
Owner: Priya
Deadline: 2024-04-15
Action: Run a game-day failover to the recovery region

# WRONG: optimizing one pillar at the expense of all others
"We need maximum reliability, cost is no object."
# Result: 10x replicas across 3 regions for an internal reporting tool

# CORRECT: match investment to business criticality
Tier 1 (payments): Multi-AZ, active-active, high cost -- justified
Tier 3 (analytics): Single-AZ, spot instances, low cost -- appropriate