- Duration: 120 minutes
- Prerequisites: All modules M01 through M07
- Primary Metrics: Discovery Audit + Jargon-Free Test + Consensus Score
- Frameworks: 5 (ADR, Decision Latency, One-Way Door, Two-Way Door, War Room)
ADR (Architecture Decision Record)
A structured document that captures not just what architectural decision was made, but why it was made, what alternatives were considered, what constraints ruled them out, and what the compliance path is. ADRs prevent “we’ve always done it this way” and “who decided that?”:the two phrases most responsible for architectural debt accumulation. Used well, the ADR is not a historical artifact; it is a living alignment document that surfaces when the constraints that drove the original decision have changed.
Decision Latency
The time between when a decision is needed and when it is made. Decision latency is the number-one cause of project delays that never appear in a project management tool, because the delay is attributed to subsequent work, not to the original deferral. The framework measures latency for each open architectural decision, names the owner and the blocker, and creates urgency without creating pressure:by making the cost of delay visible in the same financial language as the project itself.
One-Way Door
Amazon’s framework: some architectural decisions are effectively irreversible within the life of the project:vendor lock-in, data residency choices, security architecture foundations, network topology. These are One-Way Doors. They deserve proportional analysis, broad stakeholder consultation, and explicit consensus before commitment. Treating a One-Way Door as reversible is the most common source of architectural regret that surfaces two years after go-live.
Two-Way Door
Reversible decisions should move fast. The naming convention, the development environment toolchain, the internal API versioning strategy:these are Two-Way Doors. Applying One-Way Door rigor to Two-Way Door decisions is the most common cause of decision latency in high-functioning technical organizations. The framework trains architects to classify quickly and spend their alignment capital on the decisions that deserve it.
War Room
A time-boxed facilitated session designed to produce a documented decision within a defined window:typically four hours or fewer. The War Room has a structured agenda: (1) surface all constraints and data, (2) present options with their trade-offs, (3) establish the decision criteria, (4) vote, (5) document the ADR. The facilitator’s role is to ensure the decision happens:not to advocate for a position. The architect who runs the War Room effectively is demonstrating the Trusted Advisor posture: they own the process, not the outcome.
A $8B regional bank, 14 months of stalled cloud migration, and three decisions no one would own
Situation
Meridian Financial Group: an $8B regional bank: is 14 months into a cloud migration that was scoped for 18 months total. Three architectural decisions are formally open in the project tracker: (1) cloud-native rebuild vs. lift-and-shift for the core transaction ledger, (2) microservices vs. modular monolith for the new customer-facing API layer, (3) on-premises vs. Azure Confidential Computing for cardholder data. No owner is listed for any of them. The program manager attributes all schedule slippage to “downstream dependencies” and “vendor delays.” The architects attribute it to “waiting on direction.” No one has named the stall as a decision problem.
Move 1: Decision Latency audit
The architect runs a Decision Latency analysis on all three open items. Cloud-native vs. lift-and-shift has been open 11 months; every week it stays open costs $62K in parallel-path infrastructure spend. Microservices vs. modular monolith has been open 8 months; 14 engineers are building against an undecided API boundary, producing work that will require partial rework regardless of outcome. The cardholder data question has been open 6 months; compliance review cannot begin until it resolves. Total weekly latency cost: $180K. The architect presents this as a financial statement, not a technical one.
Move 2: One-Way Door classification
The architect classifies all three decisions using the One-Way Door framework. Cloud-native rebuild is a One-Way Door: if Meridian commits to a rebuilt transaction ledger, they cannot return to lift-and-shift without re-incurring 18 months of re-engineering. Confidential Computing is a One-Way Door: the security architecture and HSM procurement path locks in a vendor relationship and compliance posture that changes how cardholder data is governed going forward. Both decisions have been treated as Two-Way Doors: deferrable, revisable, low-stakes: and this misclassification is the root cause of the 14-month stall. Microservices vs. modular monolith is reclassified as a Two-Way Door: the API contract can be versioned, and a modular monolith can be decomposed incrementally. It should be decided in 48 hours and delegated to the engineering lead.
Move 3: ADR drafting before the War Room
The architect drafts an ADR for each of the two One-Way Door decisions in advance of the War Room. The ADRs separate verified constraints from working assumptions. For cloud-native vs. lift-and-shift: the regulatory constraint is verified (OCC examination timeline); the technical readiness of the engineering team is listed as an assumption requiring a two-week skills audit. For Confidential Computing: the cardholder data classification is verified; the HSM vendor's support path is listed as an assumption awaiting a vendor call. The pre-built ADRs mean the War Room begins with evidence on the table, not debate about what is true.
Move 4: War Room execution
A four-hour War Room is scheduled with the CTO, CISO, CFO, and program lead. The architect facilitates, not advocates. The agenda: (1) 20 minutes reviewing the Decision Latency cost statement: $180K/week, $7.2M to date in stall cost; (2) 30 minutes on the One-Way Door ADR for cloud-native vs. lift-and-shift, options and decision drivers only; (3) vote and document; (4) 30 minutes on the Confidential Computing ADR; (5) vote and document; (6) 20 minutes on the Two-Way Door microservices decision: delegated to engineering in the room. The War Room produces two completed ADRs, one delegated decision, and a compliance review kickoff date. Fourteen months of stall resolves in four hours.
Outcome
Decisions: cloud-native rebuild approved with a 90-day skills audit as a pre-condition; Azure Confidential Computing approved with HSM vendor call due in 10 days; modular monolith approved by engineering lead before the War Room adjourned. The program moved from three open decisions to zero open decisions. The subsequent six weeks produced more architectural progress than the prior 14 months combined: not because the technical work changed, but because the decision foundation under it stabilized. The architect’s contribution: a financial audit, a classification framework, two pre-built ADRs, and a facilitated session. No slide deck, no recommendations, no advocated position.
Two VPs, a cardholder data decision, and a War Room that almost didn’t have a facilitator
Situation
Larkfield Health Network is a 9-hospital system building a new patient data platform. The VP of IT and the VP of Clinical Operations agree on the overall architecture but have reached a deadlock on a single question: whether the patient matching algorithm should run in a centralized cloud service or remain federated in each hospital’s local environment. The debate has been running for six weeks in email threads and has escalated to the CIO. The CIO’s response: “figure it out and tell me what you decided.”
Move
The architect declines to take a position and instead proposes a War Room with three rules: (1) no one advocates for their prior stated position in the first 20 minutes: both VPs must articulate the strongest case for the other side; (2) the Decision Latency cost of continued deadlock is stated at the opening and remains visible on the whiteboard throughout; (3) the output is a signed ADR, not a consensus feeling. The role-reversal opening in rule (1) surfaces two constraints neither VP had stated publicly: the VP of IT acknowledges that centralized architecture requires a BAA amendment that procurement is not ready to process in time; the VP of Clinical Operations acknowledges that federation means 9 separate maintenance contracts and she doesn’t have the staff for it. Both constraints were known individually. Neither had been named in the shared conversation.
Outcome
The decision: federated matching for the first 12 months with a centralization trigger defined in the ADR: if procurement resolves the BAA amendment within the project window, the architecture migrates. The ADR is signed by both VPs. The six-week email thread resolves in 90 minutes. The War Room’s value was not the outcome: both sides could have reasoned their way there. The value was the structured constraint-surfacing that made a shared decision possible without requiring either VP to lose face.
The ADR that got updated twice and saved a $2.4M re-architecture
Situation
Atlas Pharmaceuticals is three years into a cloud-native data platform built on Azure Databricks and Data Factory. An ADR was written at the start of the program documenting the choice to use a medallion architecture (Bronze/Silver/Gold) over a data vault. The ADR included a compliance path: “Revisit if the number of regulated data sources exceeds 40 or if EU GMP Annex 11 requirements are adopted.” Three years later, Atlas has 53 regulated data sources and is entering Annex 11 scope. No one on the current team was present when the ADR was written. The original architect left the company two years ago.
Move
The compliance path clause in the ADR is triggered. The new architect reads the original ADR and finds the context that is no longer visible in the codebase: the reason medallion was chosen over data vault was a team capability gap at the time: the Atlas data engineering team had no data vault experience, and the training investment was not in scope. That constraint is now inverted: the team has 3 years of medallion experience and zero data vault knowledge. The original reasoning is preserved; the decision is still correct. The ADR is updated with a second entry: “Trigger condition met (53 regulated sources, Annex 11 in scope). Decision reviewed [date]. Medallion architecture retained. Reason: team capability constraint cited in v1 is now an asset, not a risk. Data vault migration would require 18 months of re-training and platform rebuild. Annex 11 compliance addressed via audit trail layer added above existing Gold zone. No architectural migration required.”
Outcome
The ADR’s compliance path clause avoided a $2.4M re-architecture that a competing vendor had proposed. The original decision was correct three years later: but without the documented reasoning, the team had no basis to resist the re-architecture proposal. The ADR was the evidence. The lesson: an ADR without a compliance path is an archive. An ADR with a compliance path is a living constraint that protects future architects from re-litigating settled decisions without new information.
The Two-Way Door that got treated as a One-Way Door: and what it cost
Situation
Coastal Logistics is deploying a new freight tracking platform. The team is debating internal API versioning strategy: semantic versioning vs. date-based versioning. It is a well-understood technical question with reasonable arguments on both sides. The team lead escalates it to the architecture review board, which schedules a three-week review with a formal written recommendation. Six engineers pause work on API development while the review proceeds.
Move
A newly onboarded architect asks one question in the first review meeting: “If we choose semantic versioning today and discover in six months it’s the wrong call, what does the migration cost?” The answer: two days of automated rename scripts across internal services. The architect names the classification out loud: this is a Two-Way Door. The reversal cost is negligible; the decision has been escalated to the wrong level of rigor. The recommendation to the review board: make the decision in this meeting, document it in a two-paragraph ADR, and close the review.
Outcome
The decision is made in 12 minutes: semantic versioning, two-paragraph ADR, six engineers back on API development the same afternoon. The three-week review is cancelled. The cost of misclassifying a Two-Way Door as a One-Way Door at Coastal Logistics: three weeks of decision latency, six engineers partially blocked, and an architecture review board credibility problem that took months to repair. The One-Way Door / Two-Way Door classification is not a philosophical framework. It is a cost-avoidance tool. Applying it before escalating a decision is one of the highest-leverage moves an architect makes in a program week.
ADR Workshop
Write a complete ADR for a real or fictional architectural decision. Use M08_ADR_Template.docx. The test is whether a stakeholder who was not in the room can understand why the decision was made and what would justify revisiting it.
- Choose a real architectural decision from a recent engagement (or use the fictional scenario in the module folder). It should be a decision with at least two credible alternatives.
- Complete all sections of the ADR: (a) decision title and date, (b) context:what was the problem being solved, (c) decision:what was chosen, (d) alternatives considered and why they were ruled out, (e) decision drivers:the constraints that made this the right choice, (f) consequences:what this decision commits you to, (g) compliance path:what signal would indicate this decision should be revisited.
- Present the ADR to a peer who will challenge the decision drivers. Their job is to find any driver that is an assumption rather than a verified constraint. For each assumption they surface, update the ADR.
- After the challenge, ask: does the ADR now contain enough information for a future architect to understand why not to change this decision without good reason?
Decision Classification Sprint
Build the classification reflex. The goal is to classify correctly and quickly:not to deliberate on edge cases.
- Using M08_Decision_Classification_Cards.pdf, work through all 10 fictional architectural decisions. For each, classify as One-Way Door or Two-Way Door and estimate the decision latency risk (Low/Medium/High) if the decision is deferred one week.
- For the three decisions with highest latency risk, write the escalation criteria: the specific condition under which you would force a decision within 5 business days, the person you would escalate to, and the one-sentence framing you would use to create urgency without creating alarm.
- Compare your classifications with a peer. Where did you disagree? Work through the disagreements to a resolution. Document the disagreement and the reasoning:this is a real-world ADR situation in miniature.
War Room Simulation
Run a full War Room simulation on a deadlocked architectural decision. This exercise integrates Discovery (surfacing constraints), financial fluency (cost-of-latency framing), influence (managing conflict), and storytelling (framing the decision for different audiences). One person facilitates. Everyone else plays a named stakeholder role from the module folder scenario.
- Assign roles from M08_War_Room_Facilitation_Guide.pdf: Facilitator, CTO (skeptical, values stability), VP Engineering (values velocity), CFO (values cost predictability), Security Lead (values compliance). Brief each person on their character’s priorities and red lines.
- Facilitator sets the agenda and time-box: 45 minutes, hard stop, documented decision required. The facilitator may not advocate for a position.
- Run the War Room through all five phases: surface constraints (10 min) → present options (10 min) → establish decision criteria (10 min) → vote (5 min) → document ADR in the room (10 min).
- At the end, each participant rates the facilitator on the Consensus Score: 1–5 on feeling heard and genuinely consulted. Target: 4/5 or higher across all players.
- Debrief: was a decision documented? Was it the right one? What would the facilitator do differently?
This rubric covers all three program metrics. Completion requires “Ready” on all primary-metric indicators and “Ready” or “Developing” on all stretch indicators. If any primary-metric indicator is “Not Yet,” return to the relevant module before completing the capstone assessment.