Early in my career I thought a good architecture decision was a clever one. I'd look for the elegant pattern, the framework nobody else had thought of, the design that would impress in a review. Fourteen years and many design reviews later, I judge decisions very differently. The ones that age well are rarely clever. They're cheap to reverse, easy to explain and honest about their trade-offs.
1. Separate one-way doors from two-way doors
Most decisions are two-way doors: if we're wrong, we walk back through. Choosing a UI component library, a naming convention, even most integration tools. A few are one-way doors: the core data model, the org strategy (single vs multi-org), the identity model, the system of record for a key entity.
I now spend the bulk of review time on the one-way doors and deliberately move fast on the rest. Teams that treat every decision as irreversible slow to a crawl. Teams that treat every decision as reversible end up with a data model they can't change.
2. Write the decision down — with the alternatives
A lightweight Architecture Decision Record (ADR) is the cheapest insurance I know. Mine have five headings:
- Context — what forced the decision now.
- Options considered — at least two real ones.
- Decision — what we chose.
- Consequences — what gets easier, what gets harder.
- Revisit when — the signal that should make us reopen it.
The "revisit when" line is the most underrated. It turns a decision from a monument into a hypothesis.
3. Prefer boring at the core, interesting at the edges
The centre of an enterprise platform — data model, security model, integration backbone — should be boring, well-understood and well-documented. Innovation belongs at the edges, where it's contained: a new AI capability behind a clear interface, an experimental channel, a proof of concept.
This is especially true with AI right now. The agentic layer can evolve every quarter. The order data it reads from should not.
4. Design for the team who will run it
The decisions that age worst are those that only made sense to the people in the room. A pattern that requires three senior developers to maintain is a liability the day they move on. I ask a simple question in every review: "Could the support team explain this at 2 a.m.?"
5. Make non-functional requirements first-class
Volume, latency, availability, security, auditability. Nobody gets excited about NFRs in a kickoff, and every serious production incident I've seen traced back to one we skipped. I put them on the same page as the functional scope — with numbers, not adjectives.
- Have a written rationale and alternatives
- Isolate change behind clear interfaces
- State NFRs with numbers
- Name the signal to revisit them
- Optimise for the demo, not the decade
- Depend on one person's knowledge
- Couple the core to a fast-moving tool
- Treat "we'll fix it later" as a plan
The question I ask last
Before signing off any significant design I ask: "If we're wrong about this, how much will it cost to find out, and how much will it cost to change?" If both answers are small, we move. If either is large, we slow down and get more evidence. That one question has saved more programmes than any framework I know.
Pranav Sanvatsarkar is a Solution Architect with 14+ years across telecom, healthcare, public sector and non-profit, focused on AI, agentic automation and Salesforce architecture. Say Hello!