Models That Matter.

What the book is about

Two architects, given the same problem, will produce different artefacts. That's expected. Two architects, given the same problem and the same tool, will still produce different artefacts — and the tool will have shaped the difference more than the problem did. Most architectural tools are built around an assumption about what the architect is doing that turns out to be wrong, and the architect ends up working around the tool rather than with it.

Models That Matter is about what those assumptions are, where they came from, and what the actual work of architectural modelling looks like once they're identified. It draws on twenty years of practice across telecom, banking, government, and SaaS; on the academic literature that took architectural representation seriously (Kruchten, Rozanski & Woods, the early ArchiMate work); and on a careful look at why the tools the industry produced have drifted so far from what working architects need.

The book is a sustained argument, not a how-to. There are concrete examples and named techniques, but the core proposition is a way of thinking about what a model is for and what tools should do to support it. Architects who finish the book will recognise a lot of their own practice in it, and have new language for things they already do.

Chapter outline

The full chapter list will be confirmed at publication. The chapters with definite shape today:

1. 01
   The work architects actually do Seven distinct purposes architects model for, and why treating them as one purpose is the original sin of modelling tools.
2. 02
   The shape of an architectural artefact Formality and detail as the two-dimensional space every architectural artefact lives in. Why movement across the space is the architect's actual work. Available now as a blog post
3. 03
   Three layers of element identity A principled account of what a model element actually is. Why the same element appearing on multiple diagrams is the same element, and how to design a metamodel that respects that.
4. 04
   Artefact boundaries and delegation What does an architectural artefact own, what does it reference, and what does it delegate? A working theory of artefact boundaries that survives across projects.
5. 05
   Notation pluralism and the principled metamodel ArchiMate and UML can live inside the same metamodel. Why a tool that supports both natively is built differently from one that picks a side.
6. 06
   Modelling in the age of AI agents LLMs can read and write structured models in ways humans find tedious. What does it mean for the tool, and the practice, when the artefact is partly authored by a reasoning system?

Additional chapters cover validation, cloud profiles and visual variance, navigating large models, versioning without branching, and viewpoint design. Final chapter list will be confirmed at publication.

How the book and the tool reinforce each other

EOModeller implements the method Models That Matter describes. The book chapter on the formality–detail quadrant corresponds to the quadrant picker on every diagram in EOModeller; the chapter on three-layer element identity corresponds to the metamodel that lets one element appear on many diagrams without being duplicated; the chapter on notation pluralism corresponds to the unified UML + ArchiMate metamodel.

Neither stands alone. The tool without the book is "another modelling app"; the book without the tool is an argument without a worked example. Together, they're a method and the means to practise it.

Audience

The book is written for working architects, senior developers moving into architectural roles, and the academic and industrial audiences that care about architectural representation. It assumes familiarity with one or more modelling notations (UML, ArchiMate, C4, ER) but doesn't require expertise in any. It is not an introductory text on UML or ArchiMate — there are good books for that already.

How to get it

The book is in draft. Sign up to the early-access programme to be notified when chapters land on the blog and when the full volume is available. We'll publish through the channels architects actually buy books through (Leanpub, then traditional publishing if interest justifies it).

No mailing list other than that. We'll send you a note when the book is out; we won't send you anything else.