Making — and Defending — Architecture Decisions at Scale
The core skill that defines the role: making reversible-vs-irreversible calls under uncertainty and getting an org to commit.
Most architecture decisions fail not because they were wrong at the time, but because the context was never documented and the assumptions were forgotten before anyone challenged the decision. Here is how to decide under real uncertainty, get organizational buy-in, and defend the original reasoning when the challenge comes — because it will.
The decision itself is the easy part. You gather options, evaluate trade-offs, pick the one that best fits your constraints. The hard part is everything after: getting the organization to commit, keeping teams aligned while they build against it, and defending the original reasoning two years later when someone asks why the system looks the way it does.
Reversible vs. Irreversible: The Only Taxonomy That Matters
Jeff Bezos articulated the most useful framing for architectural decisions: one-way doors and two-way doors. Two-way door decisions are reversible — you can walk through, look around, and walk back out if the room is wrong. One-way door decisions are not — once made, unwinding them costs months or years.
The failure mode in engineering organizations is treating one-way doors like two-way doors. A team moves fast, picks a data store because it solved the immediate problem, and ships. Eighteen months later that data store is embedded in eleven services and the migration cost is prohibitive. The decision was made in two days without the framing it deserved.
Practical test: if you had to reverse this decision in six months, what would it cost? If the answer is "a rewrite" or "a two-month migration," it is a one-way door. Treat it accordingly — slower process, explicit documentation, explicit sign-off from affected teams.
Two-way door examples: framework choice for a new service, REST vs. gRPC for a new API, caching strategy for a single service. One-way door examples: shared database schema between services, event streaming platform for the entire org, authentication model.
Deciding Under Uncertainty Without Paralysis
Perfect information is not available. Architects who wait for it make delays, not decisions. The discipline is distinguishing between uncertainty that should delay a decision and uncertainty that just feels uncomfortable.
Uncertainty that justifies delay: you do not know the expected traffic pattern, and the two viable architectures diverge at 10x the current load. Run the experiment. Uncertainty that does not justify delay: you do not know whether the team will prefer gRPC or REST. Pick one, document the reasoning, revisit at the six-month checkpoint.
The process I have used across organizations:
- Name the decision clearly. One sentence. What specifically is being decided.
- List the options. Usually two to four. More than four is still research, not decision-making.
- State the constraints that are non-negotiable. Latency budget, team operational capability, compliance requirements. These are the filters.
- State the assumptions you are making. These are the risks. If an assumption is wrong, the decision may need to revisit.
- Pick the option that best satisfies the constraints given the assumptions — not the one that wins a design review, but the one your team can maintain at 3am.
- Name the signal that would trigger revisiting the decision. A specific metric, not "if it doesn't work out."
This process takes 30 minutes for a two-way door decision and three hours for a one-way door. It is not a committee. It is one person doing structured thinking and producing a record.
Getting Buy-In: ADRs and Disagree-and-Commit
An architecture decision nobody agrees with is not a decision — it is a directive that teams will route around.
The Architecture Decision Record (ADR) is the standard format. An ADR is not a design document — it is a decision record. The critical sections: context (what situation forced this decision), options considered (with honest evaluation of each), decision (what was chosen and why), consequences (what gets harder, what gets easier, what is explicitly deferred). The consequences section is where most ADRs fail — architects list only what gets better, not what gets harder.
Circulate the ADR before it is final. The goal is to surface disagreement while the decision is still cheap to change. Set a deadline: feedback by end of week, decision final on Monday. After the deadline, absent blocking information, the decision moves.
Disagree-and-commit is the resolution mechanism when consensus is impossible. The architect makes the call. The dissenting party states their objection on record — in the ADR, in the meeting notes — and commits to the decision. The objection being on record serves two purposes: it validates the dissenter's perspective, and it creates a data point for the post-mortem if the decision turns out to be wrong.
What disagree-and-commit does not mean: the dissenting party's concerns are ignored. They should appear in the "consequences" and "assumptions" sections of the ADR. If the dissent was correct, the ADR is the record of the missed signal.
Defending a Decision When Challenged Later
Challenges come in two forms.
The first is a good-faith challenge: new information has emerged, circumstances have changed, and someone is asking whether the original decision still holds. Engage it directly — reread the original ADR, evaluate whether the new information changes the trade-off, and either reaffirm or formally supersede the decision.
The second is revisionism: the implementation was harder than expected, the team is frustrated, and someone is retroactively questioning the original decision without new information. This is not a challenge to the decision — it is a signal about implementation difficulty. Different problem, different response.
How to tell the difference: is there new information that was not available at decision time? If yes, engage the technical challenge. If no, the conversation is about implementation support, not architectural reconsideration.
The ADR is your defense in both cases. Without documentation, every challenge becomes a debate about who said what in which meeting. With an ADR, the context, the options, the trade-offs, and the decision are on record. The challenge either addresses that record or it does not. For the mechanics of how architectural decisions behave in practice under organizational pressure, the post on architecture decisions at scale is worth reading before you write your first ADR for a contested decision.
Key Takeaways
- One-way vs. two-way doors. Spend disproportionate time on irreversible decisions. Move fast on reversible ones. The failure mode is treating the former like the latter.
- Uncertainty is not a reason to delay; it is information about risk. Document the assumptions, not the certainty.
- The ADR wins buy-in before the decision is final. Circulate, invite challenge, set a deadline. Finalize after the deadline passes.
- Disagree-and-commit requires the objection to be on record. That record protects both the dissenter and the architect.
- Good-faith challenges engage new information. Revisionism does not. Tell the difference before responding.
- Next step this week: Find one decision your team made in the last quarter with no written record. Write a two-paragraph retrospective ADR: what was decided, what the constraints were, what you now know. That is the lowest-fidelity version of the practice that matters most.