Architecture = Decisions, Not Diagrams

Architecture = Decisions, Not Diagrams

Most teams treat architecture as a diagram: boxes, arrows, and a list of “approved” technologies. Senior engineers treat architecture as a series of decisions made under uncertainty.

Those decisions have two features:

1. They trade one quality for another (speed vs. safety, scale vs. simplicity)
2. They age over time (what was right at 1k users can be wrong at 100k)

If you can’t name the tradeoff or why it was chosen, you don’t have architecture — you have folklore.

Decision Patterns You’ll Use All Course

Pattern 1: Name the decision driver.

Every architectural decision has a primary driver:

• Performance? Reliability? Cost? Compliance? Time-to-market?
• “Because we like it” is not a driver.

Pattern 2: Classify reversibility.

• One-way door: hard to reverse (data model, platform choice)
• Two-way door: cheap to change (library, internal API style)

Pattern 3: Keep a decision log.

Architecture is 80% “why we chose X.” Document the context, options, and tradeoffs so the next team can evaluate, not guess.

The Minimum Viable Architecture (MVA)

A good architecture is the minimum structure that keeps you moving safely. Too little and you drown in chaos; too much and you slow to a crawl.

MVA checklist:

• Clear module boundaries
• A consistent data model
• A deployment pipeline
• Observability for critical paths
• A decision log for irreversible choices

Rule of thumb: if a decision doesn’t prevent you from shipping next month, keep it lightweight.

🧠 Knowledge Check

Q: What’s the fastest way to diagnose whether a team actually has an architecture?

<details> <summary>💡 Reveal Answer</summary>

Ask: “What were your last 3 architectural decisions and why did you choose them?”

If the team can’t answer, the architecture isn’t explicit. It’s accidental.

</details> <details> <summary>Best approach</summary> </details>