skip to content

Architecturally Significant Decisions

9 roadmaps6 questions

Not every decision is architectural: the ones that are have a high cost of change, cross many components, or move a quality attribute. You will learn to identify architecturally significant requirements and to delay a decision to the last responsible moment without drifting.

part ofSoftware design & architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

6

What makes a design decision architecturally significant rather than a routine implementation choice?

level: juniorimportance: must knowfreq 75%

answer

  1. hard to change later
  2. cost of change = significance
  3. broad impact, crosses boundaries
  4. moves a quality attribute
  5. context-dependent, not absolute

basics

~20 s

A decision is architecturally significant when it is expensive to change later, affects many parts of the system or many teams, and drives qualities such as performance, security or availability. Routine choices are local and cheap to reverse.

solid answer

~40 s

Three tests settle it. (1) Cost of change: reversing it later means touching many modules, migrating data, retraining teams or renegotiating contracts. (2) Breadth of impact: it crosses component, team or deployment boundaries and becomes an assumption others build on, constraining later decisions. (3) Quality-attribute sensitivity: it materially moves a non-functional property (latency, availability, scalability, security, modifiability, cost), not just behaviour. Integration style (events vs request/response), consistency model, service decomposition, persistence technology and public contract shape are architectural. A loop construct, a variable name or a sorting algorithm inside one class is not. Significance is contextual and time-varying: the same decision can be architectural in a large system and trivial in a prototype. Mature architecture work deliberately shrinks the significant set by making change cheaper.

go deeper

for a junior

State the two headline tests: hard/expensive to change, and affects many parts of the system. Give one concrete example (database choice, sync vs async integration) and one counterexample (naming, a local algorithm).

for a middle

Add quality-attribute sensitivity as the third test and explain that architectural decisions become constraints on later decisions. Show you can classify concrete decisions and justify the classification.

for a senior

Emphasise that significance is contextual and time-varying, tie it to cost of reversal and blast radius, and mention deliberately reducing significance via abstraction, contract tests and automation. Reference recording decisions as ADRs.

for a principal

Frame it as governance economics: the significant set defines where scarce review attention goes. Discuss organisational coupling (Conway's law), how to keep the set small, and how fitness functions and platform investment convert one-way doors into two-way doors.

## The core idea A system involves thousands of decisions; only a small fraction deserve architectural attention. Those are the **architecturally significant decisions**. A widely used definition (Grady Booch) says architecture is the set of significant design decisions, where **significance is measured by the cost of changing them**. Martin Fowler's shorthand is similar: architecture is the stuff that is hard to change later. ## Three practical tests **1. Cost of change (irreversibility).** Ask: if we discovered in six months this was wrong, what would it cost to undo? If the answer involves data migration, coordinated releases across teams, re-signing vendor contracts, retraining, or client-visible breaking changes, it is architectural. If one developer can change it in an afternoon inside one module, it is not. **2. Breadth of impact (structural reach).** Architectural decisions become **constraints** that later decisions must obey. Choosing asynchronous messaging between two services forces every caller to handle eventual delivery, retries, ordering and duplicate messages. That single choice propagates into dozens of local designs. A decision confined behind one interface, invisible to callers, is local. **3. Quality-attribute sensitivity.** **Quality attributes** (also called non-functional requirements) are measurable system properties: latency, throughput, availability, durability, security, modifiability, testability, operability, cost. If varying the decision measurably moves one of these, it is architectural. Functional requirements can usually be satisfied by many architectures; quality attributes are what discriminate between them. ## Additional signals - **Hard to discover later**: the decision is implicit in dozens of places and has no single owner. - **Cross-cutting**: authentication, tenancy model, error/retry semantics, time and identity handling. - **Externally visible contract**: public API shape, event schema, URL structure, wire compatibility rules. - **Organisational coupling**: it fixes which team owns what, so changing it means reorganising people (Conway's law). ## Edge cases and nuance - **Significance is contextual.** "Which database" is architectural for a system with 5 TB and strict availability targets; for a throwaway internal tool it is a detail. - **Significance decays and appears.** A decision can stop being significant once change becomes cheap (good abstraction, automated migration), and a formerly trivial choice can become significant once ten teams depend on it. - **Significant is not the same as big or expensive to build.** A one-line choice ("IDs are opaque UUIDs, not sequential integers") can be deeply architectural; a six-month feature can be architecturally boring. - **The best architectural move is often to reduce significance** — hide the decision behind an interface, add an anti-corruption layer, keep the choice deferrable — so a wrong answer stays cheap. ## How to use it in practice Maintain an explicit list of the significant decisions (commonly as Architecture Decision Records: short documents capturing context, decision and consequences). Everything on that list gets analysis and review; everything else is delegated to the team building it. That is what stops architecture from becoming either bureaucratic (reviewing everything) or absent (reviewing nothing).

  • Give an example of a decision that looks trivial but is architecturally significant.
    Identifier strategy. Choosing sequential integer IDs instead of opaque globally unique IDs quietly fixes sharding options, cross-system merges, offline ID generation, and leaks record counts to clients. Reversing it later means migrating every stored key and every external reference.
  • Can a decision stop being architecturally significant?
    Yes. If you invest in making change cheap — an abstraction layer, automated data migration, contract tests, deployment automation — the cost of reversal drops and the decision leaves the significant set. Deliberately doing this is a hallmark of evolutionary architecture.

Rearranging furniture versus moving a load-bearing wall. Both change the room; only one needs an engineer, a permit and a budget — because only one is expensive and risky to undo.

saying these in an interview costs you the question

  • Claiming significance is an absolute property of a decision rather than relative to context, scale and organisation
  • Equating architectural with technology choices only ('the framework is the architecture')
  • Treating anything expensive or time-consuming to build as architectural, regardless of reversibility
  • Assuming functional requirements drive architecture, when quality attributes are the discriminator
  • Believing more decisions should be escalated to architects — the goal is to shrink, not grow, the significant set

context

resolving links…

open as a page

How do you identify architecturally significant requirements (ASRs) from a large backlog of requirements and stakeholder statements?

level: middleimportance: must knowfreq 65%

basics

~20 s

Look past feature lists for requirements that constrain structure: measurable quality goals (latency, uptime, scale, security), hard constraints (regulation, deadlines, existing systems), and the few features that touch everything. Turn vague wishes into testable scenarios, then prioritise by business value and technical difficulty.

open as a page

How should the reversibility of a decision change the process and rigour you apply to making it?

level: seniorimportance: must knowfreq 60%

basics

~20 s

Classify decisions by how hard they are to undo. Hard-to-undo ones deserve analysis, prototypes, review and a written record. Easy-to-undo ones should be made quickly by the team and corrected from real feedback, because deliberating costs more than being wrong.

open as a page

What is the last responsible moment heuristic for architectural decisions, and how do you know a decision has reached it?

level: middleimportance: should knowfreq 55%

basics

~20 s

Delay a hard-to-reverse decision until the point where delaying further would eliminate an important option or start blocking work. Waiting buys information; waiting too long means the choice gets made by accident or by default.

open as a page

What are sensitivity points and trade-off points in an architecture, and why do they matter when evaluating a significant decision?

level: seniorimportance: should knowfreq 45%

basics

~20 s

A sensitivity point is a decision where changing it noticeably moves one quality attribute, such as response time. A trade-off point is a decision that moves two or more quality attributes in opposite directions, so you must consciously choose which one to favour.

open as a page

How do you record and govern architecturally significant decisions so they remain useful and revisitable years later?

level: principalimportance: should knowfreq 40%

basics

~20 s

Write a short record for each significant decision: the context, the options, the choice, and the consequences. Keep records immutable, append new ones that supersede old ones, store them beside the code, and note the assumptions that would trigger a revisit.

open as a page