⌘ The Architecture Reference

Fnd thinking · Foundations · Beginner

The Architect's Role

The eight expectations of an architect, why breadth beats depth, and why roughly half the job is people skills.

Fnd thinking Beginner ⏱ 4 min read Complete

🚁 Analogy

An architect is less like a lone genius drawing blueprints and more like a helicopter pilot — a control for each hand and foot, every input affecting the others, constantly balancing technical breadth, trade-offs, business drivers, and the team. You are steering, not building every part.

The eight expectations

Fundamentals of Software Architecture lists eight expectations that hold regardless of your title:

  1. Make architecture decisions — guide technology choices rather than specify them (say “use a reactive frontend framework,” not “use React”); mandate a specific technology only when a characteristic demands it.
  2. Continually analyse the architecture — watch for structural decay; ask whether a three-year-old architecture is still viable (its vitality).
  3. Keep current with trends — your decisions are long-lasting and hard to reverse.
  4. Ensure compliance with decisions — verify teams actually follow the rules and principles.
  5. Have diverse exposure and experience — favour breadth over depth.
  6. Have business domain knowledge — to communicate with stakeholders and earn credibility.
  7. Possess interpersonal skills — leadership is at least half the job.
  8. Understand and navigate politics — almost every decision will be challenged.

Breadth over depth: the knowledge pyramid

All knowledge splits into what you know, what you know you don’t know, and what you don’t know you don’t know. Developers build a tall, narrow pyramid of expertise — but what you know is also what you must maintain, and it decays. Architects value the top and middle; technical breadth is how far that middle penetrates the unknown. Knowing that five caching products exist and their trade-offs beats being the world expert on one.

graph TD
K["What you know<br/>(must maintain · decays)"] --> Dev["Developer values depth here"]
KU["What you know<br/>you don't know"] --> Arch["Architect values breadth here"]
U["What you don't know<br/>you don't know"] --> Arch
Arch --> B["Breadth = how far the middle<br/>reaches into the unknown"]

Two dysfunctions threaten breadth: spreading too thin (expert in nothing) and stale expertise (mistaking outdated knowledge for current). The 20-minute rule — learn something new every morning before email — keeps breadth fresh.

Stay hands-on without becoming a bottleneck

Every architect should still code, but avoid the bottleneck trap of owning critical-path or framework code. Tactics: delegate the critical path and instead build business functionality one to three iterations out; write frequent proofs-of-concept (production-quality — they often become reference architecture); tackle technical-debt stories; build automation, CLI tools, and fitness functions; and do frequent code reviews.

graph TD
A["Architect's coding time"] --> X["Critical-path / framework code"]
A --> Y["Business features 1-3 iterations out"]
X -->|"AVOID — creates a"| B["Bottleneck<br/>(team blocked on you)"]
Y -->|"PREFER — stays hands-on"| H["Hands-on, not in the way"]

⚠️ Two personality anti-patterns

The Control Freak sets boundaries too tight (bans libraries, dictates class design) and steals the art of programming. The Armchair Architect sets them too loose, hasn’t coded recently, and draws diagrams too high-level to use. Aim for the just-right boundary that matches the team’s familiarity, size, experience, project complexity, and duration.

People skills are half the job

“No matter what the problem is, it’s a people problem” (Weinberg). The 4 C’s — Communication, Collaboration, Clarity, Conciseness — are the antidote to accidental complexity (a problem we made hard) versus essential complexity (a genuinely hard problem). Lead by example, not by title; provide justification rather than dictating; and let developers arrive at the solution themselves.

💡 Key insight

Guide, don’t specify. The architect’s leverage comes from setting constraints and explaining why — captured in architecture decision records — not from making every technical choice personally.

See also

When to use it — and when not

✅ Reach for it when

  • When defining what an architect is accountable for on a team
  • When transitioning from senior developer into an architecture role
  • When deciding how to keep technically sharp without becoming a bottleneck

⛔ Think twice when

  • When you expect a single universal job description — the role is context-dependent and still expanding
  • When you want to justify never coding again
fnd-thinkingArchitecture vs Design

Where the line between architecture and design actually sits — and why locating a decision on that spectrum tells you who should make it.

fnd-thinkingThinking in Trade-offs

The First Law of Software Architecture in practice — why every answer is 'it depends,' and how to analyse benefits against trade-offs.

fnd-evolutionArchitecture Decision Records

How to capture, justify, and communicate architecture decisions as ADRs — overcoming the three decision anti-patterns by recording the why.

Check your understanding

Score: 0 / 4

1. Why should architects favour technical breadth over depth?

In the knowledge pyramid, architects value the top and middle; breadth is how far the middle penetrates the bottom. Knowing five caching options' trade-offs beats mastering one.

2. What is the 'bottleneck trap'?

Architects should delegate critical-path code and code business functionality a few iterations out, so they stay hands-on without blocking the team.

3. Which best captures the 'Frozen Caveman' anti-pattern?

The Frozen Caveman keeps raising the same irrational risk ('but what if we lose Italy?'); distinguish genuine from perceived technical risk.

4. Roughly how much of being an effective architect is people and leadership skill?

Fundamentals stresses leadership is at least half the job — 'it's always a people problem' (Weinberg).

Comments

Sign in with GitHub to join the discussion.