Strategic Architect Framework: Microsoft CSA Training Program

Architecture Decision Record (ADR)

Module 08: Decision Latency & Architectural Leadership

What is an ADR? An Architecture Decision Record captures not just what was decided, but why: what constraints drove the decision, what alternatives were considered, and what signal would indicate the decision should be revisited. A well-written ADR prevents the two phrases most responsible for architectural debt accumulation: “we’ve always done it this way” and “who decided that?” Complete all sections. Incomplete ADRs are summaries, not ADRs.

ADR Number

Date

Customer / Engagement

Decision Owner

Decision Title (noun + verb + adjective: e.g., "Deploy transaction layer as modular monolith")

Section 1: Status

Current status

Supersedes (if applicable)

Section 2: Context

What is the architectural problem being solved? Describe the situation that makes a decision necessary: the constraints, the forces in tension, and what happens if no decision is made. Be specific. "We need to modernize" is not context. "The current batch process runs on a 7-year-old SQL Server cluster that cannot horizontally scale, and the growth forecast requires 5× throughput within 18 months" is context.

Cost of latency if this decision is deferred 1 week

Hard deadline for decision

Section 3: Decision

State the decision in a single, unambiguous sentence beginning with an active verb. "We will…", not "we should consider…" or "it is recommended that…"

Section 4: Alternatives Considered

For each alternative, state it clearly, explain why it was considered seriously, and state the specific constraint that ruled it out. "Not a good fit" is not a reason. "Exceeds the CFO's $2M capital ceiling for Year 1" is a reason.

Alternative	Why it was considered	Why it was ruled out (specific constraint)

Section 5: Decision Drivers

List the specific, verifiable constraints that made this the correct decision. Distinguish between verified constraints (confirmed by evidence) and assumptions (not yet confirmed). Assumptions must be flagged: an ADR built on unverified assumptions is fragile.

Decision Driver	Verified or Assumption?	Evidence / Source

Section 6: Consequences

What does this decision commit the organization to? List both the positive consequences (what it enables) and the negative consequences (what it forecloses, what it will cost, what risks it introduces). Honest ADRs include both.

Positive consequences (what this enables)

Negative consequences / trade-offs accepted

Section 7: Compliance Path

What signal would indicate that this decision should be revisited? Name the specific condition, not "if things change," but "if the transaction volume exceeds 50,000/sec" or "if the regulatory framework changes to require data residency in a specific jurisdiction." This is the mechanism that prevents ADRs from becoming permanent constraints that outlive their original rationale.

Review trigger owner (who watches for this signal)

Scheduled review date (if time-based)

Section 8: Stakeholder Sign-Off

Stakeholder	Role	Consulted or Informed?	Agreed? (Y/N/Conditional)	Condition (if applicable)

ADR Quality Checklist

Decision title is unambiguous: one sentence, active verb
Context names a specific constraint, not a generic challenge
At least two alternatives considered and ruled out with specific reasons
Every decision driver is labeled as verified or assumption
Consequences include both positive and negative
Compliance path names a specific, observable trigger, not "if things change"
A future architect who was not in the room can understand why NOT to change this decision without good reason