Pierre Pureur and Kurt Bittner’s article on software architecture deserves explicit credit for shifting attention from boxes and structures to decisions. Their argument also places architecting in the development team rather than in a detached role that produces diagrams for others to implement.
That framing is stronger than defining architecture as a catalogue of components. It can be made more operational by asking why some decisions are architectural while thousands of other design choices are not.
A decision becomes architectural when it materially constrains future change: reversing it is expensive, its effects cross boundaries, or evidence about its quality arrives only after significant commitment.
Structure is evidence of decisions, not the whole architecture
A system diagram may show services, databases, queues, clients, and trust zones. It usually does not explain why those boundaries exist, which alternatives were rejected, or what must remain true when the implementation evolves.
Two systems can have similar diagrams and very different architectures. One service boundary may isolate regulatory data; another may only reflect an old team chart. One queue may be essential for absorbing load; another may be accidental complexity. The visible structure records consequences of decisions but not their full rationale or force.
This explains why copying a reference architecture is risky. The copied boxes arrive without the constraints that made them reasonable. A pattern name can describe a solution shape; it cannot decide whether the local problem justifies its coordination, latency, consistency, and operational costs.
Four properties make a decision architectural
The boundary is gradual, but four properties are especially useful:
| Property | Architectural question |
|---|---|
| Reversal cost | How much data migration, retraining, downtime, or rewriting would reversal require? |
| Blast radius | How many components, teams, users, or controls depend on the decision? |
| Evidence delay | How late will scalability, operability, security, or maintainability consequences become visible? |
| Coordination load | How many independent actors must agree and move together to change it safely? |
A local variable name usually scores low on all four. A data ownership boundary, public protocol, identity model, consistency guarantee, or deployment topology can score high. Programming language choice may be local in a small replaceable utility and architectural in a platform whose skills, libraries, and runtime become organization-wide commitments.
This test also prevents “architecture” from becoming a synonym for “important.” A business rule can be important while remaining easy to change in one module. A seemingly mundane identifier format can be architectural when it leaks into databases, APIs, logs, and partner integrations.
Decisions need falsifiable consequences
An architecture decision record is useful only if it preserves more than preference. A reviewable decision should state:
- the problem and forces present at the time;
- the chosen option and meaningful alternatives;
- assumptions on which the choice depends;
- expected benefits and accepted liabilities;
- boundaries and invariants the implementation must preserve;
- evidence that would support or weaken the decision;
- conditions under which it should be revisited.
This turns rationale into a testable claim. “Use asynchronous messaging for scalability” is too vague. A better record names the expected workload, permitted delivery semantics, ordering requirements, failure handling, and the measurements that will show whether the added complexity is justified.
The record need not predict the future perfectly. Its purpose is to make later change more informed. When an assumption fails, the team can distinguish a decision that was reasonable under old evidence from one that was never supported.
Architecture should be executable where possible
If architecture is made of consequential decisions, some of their constraints can be checked continuously:
- dependency rules can prevent forbidden module coupling;
- contract tests can preserve public interface expectations;
- policy checks can enforce identity and data boundaries;
- fitness functions can watch latency, resilience, or deployment properties;
- migration tests can validate compatibility across schema versions;
- threat models can generate security tests for trust-boundary violations;
- observability can reveal whether assumed failure isolation exists in operation.
These checks do not replace architectural judgment. They keep implemented structure from silently diverging from accepted decisions. They also make architecture visible to developers in the ordinary delivery loop rather than only during periodic review.
The strongest constraints should be enforced closest to the mechanism they govern. A prose rule that one service must not read another service’s database is weaker than network, identity, and ownership controls that make the prohibited path unavailable. Documentation explains the decision; enforcement preserves it.
Architecting is distributed, but responsibility cannot be vague
Pureur and Bittner are right that architecture cannot be handed off to a committee disconnected from implementation. Developers discover constraints and consequences while building and operating the system. Architectural knowledge must therefore live within teams.
Distributed architecting does not mean that nobody owns cross-cutting decisions. A local team may optimize its component while transferring cost to security, operations, data governance, or other services. Decisions with a broad blast radius need an explicit forum, named participants, and a record of dissent and uncertainty.
The architect’s useful function is not to monopolize diagrams. It is to improve decision quality: expose hidden constraints, connect affected groups, demand evidence proportional to commitment, and ensure that accepted boundaries remain testable. Depending on scale, that function may be performed by senior engineers, a rotating group, or a dedicated role that remains close to implementation.
Architecture is a portfolio of commitments
Not every decision should be made early. Where reversal is cheap, experimentation is better than speculation. Where evidence arrives quickly, the system can evolve through measured feedback. Architectural effort should concentrate on commitments that are expensive to undo and uncertainty that becomes dangerous after scale.
This produces a practical rule:
- identify decisions with high reversal cost or blast radius;
- make their assumptions and consequences explicit;
- defer commitment when a cheap experiment can produce better evidence;
- enforce the chosen invariants in code, infrastructure, and tests;
- revisit the decision when its recorded assumptions change.
The article by Pureur and Bittner correctly rejects architecture as static structure drawn by a separate class of people. The deeper implication is that architecture is the managed portfolio of decisions that shape the cost and safety of future change. Diagrams remain useful, but only as maps. The architecture lives in the commitments, the evidence behind them, and the mechanisms that keep them honest.