What I Didn’t Include in the Book—and Why

Writing a practical guide to enterprise architecture means leaving a lot out. Here’s what didn’t make it in—and the reasons behind those choices

Nov 03, 2025

When you write a book about enterprise architecture (EA)—especially one that aims to be comprehensive—the hardest part is not deciding what to include, but what to leave out.

EA touches nearly everything: strategy, technology, governance, data, development, even culture. But no single book can (or should) try to cover it all. The real challenge is focus: helping readers do EA, not just read about it.

So here’s a look behind the scenes: what I deliberately left out of Enterprise Architecture – Your Guide to Organizational Transformation, and why.

What Was Left Out?

Even a “comprehensive” book needs boundaries. Some topics were simply not relevant, too broad, fast-moving, context-dependent, or better covered elsewhere. What follows isn’t what was forgotten, but what was left out on purpose, to keep the book focused on practice and usefulness.

1. Framework Comparisons

You won’t find a detailed comparison between TOGAF®, Zachman, FEAF, or other frameworks. Most organizations do not need another framework review—they need to understand how to apply the most suitable frameworks in a meaningful, context-aware way.

Frameworks can be a great source of ideas and structure. But instead of spending time comparing them or going through them line by line, it’s often more valuable to explore material that goes deeper into how to adapt and use them in practice—like this book.

2. Tool Reviews and Vendor Lists

Similarly, there are no tool rankings or vendor overviews (but I’ll give a few examples).

EA tools evolve faster than any book can, and no single tool is universally “the best.” What truly matters is making a fit-for-purpose choice: selecting a tool that matches your organization’s needs, maturity, and budget, without getting stuck in endless comparisons.

Instead, the book focuses on the essentials: how to approach tool selection systematically, what really makes a difference in practice, and why the real work begins after the purchase.

A tool is only valuable when it supports the architecture practice—when it helps people collaborate, maintain clarity, and make informed decisions. The key is to manage the tool as part of the architecture capability, not let it manage you.

3. Modeling Notation Tutorials

You’ll notice the book doesn’t include detailed tutorials on ArchiMate®, BPMN, or UML.

That’s intentional. There are already excellent guides—many written by the creators of these standards—that explain every symbol and modeling convention in depth.

Instead, I wanted to focus on what actually works in practice: which diagrams help people understand, align, and make decisions. Structure and standardization matter, which is why the examples in the book use a small, practical subset of ArchiMate®.

The aim was not to show every possible modeling option, but to demonstrate how just a few well-chosen views can make architecture visible and useful. Comprehensive notation references belong elsewhere.

4. Case Studies

I considered including full-length case studies—even discussed it earlier with the Finnish publisher—but decided against it.

Every organization’s context is different, and once anonymized, real-world cases tend to lose the richness and nuance that make them meaningful. The specific situations, challenges, politics, and personalities that shape outcomes rarely survive the editing process.

Instead, I chose to focus on patterns—what typically works, what tends to fail, and why—distilled from work with more than 40 organizations. Where a specific organization was needed to illustrate a point, I used a fictional example. A company that feels real, but isn’t any single one.

The goal was not to document past successes, but to share reusable insight, so that readers can recognize their own situations and act more confidently.

5. Methodology Recipes

You will not find exhaustive, step-by-step templates, project plans, or checklists in this book.

Architecture methods only work when they are adapted to context—to the size, maturity, and culture of the organization using them. A method that fits a global enterprise may overwhelm a small public agency, while a lightweight approach may frustrate a highly regulated environment.

The truth is that every organization discovers its own way of doing EA over time. There is no shortcut to that learning process. Yet, many of the underlying principles are universal: plan enough to create clarity and alignment, but not so much that you hinder learning or adaptability.

My goal was to help readers design their own rhythm rather than follow someone else’s recipe. You will find structure here, such as the components of an EA operating model, but not a fixed methodology. The book gives you the foundation and judgment to build one that actually works in your context.

6. Integrating Disciplines and Related Functions

The book does not include detailed instructions on how EA should integrate with every other management, development, or operational discipline—such as strategic planning, project management, or IT service management.

That omission is deliberate. These relationships depend heavily on each organization’s structure, maturity, and ecosystem. Integration cannot be achieved by copying a predefined model; it requires collaboration, shared understanding, and gradual alignment over time.

The focus of the book is EA itself—its purpose, content, and use in guiding change. Other functions are discussed only so far as necessary to show how the EA function interacts with them and supports decision-making across boundaries. The aim was to clarify how EA connects, not to redefine how those other disciplines should operate.

7. Prescriptive Architecture Content

The book also avoids prescribing what an organization’s architecture should include—for example, how to make it secure, agile, or modular.

There is no universal checklist or single set of qualities that defines a “good” EA. Perhaps it cannot even be defined at the EA level. Qualities such as customer centricity, security, or sustainability are not blueprints to be followed; they are outcomes that emerge over time from informed decisions, coherent design principles, and consistent governance. They also depend heavily on each organization’s context, culture, and industry.

Instead of offering templates, the book focuses on helping readers build the capability to think architecturally and maintain meaningful architectural descriptions: connecting choices across strategy, operations, data, and technology in ways that (in the best case) naturally produce those desired qualities.

8. Detailed Solution, Process, or Technical Architectures

The book does not dive into detailed solution architectures, process descriptions, or system-level designs.

That is a conscious choice. EA operates at a logical but relatively concrete level—connecting strategy, capabilities, information, and technology in a way that guides and constrains detailed design without replacing it.

Focusing too deeply on technical or process-level detail would blur that distinction and risk turning EA into an implementation discipline. The goal of the book was to stay at the level where EA adds the most value: defining structures, principles, and relationships that shape decisions across domains.

Those working on detailed architectures—solution, application, infrastructure, or process—are essential partners, but their work begins where EA guidance ends. My aim was to clarify that relationship rather than overlap it.

9. Academic Theory

Although my background is academic, I intentionally kept theory to a minimum.

The purpose of this book is not to argue definitions or refine conceptual models, but to make EA usable. There is a time and place for research (my PhD is proof of that), but this book was written for practitioners: for those who need to explain architecture to leaders, use it to guide change, and keep it alive in everyday work.

There is great value in theory, of course. Academic work gives us the language, structure, and rigor that the field depends on. But too often, theory and practice drift apart. My goal was to bridge that gap just enough to make complex ideas usable without turning the book into a textbook.

Why Leaving Things Out was Necessary

Writing a “practical guide,” even an ambitious one, required drawing clear boundaries.

Leaving things out was not about avoiding depth but about maintaining focus. I wanted this book to be something you could pick up on a Tuesday afternoon and actually use in a meeting that same week, not just admire on a shelf.

It is always tempting to make a book that tries to cover everything. But EA—like organizations themselves—only works when you decide what truly matters. In that sense, deciding what not to include was perhaps the most architectural decision of all.

Some of the topics I left out may still find their place later. Perhaps in future articles, workshops, or even another book. A deeper dive into tools, or an exploration of how AI is already reshaping the EA discipline, may be worth returning.

For now, this book had one mission: to make EA practical, human, and usable. A guide you can apply, not just read.

Over to You

If you have already read the book: what do you wish I had included?

Or perhaps, what are you glad I left out?

I would love to hear your thoughts before I start planning what comes next.

PS—For Finnish Readers 🇫🇮

For those who read Finnish, I have just released a new information package on enterprise architecture at kokonaisarkkitehtuuri.org.

It is largely based on the ideas from my book, but includes updated material and a large Q&A section. The goal is the same: to make architecture understandable, actionable, and relevant for real organizations—in plain Finnish.

Take a look, share it with your colleagues, and let me know what you think.