I have said it before: the TOGAF Standard is awesome. If you make an effort to really understand the framework you will agree with me. Unfortunately, despite being around for thirty years, it is still often rigorously misunderstood and misinterpreted. And it is these misinterpretations that lead to the myths that circle the framework. That is why it is high time to start mythbusting the TOGAF Standard.

Busting a myth means proving that a widely held belief or misconception is false or misleading. It involves presenting facts, evidence, or logical reasoning to clarify the truth and correct misunderstandings.

For example, if people believe that the TOGAF Standard is only for IT architecture, busting the myth would involve explaining that it actually covers business, data, application, and technology architecture, showing that it’s much broader than just IT. It’s a way of debunking false assumptions and replacing them with accurate information.

Debunking Common Myths

The TOGAF Standard is widely used in Enterprise Architecture, but there are many misconceptions about it. In this blog I’ll be debunking eight common myths that often lead to misunderstandings.

• TOGAF is an abbreviation of The Open Group Architecture Framework
• The TOGAF Standard is only for large enterprises
• The TOGAF Standard is a rigid, prescriptive framework
• The TOGAF Standard is only about IT Architecture
• The TOGAF Standard replaces other frameworks
• The TOGAF Standard is outdated and no longer relevant
• The TOGAF Standard is just about documentation
• The Architecture Development Method must be followed step-by-step

Are you ready for the facts? Here goes!

Myth #1: TOGAF is an abbreviation of The Open Group Architecture Framework

No, it is not. Not since the release of the 10th Edition anyway. Granted, the abbreviation has been used in the past, but ever since The Open Group launched its 10th Edition of the framework back in April 2022, they updated the legal policies around it saying that the abbreviation is not to be used anymore. From that point on, the framework is simply called the TOGAF Standard.

Trademarks are not acronyms; they should not be spelled out, abbreviated, or used by themselves within parentheses or brackets.¹

Explicitly referring to the framework as a standard is actually a good thing. Given that The Open Group is an organization that develops, delivers, and maintains standards, the name fits perfectly.

To all the people out there who use ChatGPT to generate their articles for them: please read the output before posting it online. Using the ChatGPT definition of the TOGAF Standard is a dead giveaway of two things: you did not write the article yourself and you have not been keeping up with the latest developements these past years.

Myth #2: The TOGAF Standard is only for large organizations

In practice, the TOGAF Standard is used with some regularity in many large organizations and less so in smaller ones. However, it is a misconception that the TOGAF Standard is only applicable to large organizations. In fact, the use of any framework is independent of the size of the organization. Every organization benefits from using an architectural framework.

Granted, not every organization will use a framework to the same extent, and not every organization will use an architecture framework as much, because there is not always a need to do so. Architecture frameworks – and the TOGAF Standard is no different – are scalable and adaptable to any situation and any size of organization. Providing insight, overview, and guidance for a structured approach to work is beneficial to any organization, large or small. Every organization should want to have its goals translated into the impact they will have on operations. An architectural framework such as the TOGAF Standard can be a tremendous help in this regard.

Myth #3: The TOGAF Standard is a rigid, prescriptive framework

Contrary to what most people think, the TOGAF Standard is a very flexible framework. It does not follow a strict set of rules, and organizations are free to tailor it to their specific needs rather than follow it to the letter.

It is true that the TOGAF Standard is a very complete framework in the sense that it contains a lot of information on how to approach different situations and scenarios. This wealth of information is sometimes seen as something that must be followed to the letter. This is not true.

The essential scaffolding of the TOGAF framework is the concepts. Everything else in the TOGAF framework is either an example or a starter set to get you moving. If you do not like the example, then you can take advantage of the modular structure of the TOGAF framework and substitute it.²

The framework simply describes every possible component, entity, or concept that you may encounter in the practice of architecture. It does not mean that your architecture has to follow everything that is written in the TOGAF Standard. The framework acts as a blueprint that needs to be customized. After that, it can be applied as best suits the organization.

Myth #4: The TOGAF Standard is only about IT Architecture

When you look at the breadth of Enterprise Architecture, you can see that IT Architecture (or Technology Architecture as it is called in the TOGAF Standard) is part of the scope of the overall picture. However, Technology Architecture is only one of the four core architecture domains or segments that make up Enterprise Architecture. Business Architecture, Data Architecture, and Application Architecture are the other three segments.

The TOGAF Standard is an Enterprise Architecture framework because it addresses all four domains. It provides a holistic view of an organization.

The latest edition of the framework even references the BIZBOK Guide (amongst others) for its Business Architecture concepts and techniques³. The reason for this is that the content of this particular architecture domain is described in much more detail in the BIZBOK Guide than in the TOGAF Standard. Rather than duplicate the information, The Open Group decided – wisely, if you ask me – to refer to this other source of information.

Some people have argued in the past that because the framework was written by IT Architects, it must be an IT Architecture framework. That’s like saying that a painter can’t play cards or do laundry. It is one of the less solid arguments for why these people believe that the TOGAF Standard should be considered an IT Architecture framework.

Myth #5: The TOGAF Standard replaces other frameworks

Absolutely not. The TOGAF Standard does not compete with other frameworks like Zachman, SAFe, ITIL, or COBIT. In fact, sometimes it can be a good idea not to get all your architecture-related stuff from a single framework. The TOGAF Standard recognizes this:

Because the TOGAF Standard is a generic framework and intended to be used in a wide variety of environments […] it may be used either in its own right, with the generic deliverables that it describes, or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.⁴

The TOGAF Standard is all about providing generic deliverables by suggesting a generic approach to practicing architecture. If there are components from other frameworks that are better suited to your organization, it is certainly recommended that you use them.

Myth #6: The TOGAF Standard is outdated and no longer relevant

This myth also needs to be dispelled quickly. No, the TOGAF Standard is not outdated and certainly not irrelevant. Over the many years of its existence, the framework has continued to evolve. It now reflects modern architectural trends such as digital transformation, cloud computing, and agile methodologies.

Every few years, a new and updated edition of the TOGAF Standard is released. Each new edition addresses the shortcomings of previous versions and adds new content, trends, or techniques. Of course, the core content remains largely the same because it doesn’t change that much over the years.

It is remarkable that the TOGAF Standard is even criticized for its content. If you look at other frameworks, there is not one that is updated significantly more than once every few years. Unfortunately for the TOGAF Standard, which is the most famous framework in the world, it only gets this kind of criticism because of its fame.

Myth #7: The TOGAF Standard is just about documentation

In a recent LinkedIn post, I elaborated on this particular myth. Many architects think that doing architectural work means producing reams of documents. This all seems to be based on the idea that the TOGAF Standard is deliberately out to capture everything related to the profession and the work that comes with it. This assumption is completely unwarranted, as it is not stated anywhere in the framework.

The TOGAF Standard, of course, recognizes the need to document important matters such as agreements made at the beginning of architectural work. There are four architecture documents (see Figure 2) that need to be created. Each of the four architecture documents has a set structure that must be reflected in the documents. However, this does not mean that everything else regarding architecture work should be documented endlessly.

The cause of this confusion may be that architects think that every diagram, matrix, or catalog needs to be captured in the Architecture Repository. Perhaps not surprisingly, this is another misconception. The Architecture Repository should contain Architecture and Solution Building Blocks, not elaborate solution diagrams, matrices, or catalogs.

So in summary, the TOGAF Standard does not suggest endless documentation. This is one of the myths created by not properly understanding the framework and letting one’s imagination run wild.

Myth #8: The Architecture Development Method (ADM) must be followed step-by-step

Sadly, the Architecture Development Method graphic (shown in Figure 2) is still frequently misinterpreted as a linear, waterfall-style process. In reality, however, it is a logical method that groups key activities to clarify their relationships and information flow. The well-known graphic is a stylized representation showing these information flows. It is not a representation of an activity sequence.

The Architecture Development Method should not be understood as a processes model.⁵

The ADM allows the same amount of tailoring as the full framework does, and supports no less than four different types of iteration, which makes it suitable for any kind of situation. It is by no means limited to following it step by step.

The Explanation

There are three reasons why these myths exist. The most common is unfortunately a misinterpretation of the content of the TOGAF Standard. This is usually caused by not reading carefully enough what is described in the framework.

Number two is the use of one’s own imagination. Too often, things are simply made up because the reader of the TOGAF Standard is insufficiently capable of interpreting it correctly. People do not properly understand what they read and make something up (usually in a negative way) to cover up their own inability.

The third reason these myths exist is the continued use of outdated information. Often architects still cling to what they learned years ago when they took a now ancient TOGAF exam. Or they simply take information they heard somewhere and without giving it any further thought proclaim it as today’s truth. It’s actually funny when you think about it: the people who claim that the TOGAF Standard is outdated and no longer relevant are, in fact, outdated themselves.

The Score

And there you have it. All eight myths busted in less than ten minutes of reading. Myths: 0, Facts: 8. The TOGAF Standard vs. Ignorance: 1:0

1. The Open Group trademarks ↩︎
2. A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM ↩︎
3. Referenced documents regarding Business Architecture ↩︎
4. Using the TOGAF Standard with other frameworks ↩︎
5. A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM ↩︎