There is a small set of EA books that survive the test of being quoted by people who have not actually read them. Enterprise Architecture As Strategy is one of them. It is the source of the Operating Model quadrant — Diversification, Coordination, Replication, Unification — which has been laundered through a thousand consulting decks and survives every laundering mostly intact.

If your only exposure to the book is those four boxes, you are missing roughly eighty percent of what makes the book useful. The boxes are the finished diagnostic. The argument that produced them is the part you actually want.

The actual thesis

The thesis is one sentence: the job of enterprise architecture is to make the operating model executable. Not to document the current state. Not to produce target-state diagrams that no one reads. Not to govern. To make it possible for an organization to do, repeatedly and cheaply, the thing it has decided to be good at.

This sounds obvious. It is not obvious in practice, because most EA functions inherit their charter from the IT side of the house and end up solving for technology rationalization — which is a perfectly reasonable goal but is not the same goal. The book’s quiet, twenty-year-old insistence that EA is a business discipline that happens to live in IT is the part that has aged best.

The Four Operating Models, in plain English

The two axes are integration (do business units share customers, products, data?) and standardization (do business units run the same processes?). The four combinations:

  • Diversification: low integration, low standardization. Holding companies. Conglomerates. Private-equity portfolios. The job of central IT is to be small and ignorable.
  • Coordination: high integration, low standardization. Different business units doing different things for the same customer. Universal banks, large hospital systems.
  • Replication: low integration, high standardization. Franchise models. Retail chains. Same process, separate customers.
  • Unification: high integration, high standardization. One process, one customer base, one truth. SaaS companies, integrated airlines.

The diagnostic is brutally useful because most large organizations think they are Unification when they are actually Coordination, or vice versa, and the resulting EA strategy is wrong in predictable ways. I have walked into engagements where the target-state architecture assumed Unification and the operating model the company actually ran was Coordination, and the result was eighteen months of rebuilding integration patterns that were never going to be adopted.

What the book gets right

  • It refuses to be normative about which model is “best.” Each model has its own EA implications. The book takes pains to give worked examples in every quadrant, including ones (Diversification) where the honest EA answer is “do less.”
  • The Foundation for Execution framing. The book argues that EA produces a Foundation — a stable set of digitized processes, shared data, and reusable infrastructure — that the business can then build on. This is the most cogent answer I have read to the perennial “what is EA actually for” question.
  • The maturity-stage progression. Silos, standardized technology, optimized core, business modularity. It is descriptive rather than prescriptive, which is rare for EA literature.

What feels dated

A lot, honestly. The case studies — UPS, Dow, Delta, ING Direct — are period pieces. The treatment of “digital” assumes a 2006 enterprise where the customer-facing channel is a website and the back office runs SAP. There is essentially no treatment of cloud, no treatment of platform businesses, no treatment of the way data products have collapsed parts of the integration problem into the storage layer.

But — and this is the thing — the framework survives the case studies. The Operating Model quadrant works just as well for a company whose “products” are LLM-mediated services and whose “processes” are agent workflows. I have used it inside conversations about how to organize an AI platform team. The axes do not care what the technology is.

What I wish the book had

A chapter on what happens when the operating model the business says it runs is not the operating model it actually runs. Most of the value I get from the framework is in surfacing that gap, not in confirming the official answer. The book treats the operating model as a deliberate choice. In practice it is almost always a residue of past acquisitions, politically-protected fiefdoms, and one CEO’s preference five years ago.

Who I’d give this to

  • Any new head of EA, on day one.
  • Any CIO who has just been told to “do an enterprise architecture.”
  • The strategy team, if they will read it. They usually will not, but the book is short enough that you can hand it over without imposing.

I would not give it to a hands-on architect. The book operates at a higher altitude than most architects need to work at, and the practical patterns live elsewhere. For that I would point at The Software Architect Elevator, which is the natural pair.

Reading note

The book is short — about 230 pages — and a third of that is case studies you can skim. The first three chapters and the closing chapter are the load-bearing parts. If you read those four chapters and one case study from a quadrant you actually work in, you have got the whole argument.

Bottom line

This is the EA book I trust most when I am trying to convince a non-architect that EA is a real discipline rather than a documentation hobby. The Operating Model framework alone is worth the price. The fact that it survived twenty years of digital transformation hype unchanged is, I think, a quiet endorsement of how solid the underlying thinking is.

The natural next reads are The Software Architect Elevator for the practitioner lens and The TOGAF Standard, 10th Edition for the governance scaffolding that most large organizations end up bolting on top of the operating-model conversation.