Skip to content
Software Architecture Guide

Architectural Decision Definition of Ready

Explanation

Section titled “Explanation”

The checklist is modeled on the agile Definition of Ready. In agile work, that concept helps people avoid misunderstandings about how mature an item is. The same idea applies to architectural decisions (see Architectural Decision).

Before making a decision, the team checks five ready-to-START criteria:

  1. Stakeholders. The people involved in the decision are known. A RACI matrix can group them as Responsible, Accountable, Consulted and Informed (see RACI Matrix).
  2. Time. The decision is taken at its most responsible moment. Hitting that moment is important.
  3. Alternatives. The team has options to compare. The companion Definition of Done asks for at least two alternatives, compared by stakeholder concerns.
  4. Requirements. Requirements and decision drivers are identified and drafted. Ideally they are SMART (see SMART Requirements). An architectural significance test can score which decisions are significant.
  5. Template. An ADR template has been chosen and validated, for instance in a trial. It can come from the community or be your own (see Architectural Decision Record).

Passing the START gate does not make a decision done. Feature-oriented readiness and done checklists do not check decisions. So a separate Definition of Done for decisions exists. Its name is ecADR, and it has five criteria: evidence, criteria, agreement, documentation, and realization/review. It asks the team to capture the decision in a lean template such as a Y-statement or MADR. See Definition of Done for Architectural Decisions.

Example

Section titled “Example”

A team must choose how two systems exchange data. Before the decision meeting, they walk through the checklist. They list who is affected and who must approve. They write down two options. They draft the requirements that matter. They pick an ADR template and try it on a small decision. One item is missing: nobody has drafted the requirements. The team postpones the meeting until that is done.

Trade-offs

Section titled “Trade-offs”

The checklist adds a small step before each decision. The facts do not say how heavy this step is, so teams should judge how strictly to apply it. Requirements only need to be identified and drafted, not perfect. Passing the gate does not finish the work: the decision still needs the Definition of Done.

The five START criteria as a gate before a decision, followed by the Definition of Done.

Diagram source 
flowchart LR
  S[Stakeholders] --> T[Time]
  T --> A[Alternatives]
  A --> R[Requirements]
  R --> M[Template]
  M --> D{All five met?}
  D -- yes --> X[Make the decision]
  D -- no --> W[Close the gap first]
  X --> F[Check Definition of Done]

Checks

Section titled “Checks”
  • The record shows that the stakeholders of the decision were identified, for example in a RACI matrix.
  • The decision requirements and drivers are at least identified and drafted, ideally in SMART form.
  • An ADR template was chosen and validated before the decision was recorded.
  • A decision that passed the START gate is not marked done until the Definition of Done is met.
Section titled “Related”

Sources

Section titled “Sources”