Architectural Significance
also called Architecturally Significant Decision, Significance Test
The test that separates decisions worth reviewing from the ones a team should make alone, by asking what undoing each one would cost rather than how technical it sounds.
A platform team spends two weeks choosing an HTTP client library. In the same fortnight a new service ships writing directly to the orders table another team owns, because that was the quickest way to read a customer's history. The library is reversible in an afternoon with a find-and-replace. The shared write is a constraint every future change to orders must respect, and removing it means a read API, a backfill, and a release coordinated across two teams.
Attention went to the loud decision instead of the expensive one. Teams argue about decisions that are easy to have an opinion about, while the decisions that bind the future are the invisible ones: an identifier format, where the tenant id lives, which service owns a write.
Architectural significance is the test that sorts the two, and the test is not "is it technical" but "what does undoing it cost, and whose code does it constrain".
Why it matters
Review capacity is the scarcest thing an architecture function has. A team that reviews everything builds a queue, and the queue teaches engineers to route around review. A team that reviews nothing finds its data model was set by the first pull request.
Reversal cost is the right sorting rule because it is what a decision imposes on the future. A choice one engineer can undo in a day is a preference. A choice whose reversal needs a data migration, a deprecation window for external callers, or a release coordinated across teams is a constraint, and constraints are worth an hour of senior attention now instead of a quarter of work later.
Implementation patterns
- Write the reversal plan beside the decision. An entry saying "undoing this rewrites 40M rows and gives partners 90 days' notice" ends the argument.
- Apply two questions. Does it constrain choices another team will have to make? Does undoing it need a data migration or a coordinated release? One yes makes it significant; two makes it worth a written record.
- Publish the boundary. What teams decide alone (libraries, internal structure, test tooling) and what needs a second reader (data ownership, identifiers, tenancy, the authorisation model, anything with an external consumer).
- Decide early where reversal is expensive and late everywhere else. Identifier format and write ownership are cheap on day one and brutal in year three; a library choice can wait.
Industry example
ISO/IEC/IEEE 42010:2011 defines a system's architecture as the fundamental concepts or properties of a system in its environment, embodied in its elements, relationships, and the principles of its design and evolution. The load-bearing word is fundamental: what is essential about a system, not everything about it.
Martin Fowler's 2003 IEEE Software essay "Who Needs an Architect?" lands somewhere less comfortable: significance is whatever the expert developers on a system consider significant. That is a social definition, which is why reversal cost matters: it is the part of the judgement you can write down and argue about.
Failure scenarios
- Everything is architectural. The board takes 40 designs a quarter, perhaps six with an irreversible decision in them, and the lead time on the other 34 teaches teams to present after shipping.
- Nothing is architectural. The symptom arrives during an incident: two services writing the same rows.
- The record without the cost. A decision log missing the reversal field, so the next team relitigates the choice from scratch.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Narrow definition (irreversible only) | Fast reviews, high signal, teams keep autonomy | Misses slow accumulation: a library that becomes load-bearing one team at a time |
| Broad definition (anything cross-cutting) | Consistency, fewer surprises | A queue, a routed-around process, senior time spent on preferences |
Narrow is the better default, with the cheap-but-accumulating class reviewed on a cadence instead.
When not to use it
One team, one deployable, no external consumers: the architecture is the code, reversal costs a sprint, and significance criteria for a three-month experiment are overhead with no payer. Keep a decision log if it helps you remember, and skip the process around it.
It flips the first time a second team changes the same code, a consumer outside your release cycle depends on your interface, or a datum arrives that regulation says you must control. Each converts cheap reversal into coordinated reversal.
Interview question
Q: You join a 60-engineer company with no architecture review and a mandate to add one. What goes on the list of decisions that need review, and how do you stop the list swallowing everything?
What a strong answer covers: reversal cost as the sorting rule rather than seniority or technical depth; the short list most products need first (write ownership, identifier and tenancy design, the external contract, the authorisation model); what teams explicitly keep; and a measure of review lead time, because a review that adds days gets bypassed.
Quick check
Quiz: A logging library standard and a second service writing to the orders table land the same week. Which is architecturally significant? — The shared write: undoing it needs a read API, a backfill and a release coordinated across two teams, while the library is a find-and-replace.
Flashcard: What single question sorts architectural decisions from ordinary ones? — What would undoing this cost, and who would have to be involved.