Some years into applying the TOGAF® Standard, I watched a capable architecture team present a complete set of deliverables to a sponsor who had stopped listening. Every catalogue was there. The matrices reconciled, and the diagrams were clean enough to frame. The sponsor, a practical person with a budget to defend and a board to answer to, asked one question: what does any of this change on Monday?
Nobody in the room could answer it, me included. The target architecture had no funding agreed. The principles had never left the room. The roadmap's first step depended on a decision nobody had asked the sponsor to make. In the Preface of Enterprise Architecture in Practice I put it as plainly as I can: "The work was correct and inert. We had produced the framework rather than used it."
That book went on sale on Sunday 1 November. It is the sixth book I have published this year, and the first written for the people in my own trade.
Why a field guide, when the Standard already exists
The Open Group publishes the TOGAF Standard, and it is the authoritative reference [1]. If you want the definitive statement of what a phase contains or what an artefact is, that is where you go, and the book points you there throughout.
What the Standard tells you is what the framework is. It says much less about what applying it asks of you. Take scope. Phase A tells you to define the scope of the engagement and lists the dimensions you can bound it along. It does not warn you about the commonest way I have seen an engagement fail: a scope that is technically complete and politically impossible. One that commits four business units to a change only two of them have accepted. Knowing the definition of scope does not protect you from that. Knowing how the definition behaves in a real room, with sponsors who can still withdraw, does.
That knowledge is judgement, and judgement is the part a standard cannot teach, because teaching it is not a standard's job. Two teams can apply every step of the same method. One leaves the organisation exactly where it found it. The other changes something real. The framework is identical in both rooms. The practitioner is not.
One company, from first workshop to last review
The book carries one fictional company through the whole method. Astela Telecommunications has joined seven businesses by acquisition and runs seven overlapping customer systems. It has been handed a 40 per cent call centre cost target and answers to a board that wants to know where the money is going [2]. Astela is invented. Every problem it meets is one I have met in a real organisation.
Following one company across nineteen chapters shows something a phase-by-phase reference cannot: how decisions connect. A scope agreed loosely in Phase A comes back to find you in Migration Planning, several Parts later, when it decides what can and cannot be sequenced.
My favourite scene in the book sits in Chapter 16. Astela's programme director, two weeks behind schedule, asks to skip straight from Technology Architecture to commissioning projects. He is not being obstructive; the pressure is real. The Chief Architect opens her notebook and draws a line down the page. On the left she writes what the request is right about. On the right, what would break if they did it. That two-column page is what tailoring the framework without breaking it looks like in practice, and it takes about four minutes.
The chapter most framework books leave out
The TOGAF Standard is contested, and I take the contest seriously. Chapter 17 is given entirely to the three strongest cases against it: its weight against continuous-delivery cadences, the questions about adoption failure and return on investment, and the alternatives some argue do the job better. Each one appears in the form its most serious advocate would recognise, next to the framework's documented response at the same depth. Then the chapter stops. It does not tell you who wins, because the answer depends on conditions only you can see.
Chapter 19 follows that through to the decision most practitioners are never taught to make. It opens with an eleven-line brief for an architecture engagement that names a timeline and a budget. Four questions go unanswered: what the architecture is for, who governs compliance with it, why this timeline, and whether the organisation wants architecture or the appearance of it. The chapter shows how to tell substantive adoption from ceremonial adoption before you commit. It also shows how to recognise when an engagement should not yet proceed at all. Saying "not yet" to a sponsor is a professional skill.
What it is, and what it is not
It is a field guide for Chief, Enterprise, Domain and Solution Architects who apply the TOGAF Standard, 10th Edition, in real organisations under real constraints. It assumes professional intelligence, not prior knowledge of the framework, and defines every acronym on first use.
It is not exam preparation; The Open Group's own materials handle certification. It is not a sales pitch for the framework, and not an argument against it either. The book is independent of, and has not been reviewed, approved or endorsed by, The Open Group.
Why I wrote it
I have spent more than thirty years in architecture, security and technology leadership in New Zealand. In that time I have come to treat the work as a form of kaitiakitanga: stewardship of something that is not yours. It is done on behalf of people who will never see the architecture and should never have to. They see whether the service works.
This book is the practitioner's half of the method, written down, so that the next team in that room has an answer ready when the sponsor asks. Enterprise Architecture in Practice is out now on Kindle and in paperback, with the hardcover to follow [2]. Assume Breach, built from the EA Thursday chapters, follows on 9 January 2027.
So I will ask you the question the book is built on. What did your last sponsor ask that the method could not answer for you?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Enterprise Architecture in Practice: A Field Guide to Applying the TOGAF® Standard is available now; Assume Breach, built from the EA Thursday chapters, follows on 9 January 2027. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
TOGAF is a registered trademark of The Open Group.
[1] The Open Group. "The TOGAF® Standard." https://www.opengroup.org/togaf
[2] Hamberger, Andreas. Enterprise Architecture in Practice: A Field Guide to Applying the TOGAF® Standard. Te Pono Limited, 1 November 2026. https://www.amazon.com/stores/author/B0GTPK7MXL/allbooks