Architecture decisions become difficult for an interesting reason: the technology is often the easy part.

The harder work is deciding which qualities matter most, which constraints are real, what uncertainty can be tolerated, and what the organization is willing to pay for over time.

A useful architecture process therefore needs to do more than compare products. It should make the decision logic visible.

The Core Idea

For consequential decisions, move through six questions in order:

  1. What decision are we actually making?
  2. What forces shape the decision?
  3. Which options are genuinely viable?
  4. What trade-offs distinguish them?
  5. What evidence would change the choice?
  6. When should we revisit the decision?

This sounds simple. The discipline comes from refusing to jump directly from a problem statement to a preferred technology.

1. Define the Decision, Not the Solution

Weak decision statement: Should we use Kafka?

Stronger decision statement: How should services exchange high-volume domain events when consumers need independent scaling, replay, and failure isolation?

The second statement leaves room for alternatives and makes the architectural need visible.

A good decision statement should specify the scope, the actors affected, and the outcome required without embedding the answer.

2. Separate Constraints From Preferences

Teams frequently treat preferences as if they were constraints. “We already use product X” can matter, but it is not the same kind of force as a regulatory obligation, latency requirement, data-residency rule, or hard budget limit.

Classify forces explicitly:

  • Hard constraints: conditions an option must satisfy.
  • Quality attributes: reliability, security, performance, operability, evolvability, cost, and similar concerns.
  • Organizational forces: skills, support model, ownership, standardization, procurement, and migration capacity.
  • Preferences: familiarity, elegance, ecosystem preference, or strategic direction that can be challenged.

If everything is marked “must have,” the framework is not helping. Architecture is the act of making priorities explicit.

3. Keep the Option Set Small and Real

A decision record does not become stronger because it lists eight products. Usually two to four viable options are enough.

Include the status quo when it is genuinely viable. “Do nothing yet” is often an important option because migration and organizational change have costs.

Remove options that fail hard constraints before detailed scoring. There is little value in debating a technically attractive option that cannot legally, operationally, or economically be adopted.

4. Compare Trade-offs, Not Features

Feature matrices tend to reward products with the longest feature list. Architecture decisions need a different question: what consequence does each option create for the qualities we care about?

For each viable option, record:

  • what becomes easier,
  • what becomes harder,
  • what new failure modes appear,
  • what operational capability is required,
  • what becomes difficult to reverse, and
  • what cost moves from today into the future.

This is where a good architecture discussion becomes useful. The question is rarely “which option has no downside?” It is “which downside are we intentionally accepting?”

5. Score Carefully

Weighted scoring can help when the team needs a shared view across several qualities, but the score should support judgment rather than replace it.

A practical scale is 1–5 for each decision force:

  • 1: poor fit or significant downside
  • 3: acceptable with meaningful trade-offs
  • 5: strong fit with manageable downside

Weight only the factors that truly differ in importance. If every factor receives nearly the same weight, simply discuss them qualitatively.

Most importantly, attach a short reason to every meaningful score. A naked number hides disagreement.

6. Make Uncertainty First-Class

Architecture teams sometimes disguise uncertainty as confidence. A better record says what is known, what is assumed, and what needs evidence.

Examples:

  • We have not validated throughput above the expected three-year peak.
  • The operating team has limited experience with this technology.
  • Vendor pricing after the first committed tier is uncertain.
  • The migration estimate assumes consumers can move independently.

An assumption that could reverse the decision should become an experiment, spike, benchmark, or explicit follow-up action.

7. Record Reversibility

Not every decision deserves the same process.

A decision is more consequential when it has a large blast radius, high switching cost, irreversible data or protocol effects, or creates a long-lived organizational dependency.

Use more rigor for decisions that are:

  • expensive to reverse,
  • shared by many teams,
  • security or compliance sensitive,
  • likely to shape several years of delivery, or
  • difficult to test safely after adoption.

Small reversible decisions should remain local. Architecture governance becomes harmful when every implementation choice requires the same ceremony.

8. Decide Who Owns the Decision

Architecture works better when decision rights are explicit.

A domain team may own a local implementation choice. A platform team may own the contract of a shared capability. An enterprise architecture group may define cross-enterprise constraints or standards. These are different responsibilities.

The decision record should name:

  • Decision owner — accountable for the choice.
  • Contributors — people supplying expertise or evidence.
  • Affected teams — people who must live with the consequence.
  • Approver, if needed — only where governance genuinely requires one.

Consensus can be useful, but unclear ownership should not be mistaken for collaboration.

9. Write the Decision in One Sentence

After the analysis, the decision should be explainable without reopening the whole meeting.

A useful format is:

We will use [option] for [scope] because [primary reasons], accepting [important trade-off].

If that sentence is difficult to write, the team may not yet agree on why the option won.

10. Record What Would Cause Reconsideration

An ADR should not become a historical tombstone. Record explicit triggers that would cause the decision to be revisited.

Examples include:

  • transaction volume exceeds the validated operating envelope,
  • the chosen service changes pricing materially,
  • a new regulatory constraint appears,
  • operational burden exceeds an agreed threshold, or
  • a strategic platform capability becomes available that removes the original constraint.

This turns “architecture is evolutionary” into something operational.

A Compact Decision Flow

Decision question
      ↓
Hard constraints
      ↓
Decision forces + priorities
      ↓
2–4 viable options
      ↓
Trade-offs + uncertainty
      ↓
Evidence / spike where needed
      ↓
Decision + owner
      ↓
Consequences + revisit triggers

Common Failure Modes

  • Technology-first framing: starting with a favored product and constructing criteria afterward.
  • False precision: producing a weighted score of 4.37 when the underlying estimates are mostly subjective.
  • Architecture by committee: requiring broad consensus without naming who owns the decision.
  • Ignoring operations: evaluating build-time capability while excluding support, failure recovery, upgrades, and ownership.
  • Ignoring migration: comparing ideal end states while treating transition cost as somebody else's problem.
  • Permanent standards: recording a decision but not the conditions under which it should be revisited.

Use the Interactive Decision Aid

The accompanying tool helps structure a real decision, compare up to three options, and surface whether your choice is being driven by evidence or assumptions.

Open the Architecture Decision Aid →

Download the Template

Download the reusable Architecture Decision Record template

Explore this topic

Part of the Architecture Practice topic collection.