Overview

Architectural thinking is the ability to see systems from an architect’s perspective — understanding how individual changes affect overall scalability, how system parts interact, and which technologies fit a given problem. It is distinct from coding or design thinking. Richards and Ford describe four core aspects: understanding the architecture/design spectrum, building technical breadth, translating business drivers into architectural characteristics, and analysing trade-offs systematically.

Architecture is the stuff you can’t Google or ask an LLM about.

Mark Richards

Architecture vs design

Architecture and design exist on a spectrum, not in separate buckets. Three criteria help classify a decision:

  1. Strategic vs tactical: strategic decisions are long-term, involve many stakeholders, require weeks of planning → architectural. Tactical decisions are short-term, made alone or in a pair, change quickly → design.
  2. Level of effort: Martin Fowler defines architecture as “the stuff that’s hard to change.” Higher effort to change = more architectural.
  3. Significance of trade-offs: bigger trade-offs push a decision toward the architecture end. Moving monolith → microservices has enormous trade-offs; rearranging fields on a screen does not.

Technical breadth vs depth

Developers must have deep expertise (technical depth). Architects must have wide exposure (technical breadth). The knowledge pyramid captures this:

For an architect, breadth is more important than depth. Knowing five solutions exist for a problem is more valuable than being the world’s expert in one. The recommended posture: sacrifice some hard-won expertise periodically to broaden the portfolio.

Dysfunctions from ignoring this

  1. Attempting to maintain depth across too many areas, succeeding in none.
  2. Stale expertise: outdated knowledge mistaken for current mastery (see Frozen Caveman antipattern below).

Techniques for building breadth

Frozen Caveman antipattern

Architects who have been burned by past failures become irrationally fixated on that failure mode in every future design, even when the risk is negligible. Example: an architect who once experienced a major outage becomes obsessed with a redundancy concern that is statistically unlikely in the new context. Recognising and overcoming Frozen Caveman thinking is part of mature architectural thinking.

Trade-off analysis

Every architecture decision has trade-offs — there are no universally “correct” answers, only contextual judgements.

There are no right or wrong answers in architecture — only trade-offs.

Neal Ford

Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

Rich Hickey

Thinking architecturally means explicitly enumerating both the benefits and the costs of a solution before deciding. Example: pub/sub topics give extensibility and decoupling, but introduce data-access security risks, prevent heterogeneous contracts, and limit programmatic autoscaling — whereas point-to-point queues sacrifice extensibility for better isolation and monitoring.

Balancing hands-on coding

Architects must stay hands-on to avoid losing credibility and to avoid the Bottleneck Trap (taking ownership of critical-path code and blocking the team). Techniques:

Resources