Every few months a capable senior engineer asks me how to “become an enterprise architect”, and they nearly always mean the same thing: which course do I take, which certification do I buy, what do I put on the CV. That is the wrong end of the problem, and the gap between those two questions is most of what separates the people who get the title from the people who stall one rung below it for years.

So this is the answer I’d give you over coffee. It is opinionated, it assumes you can already build software, and it is sequenced — because the order you read these things in matters more than the list itself. The job is not a body of knowledge you acquire. It is a change in what you optimise for, and the reading is how you rehearse that change before anyone trusts you to do it for real.

What the job actually is (and isn’t)

The title “enterprise architect” is doing a lot of work, and most of it is misleading. You are not the most senior engineer. You are not a solution architect with a bigger remit. The clearest framing I’ve found is Gregor Hohpe’s elevator: the architect’s value is in riding between floors — connecting the penthouse, where strategy and money live, to the engine room, where the work happens — and refusing to live permanently on either one. A solution architect goes deep on one system. An enterprise architect’s unit of work is the portfolio: the dozen systems, three reorgs and one acquisition that nobody owns end to end.

That reframing has three consequences that trip up new architects:

  • Your output is decisions and options, not designs. Hohpe’s line that “architects sell options” is the most useful sentence in the discipline. Most of your value is keeping expensive choices open, or closing them deliberately, at the right moment.
  • You have less authority than the title implies. EA usually sits in a staff function with no engineers reporting to you. Influence is the entire job. If you need org-chart power to get things done, you will hate this role.
  • You will be wrong in public, slowly. Your decisions play out over quarters, and the feedback loop is long enough that you have to reason from principles rather than waiting to see what works.

If none of that appeals — if what you love is the deep technical craft — stay an engineer. It pays well, it’s more fun, and a good principal engineer is rarer than a mediocre EA. The role is a genuine fork, not a promotion.

The skills that decide who lands the title

Watching people make this transition, the ones who stall almost always stall on the same thing: they keep solving the problem in front of them instead of changing the system that keeps producing it. The skills that actually separate architects who land the title:

  1. Reasoning about the business as a system, not just the software. Why does this company exist, how does it make money, and what does the technology estate have to be true for that to keep working?
  2. Org design literacy. Most “architecture problems” are Conway’s Law with the serial numbers filed off. If you can’t read team boundaries, you can’t read systems.
  3. Writing that survives a room you’re not in. Decision records, one-pagers, the diagram that settles an argument. The artefact has to do the persuading when you’ve left.
  4. Knowing one technical domain deeply enough to be dangerous — usually data. In the AI era this is non-negotiable, because almost every serious architecture question is now a data-lineage question wearing a hat.

The reading path below maps onto those four, in order. You don’t need to finish each step before starting the next, but you should read them in roughly this sequence, because each one assumes the vocabulary of the last.

Step 1 — Foundations: what the role is for

Start with Enterprise Architecture As Strategy. It is twenty years old, the case studies are period pieces, and it remains the fastest way to get a leadership team to admit they don’t actually agree on what kind of company they are. The operating-model quadrant — how unified your processes need to be, how integrated your data needs to be — is the single diagnostic I reach for most weeks. Read it for the framing, skim the case studies.

Enterprise Architecture As Strategy

Then read The Software Architect Elevator. This is the book that teaches you what the job feels like rather than what the deliverables are. If the first book tells you what enterprise architecture is for at the company level, this one tells you how to actually occupy the role without becoming either an ivory-tower diagram-drawer or a glorified tech lead. It is also, almost uniquely among EA books, a pleasure to read.

The Software Architect Elevator

These two are the whole foundation. If you read nothing else on this list, read these and you’ll already think differently in your next architecture review.

Step 2 — Org design: the part nobody tells you is the job

Once you accept that most architecture problems are org problems, you need the vocabulary for it. Team Topologies is short, opinionated, and its cognitive-load framing has already escaped into the wider industry — which means your stakeholders may already speak it. I no longer accept “this will make engineers more productive” as a justification without asking what it does to team cognitive load and the boundaries between stream-aligned and platform teams.

Team Topologies

This is also the step where you stop thinking of “architecture” as a property of software and start thinking of it as a property of the organisation that produces the software. That shift is the actual job. If you want the narrative version of the same lesson first, The Phoenix Project does the storytelling work and is the cheapest org-design lesson around — read it on a train, then come back here.

Step 3 — One technical domain, deep: data

You need at least one domain you can reason about from first principles, and in 2026 the highest-leverage choice is data. Designing Data-Intensive Applications is the only systems book I’ve deliberately re-read three times. It gives you the vocabulary for state, consistency, replication and the derived-data pipelines that every AI initiative quietly depends on. An EA who can’t reason about data lineage is, in the current environment, an EA who signs off on things they don’t understand. Buy the print edition — you will annotate it, and the second edition has been “imminent” for long enough that I’d stop waiting and read the one that exists.

Designing Data-Intensive Applications

The point of this step is not to become a data engineer. It’s to have one domain where you can tell when a vendor or a delivery team is hand-waving. Pick data; the leverage is highest and the questions transfer everywhere.

Step 4 — Framework and certification: signalling, honestly

Now, and only now, the bit everyone wants to start with: TOGAF. Let me be blunt about what certification is and isn’t. TOGAF is signalling. For a meaningful slice of employers — large enterprises, government, consultancies, anywhere procurement writes the job spec — it is a box on the form, and not having it quietly closes doors you’ll never see close. That is a real reason to get it. It is not the same as the framework making you a better architect, and you should not confuse the two.

What TOGAF genuinely gives you is a shared vocabulary and a defensible process when you walk into an organisation that already runs on it. What it does not give you is judgement, and the failure mode of the framework-first architect — the one who produces an immaculate ADM cycle that no engineer will ever read — is so common it’s a stereotype. Read the framework after the four steps above, so you have something to hang it on.

If you’re going for it, two books. The TOGAF Standard, 10th Edition is the reference; the 10th edition is the first version I’d actively defend, because the Fundamental Content is honest about how little it promises and the Series Guides are explicitly optional.

The TOGAF Standard, 10th Edition

Pair it with Mastering TOGAF 10 as the study companion — worked examples more concrete than the standard’s own, and practice questions calibrated to the actual exam. Run both through the structured TOGAF 10 self-study path rather than reading them cover to cover; the standard is a reference document and reading it linearly is a special kind of penance.

Mastering TOGAF 10

Treat the certification as a week of focused study to clear a hurdle, not a year of your development. The hurdle is real; it is also small.

Step 5 — The AI-era shift

The newest pressure on the role, and the one that most reading lists haven’t caught up with, is that you are now architecting systems that change production without a human in the loop. The discipline-level treatment of this is still settling, and the books worth reading are uneven — I cover the current crop in the best EA books of 2026 rather than rehashing them here. What matters for someone entering the role is this: the foundations above are what make the AI material legible, not the other way round. Reason about an agent the way Kleppmann teaches you to reason about a derived-data pipeline, and the hype mostly evaporates.

The bottom line

If you want the honest path from senior engineer to enterprise architect, it isn’t a certificate. It’s a change in the unit of work you optimise for — from the system in front of you to the portfolio and the organisation behind it — and the reading above is how you rehearse that change. Read the two foundation books, absorb the org-design lens, get deep in one technical domain, then clear the TOGAF hurdle if your market demands it. Do it in that order and the title tends to arrive on its own, because by then you’re already doing the job. Do it in reverse — certificate first, judgement maybe-later — and you join the large population of people with “Enterprise Architect” on LinkedIn and a solution architect’s instincts underneath.

For the full ranked buying guide, see the best enterprise architecture books in 2026. For the personal, re-reading version of the list, see what I read in 2025.

Becoming an enterprise architect — straight answers

Do I need a certification to become an enterprise architect?
No certification makes you an architect, but TOGAF (OGEA-101 / OGEA-102) is genuine signalling that opens doors at large enterprises, government and consultancies where procurement writes the job spec. Treat it as a hurdle to clear in a focused week of study, not as a substitute for judgement. Get the foundations first and the certification last.
What's the difference between a solution architect and an enterprise architect?
A solution architect goes deep on one system. An enterprise architect's unit of work is the portfolio — the dozen systems, the reorgs and the acquisitions that nobody owns end to end — and most of the job is influence without org-chart authority. It's a genuine fork from the engineering track, not a promotion above it.
Which book should I read first to move into enterprise architecture?
Enterprise Architecture As Strategy (Ross, Weill, Robertson) for what the role is for at the company level, then The Software Architect Elevator (Hohpe) for what occupying the role actually feels like. Those two are the whole foundation; read them before touching any framework material.
Can I become an enterprise architect without being a senior engineer first?
It's possible but harder, because the role's credibility comes from having shipped real systems and lived with the consequences. The fastest route is to be a strong senior or principal engineer who can already reason about one technical domain deeply — usually data — and then deliberately widen the unit of work you optimise for.
How long does it take to become an enterprise architect?
There's no fixed timeline, but expect a few years of deliberately broadening from system-level to portfolio-level thinking on top of solid engineering experience. The reading path here is months, not years; the judgement it rehearses is what takes time, and it accrues fastest when you're already operating one rung below the title.