Software architecture · Level 0: The architect · Module 02 of 46

The architect's role

An architect isn't the best programmer promoted upwards. It's a different job: making and explaining the expensive decisions, knowing a little about a lot of technology rather than a lot about a little, and staying close enough to the code to keep decisions honest without becoming the person every task waits for. This module covers what the job expects, how knowledge has to change, and the two traps that catch most new architects.

1. The idea

A head chef. They design the menu, lay out the kitchen, choose suppliers, set the standards and taste every dish before it leaves. They still cook, but not the one sauce that every order waits on: if they're called to a meeting with the owner, the kitchen must keep running. A chef who stops cooking entirely loses touch with what's possible; one who cooks every dish becomes the kitchen's bottleneck.

Whatever the title, eight expectations come with the architect's job:

Decide and explain

Make architecture decisions, and guide technology choices rather than dictate them.
Keep analysing the architecture: is it still fit for today's load, team and business?
Make sure decisions are followed, ideally with automated checks rather than policing.
Explain decisions to developers and to the business, in each one's terms.

Know and connect

Keep up with technology trends: decisions last years, so their context matters.
Have broad, varied experience across platforms, languages and styles.
Understand the business domain: its words, its money and its plans.
Work with people and politics: almost every architecture decision will be challenged by someone.

Knowledge: from depth to breadth

Think of everything you know as a pyramid. The top is what you know well and could build with tomorrow. The middle is what you know you don't know: you know the technology exists, what it's for and roughly what it costs, but couldn't build with it today. The bottom is what you don't know you don't know: solutions you've never heard of.

Developers are paid for the top. Architects are paid mostly for the middle: you can't choose a message broker, a database or a style that you've never heard of. The top still matters, but keeping deep knowledge current takes time every week, so an architect deliberately trades some depth for breadth.

2. How it works

Trap 1: the architect on the critical path

New architects often keep the most interesting code for themselves. Press Play to see what that does to a sprint.

Trap 2: the ivory tower

The opposite trap: decisions handed down with no way for what the team learns to flow back. Watch how the same decision fares with and without the feedback loop.

3. Try it yourself

Your knowledge pyramid

Tap each technology to say how well you know it: once for "I know what it's for" (gold), twice for "I could build with it" (green), three times to clear. The pyramid redraws with each band's area matching your answers. Try the presets to compare a typical developer and a typical architect.

Illustrative: "hours a week to stay current" assumes about one hour per technology you know deeply. The point is the shape, not the numbers.

4. Trade-offs

Breadth vs depth

Breadth lets you see options and their costs; depth lets you judge whether an option will really work. Keep deep skill in one or two areas you use daily, and grow breadth everywhere else.

Hands-on vs strategic

Coding keeps your decisions realistic and earns the team's trust. Owning critical-path code makes you a bottleneck. Code where being late doesn't block anyone.

Guide vs dictate

Dictating every technology choice is fast but makes the team passive and resentful. Guiding (setting the constraints and letting the team choose within them) is slower to agree but sticks.

Specialist vs generalist architect

Data, security and platform architects go deep in one area; application and solution architects go wide. Both need the other's vocabulary to work together.

5. In real projects

Roles and titles

Titles vary wildly between companies. What separates the roles is scope (how much of the system and organisation a decision touches) and time horizon.

Role	Scope	Time horizon	Typical decision
Senior developer	Their code and their team's design	Weeks	How to structure this feature
Tech lead	One team's application	Months	Which framework and patterns the team uses
Application / solution architect	One system or product, several teams	One to three years	Style, components, data ownership, integration
Enterprise architect	All systems in the organisation	Three to five years	Standards, platforms, which systems to replace
Specialist (data, security, platform)	One concern across many systems	Varies	Data platform, identity, deployment platform

Staying hands-on without becoming the bottleneck

Build proofs of concept for risky decisions, and write them as if they might go to production: people copy them.
Take technical-debt and bug-fix work: useful, off the critical path, and it shows you where the architecture hurts.
Automate: write the fitness functions and checks that keep the architecture honest (Module 26), and tools that save the team time.
Review code regularly, looking for architecture drift rather than style nits.
Learn a little every day: a fixed short slot (say 20 minutes before email) for reading about something you've only heard of. Breadth grows slowly but steadily.

Say it in the interview

Two-sentence answers

"What does an architect do?" Makes and explains the decisions that are expensive to change, keeps checking the architecture still fits, and makes sure decisions are followed. Much of the job is translating between the business and the code.
"How do you stay technical?" Proofs of concept, technical-debt work and automation, never code on the critical path. And a little reading every day to keep my breadth current.
"Breadth or depth?" Depth in one or two areas I use daily, breadth everywhere else. I can't choose a tool I've never heard of, and I can't keep twenty tools at expert level.

Red flags interviewers notice

"I write the core framework myself so it's done right."
Describing decisions handed to the team, with no mention of feedback or revision.
Recommending only the technologies you already know well.

6. Remember it

Memory hook: "Wide, not deep; near the code, not in its way"Know a little about a lot, stay close to the code, and never be the thing the team waits for.

How this hook works: what "wide, not deep; near the code, not in its way" means

What the slogan means, phrase by phrase

"Wide, not deep": Grow the middle of the pyramid: know what exists, what it's for and what it costs.
"near the code": Proofs of concept, debt work, reviews and automation keep your decisions realistic.
"not in its way": Never own code that blocks the team when you're pulled into meetings.

Why this picture fits: it names the two traps in one line: losing touch (too far from the code) and becoming the bottleneck (too far into it).

The story → the concept

The head chef	The architect
Designs the menu and kitchen	Makes architecture decisions
Tastes every dish	Reviews code and checks fitness functions
Cooks specials, not the sauce every order needs	Writes proofs of concept, not critical-path code
Knows every supplier and ingredient	Technical breadth

The trap it saves you from

Measuring yourself by the code you write, as you did as a developer.

7. Common mistakes

Owning critical-path codeThe architect is pulled into meetings, reviews and incidents; the code they own waits, and so does every task that depends on it.

The ivory towerHanding down diagrams without staying to see them built. The team works around the parts that don't fit, and the real architecture drifts from the documented one.

Recommending what you knowIf your top band is Java and PostgreSQL, everything looks like a Java and PostgreSQL problem. Breadth is what lets you see the alternatives.

Waiting for the titleArchitecture work is done before the title arrives: analysing trade-offs, writing decision records, explaining choices. Start doing it on your current team.

8. Design exercise (30 minutes)

Draw your pyramid (10 min). Use the lab with your own answers, then add five technologies your team uses that aren't on the list.
Plan breadth (10 min). Pick five "never heard" or "know it exists" items relevant to your work. Schedule 20 minutes for each over the next two weeks.
Find the critical path (10 min). List the code you (or your architect) own. For each piece, ask: if the owner disappeared into meetings for a week, would anyone be blocked? Plan to hand those over.

9. Self-check quiz

Which band of the knowledge pyramid is the architect's main value?

You can only choose among options you know exist; that middle band is breadth.

Which coding work suits an architect best?

Valuable, informs a decision, and nobody is blocked if it waits a day.

What goes wrong with an ivory-tower architect?

Without feedback, the team works around problems and the real architecture diverges from the documented one.

What mainly separates a tech lead from an enterprise architect?

One team over months versus the whole organisation over years.

How should an architect usually handle a technology choice inside one team's service?

Guide rather than dictate: the team owns the choice, the architect owns the constraints that matter across teams.

10. Go deeper

Resource	Time	Why
The Software Architect Elevator (Gregor Hohpe)	book	The architect as the person who rides between the boardroom and the engine room.
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)	book	Chapter 1 lists the expectations of an architect; chapter 2 covers breadth and hands-on coding.
Who needs an architect? (Martin Fowler)	15 min	Two kinds of architect: the one who makes all decisions, and the one who makes the team better.