Six architecture decisions that aged well

Architecture is one of the few disciplines where you get graded a decade late. The design review says you were right; the maintenance backlog five years on tells you whether you actually were.

I went back through the systems I have worked on that are still running and asked a narrow question: which decisions am I still glad about? Not which were clever — which ones were still paying rent long after I had left the building.

1. Putting the domain model before the delivery mechanism

Every system that survived had a core that did not know how it was being invoked. HTTP, message queue, batch file, scheduled job — all of them were adapters around something that would have compiled without them.

This sounds like architectural piety until you watch the alternative. Business logic embedded in a servlet in 2003 had to be rewritten for SOAP in 2006, REST in 2011, and events in 2018. Logic that sat behind an interface got four new adapters instead of four rewrites.

2. One source of truth for identity, always

Every single integration nightmare I have been called into had multiple answers to "who is this person?" Duplicate customer records, three definitions of an active account, an employee who left but still owns approvals in one system.

Identity is the one place where I have never regretted centralising, and never once regretted the extra six weeks it cost up front.

3. Making the boring path the fast path

If the safe way to deploy is slower than the unsafe way, engineers will use the unsafe way, and they will be right to. Every environment where quality held had one property: the governed route was also the convenient route.

4. Writing the trade-off down at the moment of decision

Not a document. A paragraph, in the repository, next to the code:

ADR-014: Synchronous pricing call at checkout
Status:   Accepted (2019-03)
Context:  Pricing changes hourly; stale prices cause revenue leakage
          and customer disputes. Cache invalidation across 40 regions
          was estimated at 6 weeks.
Decision: Call pricing synchronously. Accept +80ms p95 at checkout.
Revisit:  If checkout p95 exceeds 400ms, or if regional cache
          invalidation becomes available as a platform service.

The value is entirely in that last line. Four years later, someone found this file, saw that the revisit condition had been met, and changed the design in a week — without archaeology, without a war room, and without anyone claiming "we've always done it this way".

5. Choosing the database for the shape of the questions

Not for the shape of the data — anything can store anything now. For the questions. If the interesting questions are about relationships more than two hops deep, a relational schema will fight you forever, and no amount of ORM cleverness changes that. If the questions are aggregate and columnar, row storage will punish you.

I have been wrong about this in both directions, and both were expensive.

6. Refusing to build the thing that had no owner

The single highest-return decision of my career was declining to build a system that no business unit would agree to own after launch. It was a good idea. It was well funded. There was no name on the line for its future.

Every unowned system I did build is either dead or a hazard.

Architecture is not the art of choosing the best option. It is the art of choosing the option whose consequences you are willing to live with for ten years.

The common thread

None of these are technology choices. Re-reading the list, what strikes me is that not one of them would show up on an architecture diagram. They are all decisions about reversibility — keeping the cost of the eleventh change close to the cost of the first.

That is the whole job, really. Everything else is implementation detail.