methodatlas
Playbook

Prepare Architecture Decision

Move from a fuzzy technical problem to a documented, traceable architecture decision.

Outcome

An accepted ADR with clear context, evaluated options, trade-offs, and follow-up actions.

At the end you have

Decision FrameOption FramesTrade-off MatrixADR

Decision point

You can decide which architecture option is chosen, which downsides are consciously accepted, and who owns implementation.

Next step

Review the ADR, anchor it in the architecture repository, and move follow-up actions into backlog or roadmap.

Ideal for

  • Platform and architecture questions
  • Technical decisions that are hard to reverse
  • Teams with multiple stakeholders

Not good for

  • Trivial local implementation details
  • Decisions without real alternatives
Preparation

What should be clear before you start

Roles

  • Decider or architecture owner
  • Affected delivery team
  • Stakeholders from operations, security, or product

Inputs

  • Concrete decision question
  • Known constraints and quality requirements
  • Initial solution options or technical sketches

Setup

  • Clarify decision frame and time horizon
  • Collect relevant evidence upfront
  • Define ADR location and review group
Flow

Method path

0 methods
    Completion criteria
    Templates

    Artifacts for this playbook

    Artifacts stay collapsed until you actually need them.

    MarkdownShow template

    Decision Frame

    Template for turning an unclear decision into a question, roles, options, and evidence needs.

    # Decision Frame: Topic

## Decision question

What decision needs to be made now?

## Context

Why is the decision needed, what happens without it?

## Decider and roles

- Decider:
- Input:
- Reviewer:
- Informed:

## Options

1. ...
2. ...
3. ...

## Criteria

- ...

## Constraints

- ...

## Evidence needed

What data, tests, or reviews are still missing?

## Next step

Owner, date, format.
    MarkdownShow template

    Option Frame

    Standardized description of action options so they can be compared fairly.

    # Option Frame: Option Title

## Short description

What is the option in one sentence?

## Scope

What is included, and what is explicitly excluded?

## Benefit

Which goal does this option support?

## Cost and effort

Which resources, duration, and dependencies does it create?

## Risks

Which negative consequences or open points remain?

## Assumptions

Which prerequisites need to be true?

## Decision signal

How do we know this option should be preferred?
    MarkdownShow template

    Trade-off Matrix

    Markdown matrix for comparing options across competing criteria and accepted trade-offs.

    # Trade-off Matrix: Decision

| Criterion | Weight | Option A | Option B | Option C |
|---|---:|---|---|---|
| Benefit | 30 | | | |
| Cost | 20 | | | |
| Risk | 20 | | | |
| Time-to-Learn | 15 | | | |
| Reversibility | 15 | | | |

## Accepted trade-offs

- Option A accepts:
- Option B accepts:
- Option C accepts:

## Recommendation

Which option is recommended and why?

## Sensitivity

Which small change in weighting or assumption would flip the recommendation?
    MarkdownShow template

    ADR Markdown Template

    Compact template for architecture decision records in a repository or wiki.

    # ADR-0001: Decision Title

**Status:** proposed
**Date:** YYYY-MM-DD
**Decider:** First Last
**Trigger:** Ticket, incident, or RFC

## Context

What situation makes the decision necessary? Which constraints, quality attributes, or earlier decisions matter?

## Options

### Option 1: ...
- Pros:
- Cons:

### Option 2: ...
- Pros:
- Cons:

## Decision

We decide to ...

## Consequences

Positive consequences:
- ...

Negative consequences and risks:
- ...

Follow-up ADRs or tickets:
- ...