A developer on a team I work with asked me last spring what to read to understand enterprise architecture. I sent her the ranked list, because that is what I always send. Three weeks later she told me, politely, that she had got forty pages into Enterprise Architecture As Strategy and could not tell whether it was profound or just consultancy prose about companies that no longer exist.

She was right to be suspicious, and I had given her bad advice. Not because the book is bad — it is the most useful strategy-level EA book there is — but because I handed her a ranked list when what she needed was a sequence. A ranking answers “which book is best”. A beginner needs the answer to a different question: which book will make the next one legible.

So this is the sequence. Three books, in order, and then the popular ones I would actively tell you to postpone.

Why order matters more than quality here

Almost every EA book assumes you have already been in the room. They assume you have watched a programme miss two quarters because nobody could say which system owned the customer record. They assume you have sat through the meeting where a transformation is announced and the architecture is described as “an enabler”. If you have that scar tissue, the books read as a diagnosis. If you don’t, they read as vocabulary — and vocabulary without the experience it describes is exactly the raw material for the ivory-tower architect nobody listens to.

That is the whole design principle behind this list. Feel the problem first, then get the framing for it, then learn how to talk about it upward. In that order, each book lands on something. In any other order, at least one of them is wallpaper.

Book one — feel the problem: The Phoenix Project

Start with a novel. I am aware of how that sounds.

The Phoenix Project is a parable about an IT organisation in trouble, and it is the cheapest way I know to acquire second-hand scar tissue. It gives you the Four Types of Work — planned work, unplanned work, changes, internal projects — which is the single most useful thing you can draw on a whiteboard in front of a steering committee. It gives you Brent, the engineer who is a single point of failure for everything, and naming that pattern is how you get to talk about it without attacking the actual Brent. And it gives you constraint thinking: the lesson that an hour saved anywhere other than the bottleneck is a mirage. That one idea will save you from about a third of the “we just need more developers” conversations you are going to have.

What a beginner gets from it: the shape of organisational dysfunction, in narrative form, in two evenings. What a beginner does not get: anything resembling enterprise architecture as a discipline. There is no portfolio view, no operating model, no reasoning about the estate. The technology is dated and the ITIL-heavy world it satirises has softened in places. Read it anyway, and read it first, because the next book is going to describe the fix and you want to already recognise the disease.

The Phoenix Project

· Full review →

Book two — what EA is for: Enterprise Architecture As Strategy

Now the one my colleague bounced off. Read second, it works.

Ross, Weill and Robertson’s argument is that enterprise architecture is not a diagramming activity, it is the deliberate choice of a foundation for execution: the set of things you standardise once so that the business can stop re-deciding them. Their operating-model quadrant — how integrated your data needs to be, how standardised your processes need to be — is the diagnostic I reach for most weeks, twenty years after publication. It is the fastest instrument I have found for getting a leadership team to admit out loud that they do not agree on what kind of company they are.

Be honest with yourself about the reading experience. The case studies are period pieces, several of the companies have since been acquired or restructured beyond recognition, and the prose has the flat cadence of academic business writing. Read it for the framing and skim the cases; nobody will test you on them. What you want out of it is one durable habit: when someone proposes a platform, an integration layer or a shared service, you now ask what operating model it presupposes — and notice how often nobody has decided.

Enterprise Architecture As Strategy

· Full review →

Book three — how architects actually work: The Software Architect Elevator

The first two books tell you what goes wrong and what the discipline is for. Hohpe’s book tells you what the job feels like from the inside, which is the part that surprises people who arrive from engineering.

The elevator metaphor does most of the work: the architect’s value is in riding between the penthouse, where money and strategy live, and the engine room, where the work happens — and in refusing to take up permanent residence on either floor. The related idea, that architects sell options, is the most useful sentence in the discipline and quietly changed how I write decision records. If you only take one thing from this list into your next architecture review, take the habit of asking which expensive choices a decision keeps open and which it closes.

For a beginner this is also the least intimidating of the three: short essays, readable in any order, genuinely good prose, which almost no EA book is. What it will not give you is a method. There is no process to follow at the end, and if you are the kind of reader who wants a checklist you will find it frustrating. That frustration is itself informative about the role.

The Software Architect Elevator

· Full review →

If those three land, read this fourth

Team Topologies is the natural fourth book and the first one where you are no longer a beginner. It gives you the vocabulary — stream-aligned teams, platform teams, cognitive load — for the thing you will have started to suspect around book two: that most architecture problems are org-design problems wearing a technical costume. I put it fourth rather than first because its arguments are compressed and assume you have already been annoyed by the problem it solves. Read it straight after The Phoenix Project if you want the same lesson twice, once as story and once as framework.

Team Topologies

· Full review →

The TOGAF standard — the worst possible first book

This is the one beginners reach for, because it is the thing with “enterprise architecture” written on the front and a certification attached. Do not start here. The TOGAF standard is a reference document, not a book: it describes a method for running architecture work in an organisation that already has an architecture function, a governance forum and stakeholders who want deliverables. Read cover to cover with no experience to hang it on, it is an enormous vocabulary list, and the predictable outcome is an architect who can produce an immaculate ADM cycle that no engineer will ever open.

It is worth reading — later, and instrumentally, when your employer runs on it or you want the certification for signalling. I have written separately about the honest route into the role and where certification actually sits in it. The short version: framework fourth or fifth, never first.

Zachman, ArchiMate and the reference literature

Same problem, less upside for a beginner. Ontologies and modelling notations are tools for organising work you are already doing. If you are not yet doing the work, you are memorising a taxonomy.

The heavyweight technical books

Designing Data-Intensive Applications belongs on any serious architect’s shelf and I have re-read it deliberately three times. It is still the wrong fourth book for someone who has not yet decided whether this role is for them, because it is a term’s worth of study and it answers depth questions rather than “what is this job”. Same for the evolutionary-architecture and agentic-AI material — excellent, and all of it assumes the foundations above. The full ranked picture is in the 2026 list when you get there.

The DevOps Handbook

Skip it unless you are auditing a transformation programme. The Phoenix Project does the storytelling work; the Handbook does the homework. Most practitioners do not need the homework.

The bottom line

Three books, in this order: The Phoenix Project to feel the problem, Enterprise Architecture As Strategy to learn what the discipline is for, The Software Architect Elevator to learn how the job is actually done. That is perhaps a month of evenings and it will put you ahead of a large number of people who own the title, because most of them read the framework first and the foundations never.

If after those three you find yourself more interested in the org chart than the architecture diagrams, you are reacting correctly, and Team Topologies is next. If you find yourself wanting the method and the certification, that is a real path too — just take it in the fourth slot, where the material can land on something.

Starting out in EA — quick answers

What is the best enterprise architecture book for a complete beginner?
The Phoenix Project, even though it is a novel and not strictly an EA book. It gives you the organisational problems enterprise architecture exists to solve, in narrative form, in two evenings. Read it before Enterprise Architecture As Strategy and the strategy material will land instead of reading as abstract consultancy prose.
Should I start with the TOGAF standard if I want to learn enterprise architecture?
No. TOGAF is a reference document describing a method for organisations that already have an architecture function. Read cover to cover with no experience to attach it to, it is a vocabulary list, and it produces architects who write process documents nobody reads. Read it fourth or fifth, when your employer runs on it or you want the certification for signalling.
How many EA books do I need to read before I can do the job?
Three is enough to start being useful: The Phoenix Project, Enterprise Architecture As Strategy, and The Software Architect Elevator. That is roughly a month of evenings. The books do not make you an architect — they let you recognise what you are looking at when you get into the room.
Is Enterprise Architecture As Strategy too old to be worth reading in 2026?
The case studies are period pieces and several of the companies have since been restructured, but the operating-model diagnostic has not aged at all. Read it for the framing — how standardised your processes need to be, how integrated your data needs to be — and skim the cases.
What should I read after the first three enterprise architecture books?
Team Topologies, for the org-design vocabulary you will have started reaching for by then. After that it depends on direction: the TOGAF material if you need the certification, or Designing Data-Intensive Applications if you want one technical domain you can reason about from first principles.