Skip to content

A Repeatable Design Process

Everything in this module so far was a decision you made. That is how architecture starts in a company with no practice, and it is a trap: if good decisions only happen when you are in the room, you have made yourself a dependency rather than built a capability.

This topic writes the process down. It is deliberately boring, which is the property that makes it usable by someone who is not you.

graph TD
  A["<b>1 · Frame</b><br/>state the problem as a question<br/>with a driver attached"] --> B["<b>2 · Constrain</b><br/>list what is already decided,<br/>before any option exists"]
  B --> C["<b>3 · Generate</b><br/>at least three options,<br/>including the boring one"]
  C --> D["<b>4 · Evaluate</b><br/>against fixed criteria<br/>from the ASRs"]
  D --> E["<b>5 · Decide</b><br/>named decider,<br/>named date"]
  E --> F["<b>6 · Record</b><br/>decision, reasoning,<br/>consequences, rejected options"]
  D -.->|"no option<br/>is acceptable"| C

  classDef plain fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef skipped fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  class A,B,D,E plain
  class C,F skipped

Six steps, with one loop. The amber pair are the two that get skipped under deadline pressure, and skipping either is what makes a decision impossible to defend later.

1 · Frame. Write the problem as a question, with the business driver attached. “How do we answer documented questions without a human, at a cost per interaction under the ceiling?” — not “design a RAG system”. Skip it and: you solve the wrong problem competently. This is the most expensive failure available and the hardest to spot, because the work looks excellent throughout.

2 · Constrain. List what is already decided: regulatory boundaries, the existing estate, the deadline, the capacity. Before any option exists. Skip it and: a constraint surfaces after a design exists, and you discover that the elegant answer is illegal. Constraints found late remove work already done; found early, they remove only options.

3 · Generate. At least three options. Include the boring one — the simplest thing that could work — and include doing nothing, properly costed. Skip it and: you present one option, which reads as inevitability rather than judgement, and nobody believes it. One option is also how confirmation bias becomes invisible: with nothing to compare against, the single option always looks adequate.

4 · Evaluate. Score the survivors against criteria fixed in advance, drawn from the ASRs and weighted by the Utility Tree. Constraints veto; requirements score. Skip it and: you rationalise. The criteria quietly bend until your preference wins, and everyone can feel it even if nobody can point at it.

5 · Decide. Name who decides and by when. Most architectural decisions are not yours alone — a cost ceiling belongs to whoever holds the budget, a compliance boundary to whoever can block. Skip it and: decision by exhaustion. The option still standing when everyone gets tired wins, and nobody owns it.

6 · Record. The decision, the reasoning, the consequences including the bad ones, and the options you rejected with why. Skip it and: the same debate reopens in nine months with new people, and you have nothing but memory. Module 9 builds this into an ADR practice; here it is simply the last step you do not skip.

Three compounding effects, none of which comes from the quality of any single decision.

It survives you. A process written down can be run by a tech lead on a decision you never hear about, which is the only way architectural thinking scales past one person in a 140-engineer company.

It makes your reasoning auditable, which is the mechanism by which an architect with no authority accumulates trust — Module 8’s subject, and it depends entirely on there being a visible process to point at.

It makes disagreement productive. Someone who disputes your conclusion can attack a specific step: the framing, a missing option, a criterion weight. That is a much better conversation than a general objection to your judgement, and it is only available if the steps are visible.

Six steps on every decision would stop the company. Triage in one line:

Run the full process when the decision is expensive to reverse, crosses teams, or spends someone else’s budget. Otherwise, frame it, pick, and move on.

That is Module 1’s definition of architecture doing practical work: the process applies to architectural decisions, not to all decisions. Applying it to a library choice inside one component is how an architecture practice earns the reputation it then spends years escaping.

The honest cost of the process even when correctly scoped: it is slower than deciding, and in the early weeks it will make you look indecisive to people who expected answers. The defence is to be fast at steps 1–3 — a framing and three options can take an afternoon — and to never skip step 6, because step 6 is what makes the next decision faster.

The rubric asks for the design process written down as steps you could hand to someone else. Write yours in your own words, with your own triage rule — and then check it against the decision you actually made in the trade-off table. If your real decision skipped a step, either the step is wrong or the decision needs revisiting.


→ Step 3 says generate options. With what knowledge, if not a memorised catalog of technologies? — Criteria catalogs and scale calibration