Enterprise Architecture Frameworks: Structure Without Religion

Why choosing one EA framework is usually the wrong starting point—and how to use frameworks as practical building blocks instead

Sep 08, 2026

My career in enterprise architecture (EA) actually started with frameworks.

Back in 2006, I was finishing my student exchange abroad and trying to find a job—without much luck at first. Eventually, I scored a researcher position at the University of Jyväskylä in a project on EA quality management. I knew pretty much nothing about EA at the time, so well before my first day, I was handed Jaap Schekkerman’s How to Survive in the Jungle of Enterprise Architecture Frameworks.

The appropriately named book compares 14 different EA frameworks. I remember reading it and thinking: is this really what EA is all about?

(As a side note, the university copy got ruined when a gift bottle broke in my backpack on a return flight from UK. I had to buy them a new one.)

Almost twenty years later, I still find EA frameworks interesting, but I am also quite critical of them. In my own EA book, I deliberately skip the usual framework tour. There is a good reason for that, and I will get back to it later.

Instead of asking which framework is the best, I think we should start with a simpler question: what are we actually trying to structure here? In this article, I look at the roles EA frameworks can have, why they differ so much, and how to use them without making the framework itself the main goal.

A Framework Is Not Enterprise Architecture

EA is a strategic approach to managing change. It helps an organization understand its structures and dependencies and supports planning and decision-making. I explore what EA actually includes—and where its boundaries should be—in a recent article.

An EA framework is something more limited: a generic structure for supporting architecture work. It may help define what to describe, how architecture work is organized, and how the resulting models are represented.

The distinction sounds obvious, but it matters. It is surprisingly easy to start talking about TOGAF as if TOGAF and EA were more or less the same thing. From there, architecture work can gradually turn into implementing a framework rather than solving the organization’s actual planning and development challenges.

That happens surprisingly easily with frameworks, methods, and tools. People start discussing whether something is “TOGAF-compliant,” whether the correct phase has been followed, or whether a particular notation is used properly. All of these can be relevant questions, but only after the more important one: does this help us understand or change the organization?

I would rather treat a framework as a toolbox. Use what helps, understand why it helps, and leave the rest alone.

Three Kinds of Structure

One reason the framework discussion gets confusing is that very different things are called frameworks. I find it useful to separate three kinds of structure.

The first is content structure: what architecture consists of and how its different viewpoints and elements are organized. This may include capabilities, processes, information, applications, technologies, and the relationships between them. TOGAF, Zachman, ArchiMate all provide some structure of this kind.

The second is method: how architecture work is actually done and used. This includes processes, roles, governance, and ways of connecting EA with planning and development. TOGAF’s Architecture Development Method is probably the most familiar example.

The third is notation: how architecture is represented. ArchiMate is the obvious EA example. I can confess I am a fan. It provides a consistent language for high-level architecture models without forcing every architect to invent their own collection of arrows, boxes, colors, and symbols. BPMN, UML, and C4 solve related representation problems in somewhat different areas.

Then there are reference architectures, which are often mixed with frameworks. A reference architecture provides generic architecture content for a particular domain or solution area. A framework mainly helps organize architecture work; a reference architecture gives you something more concrete to as a basis for your modeling. To make things more confusing, some frameworks also come with quite a bit of reference content. TOGAF includes reference models for technology and information infrastructure, while the US Federal Enterprise Architecture (FEAF) has gone considerably further with common reference models for business, data, services, technology, and performance.

The borders are naturally fuzzy. This is EA, after all. Some terminological suffering comes with the territory.

The Framework Jungle Is Still There

There are plenty of frameworks and framework-like approaches around: TOGAF, Zachman, Lean EA, FEAF, EDGY, DODAF, E2AF, EA3 Cube, and others. Especially in the early 2000s, new EA frameworks seemed to appear like mushrooms after rain.

Even in a small country like Finland, the public sector has been surprisingly active in developing its own approaches. We have had frameworks and official recommendations such as JHS 179 and, more recently, the Suomi.fi EA framework.

They are also quite different. Some mainly structure architecture content, some provide methods for doing architecture work, and some focus on notation. Many cover more than one of these areas.

Diagram grouping enterprise architecture frameworks into three overlapping categories: taxonomy and ontology, method, and notation, showing that frameworks such as TOGAF, Zachman, ArchiMate, and others serve different and partly overlapping purposes. — The world of EA frameworks (classification by the author)

TOGAF, for example, combines a development method with content structures and plenty of supporting material. ArchiMate focuses on modeling: it provides both a high-level structure for organizing architectural viewpoints and a more detailed notation for describing elements and their relationships. The Zachman Framework, in turn, is better understood as an ontology: it provides a systematic way to classify architectural descriptions. EDGY is an interesting newer approach that combines perspectives from EA, enterprise design, strategy, and service design. It goes beyond a modeling language by also offering practical guidance and patterns for collaborative enterprise design.

So, which framework is best? I would probably avoid that question.

Do Not Choose a Framework

Frameworks have obvious benefits. Someone else has already spent considerable time thinking about architecture structures, methods, terminology, and good practices.

But also have equally obvious limitations.

There are too many alternatives. Generic frameworks cannot take into account the goals, maturity, organization, existing governance, or very practical realities of your organization. Many are too heavy to use as they are. Some are theoretically elegant but become rather thin when you start looking for practical examples.

My recommendation is therefore somewhat paradoxical:

Do not start by choosing a framework to implement. Start by identifying what you actually need, then use suitable parts from one or more frameworks and complement them with other good practices.

This is not even contrary to what the better frameworks recommend. TOGAF, for example, is explicitly meant to be tailored to the organization and the situation.

For example, you might use ArchiMate as your modeling language, TOGAF for high-level development phases, and selected EDGY practices for collaborative enterprise design. Then combine these with whatever already works in your organization.

In any case, the parts still need to fit together. In practice, this means agreeing on a reasonably consistent terminology, content structure, and way of working—and documenting these choices in your EA operating model.

There is little reason to reinvent these things. At the same time, I would not create yet another generic framework and give it an impressive acronym. The world has enough of them already.

Instead, design an EA operating model for your organization.

Build the Operating Model You Actually Need

The operating model should explain, in practical terms, how EA is maintained and used in your organization.

At minimum, I would think about the goals and scope of EA, organizational commitment, integration with other functions, architecture content, resources and skills, and working methods and tools.

In any case, keep it lightweight. But not too light. A reference to TOGAF or some other framework is not enough. Someone still has to decide what the framework means in your organization.

The integration with other functions is probably the most important part. EA is not some enormous parallel management function. It should support and connect with strategy implementation, process development, project portfolio management, IT service management, security and risk management, and IT development.

The same principle applies to architecture content. Define what you need and keep the structure simple. A capability map, process map, major data entities, application map, information flows, and technology platforms already take you surprisingly far. Add a simple metamodel so that the relationships between these elements remain understandable.

Use the Structure, Skip the Religion

EA frameworks contain decades of useful thinking. Ignoring them completely would mean repeatedly solving problems that others have already solved.

At the same time, following one framework religiously creates the opposite problem.

The practical middle ground is to understand what your organization needs, take the best available practices, and document how they work together in your EA operating model. For me, that is the useful structural view of EA frameworks.

Frameworks provide structure for content, work, and representation. They give us a common starting point. Some have even become de facto standards: for example, TOGAF and ArchiMate are the obvious frameworks worth knowing and, if certifications matter to your work, probably the ones worth certifying in. But none of them is EA itself.

Twenty years after starting my career with a book about surviving the framework jungle, my advice for surviving it has become fairly simple:

Take the useful tools with you. You do not need to take the whole jungle.