---
title: "Architecture roadmap: from purpose to running evidence"
chapter: "00"
---

# Architecture roadmap: from purpose to running evidence

Architecture is the set of important structures and decisions that shape a system. It connects stakeholder outcomes to boundaries, interactions, data, deployment, quality attributes, and evolution. A diagram alone is not an architecture.

## Core ideas and patterns

| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| **Purpose** | Defines the outcome and value the system must create | A vague purpose makes every later choice arbitrary |
| **Context** | Shows people, external systems, laws, and physical environment | Missing context hides dependencies and trust boundaries |
| **Quality attributes** | Make speed, safety, reliability, changeability, and cost measurable | Words such as scalable or secure are not testable |
| **Structures** | Describe modules, runtime processes, data, and deployment | One view cannot answer every stakeholder question |
| **Decisions** | Record consequential choices and rejected alternatives | A decision without forces and consequences becomes dogma |
| **Evidence** | Connects design claims to tests, telemetry, exercises, and review | Architecture drifts when evidence is not automated |

## How to apply it

Start with a one-page architecture brief: mission, users, business capabilities, constraints, top risks, quality-attribute scenarios, system context, data sensitivity, and explicit non-goals. Generate two or three viable options. Compare them against the same scenarios. Choose the smallest option that satisfies the evidence thresholds. Record the decision and a date or signal that will trigger reconsideration.

## Evidence, not opinion

A useful architecture package contains a context view, major runtime and data flows, deployment/failure domains, ADRs, threat model, capacity model, service objectives, ownership map, and executable checks. Review it when the code, topology, risk, regulation, workload, or team boundaries change.

## Small example

A ticket marketplace needs buyers to see purchases within two seconds and must never sell one seat twice. Those two scenarios drive consistency boundaries, reservation expiry, idempotency, partition ownership, and operational alarms before any framework is selected.

## Feynman check

Explain the design to a new engineer without using the pattern names. State the
problem, the forces that conflict, the chosen boundary or mechanism, what can
fail, and the evidence that would prove the choice still works.