How to Use TOGAF Without Becoming the Archetype of Its Adherents

I recently came across a post on LinkedIn about Enterprise Architecture. It started by listing all the major frameworks just to posit that a real practitioner must master all of them.

This résumé disguised as scholarship never mentioned outcomes, results, or delivering value. It presumed the frameworks’ intrinsic value was what mattered, along with knowing them as thoroughly as the author.

So, given the middle-school underpinnings of my sense of humor, it reminded me of the Underpants Gnomes of South Park,² those earnest, silly figures with a famously incomplete business model.

The Gnomes give us a fitting metaphor for the belief that just naming and collecting things can substitute for the hard part, the work that actually matters. 

And nowhere in Enterprise Architecture is this clearer than in the prominence TOGAF holds as the framework that’s invoked to prove the need for architectural seriousness in large organizations.

What Is TOGAF? Overview of the Enterprise Architecture Framework

The TOGAF Standard, the Open Group Architecture Framework, provides a structured approach to planning, designing, and governing complex enterprise environments. It is influential and often serves as the starting point for organizations pursuing Enterprise Architecture.

Its foundation is the Architecture Development Method (ADM), a structure for establishing architectural vision, developing domain architectures, and governing implementation.

TOGAF’s substrate includes things like content frameworks, governance guidance, and capability and maturity models that support consistent deliverables and informed decision-making. 

Together, these resources structure artifacts and requirements and ostensibly help organizations engage with stakeholders, manage complexity, avoid duplication, and, at least I’ve heard, align technology with the business.

The ADM sits at the center of this framework and is the mechanism through which TOGAF attempts to translate theory into practice.

How the TOGAF Architecture Development Method (ADM) Works

The TOGAF Architecture Development Method is an approach for defining, planning, and governing an organization’s business, information, and technology architectures.

The Nine Phases of the TOGAF ADM

It consists of nine phases, summarized here:

Together, these phases, plus a requirements management core, outline a path from intent to implementation. Yet their practicality, like that of most conceptual processes, can be elusive.

Using TOGAF in Practice: Where It Helps and Where It Doesn’t

So what is TOGAF actually good at? Where does it help, and where does it get in the way?

I’ve used TOGAF many times, but as a resource rather than in strict adherence to its prescriptive formulation as a framework, method, and methodology.

It’s helpful as a canonical set of architectural concepts. The architecture states—baseline, target, transition—are conceptual but important, and TOGAF saves you from reinventing these types of fundamentals.

But TOGAF is not a secret key to enterprise clarity, nor is it definitive for strategy, architecture, or governance. Yet, used pragmatically, it can be helpful, much like the comprehensive guidance and templated artifacts available from Gartner.

In capable hands, TOGAF can help. In rigid ones, it can become ceremony, or even bureaucracy. And in the wrong hands, its structure can turn into dogma and its methodology can become self-referential and performative, as with our hero in the LinkedIn post.

The Problem with Overly Theoretical Enterprise Architecture Frameworks

In The Latin of Enterprise Architecture: The Zachman Framework Is Historically Significant but Rarely Used, I mentioned that when asked how to implement the Zachman Framework, John Zachman said that’s like asking how to implement the Periodic Table of Elements.

If the Zachman Framework is the periodic table, TOGAF is the Unified Theory of Everything³—an ambitious attempt to explain and organize the entirety of an organization through the lens of Enterprise Architecture.

I’m going to repeat that last part because it’s critically important: through the lens of Enterprise Architecture. We will come back to this in an article about Business Architectures, a central but deficient aspect of TOGAF theory.

This conceptual ambition—and conceptual excess—has the predictable side effect of evaporating anything resembling concrete practice, which can significantly damage the credibility of Enterprise Architecture efforts.

So it’s because of this comprehensiveness that it’s hard to define what TOGAF is in pragmatic terms. I actually know many practitioners steeped in the TOGAF way who struggle to even define Enterprise Architecture in the first place.

Also, using TOGAF pragmatically is easier said than done, especially if your goal is, like mine, to make a computer do something. Much of TOGAF’s structure and substrate is ethereal: conceptual processes, capability maps, meta-models, and transition states.

And, it’s these abstractions that form the slippery slope that can lead Enterprise Architecture away from reality in large organizations. Colloquially, that’s the dreaded Ivory Tower. But, it’s more fun referring to it as the Underpants Gnomes Model of Enterprise Architecture.

Because There’s Always One More Method: TOGAF, Zachman, and the Culture of Enterprise Architecture

We’ve now covered TOGAF, the Zachman Framework, and many of the earlier architectural and systems-engineering traditions that helped shape modern Enterprise Architecture.

Seen together, I hope you’ve noticed that they reveal as much about the culture of Enterprise Architecture as about the approaches themselves, which leads us to the next topic.

I hope you’ll join me in our next article, Agile and Enterprise Architecture Discourse, In Practice. While Agile isn’t an Enterprise Architecture framework, it’s adjacent to the discipline and important. See you then.

Notes:
1. Image generated with Google Gemini and OpenAI ChatGPT.
2. South Park (Comedy Central, 1998). Season 2, Episode 17: “Gnomes.” Home to the Underpants Gnomes’ enduring contribution to management theory: a strategic model that moves briskly from inputs to outcomes while leaving the operative middle in a state of elegant ambiguity.
3. Theory of Everything (Wikipedia) accessed July 22, 2025.