TOGAF Demystification Series: TOGAF Doesn’t Play Well With Others

Fit Together

In this post in the TOGAF demystification series I will talk about how well or not so well TOGAF plays with other frameworks in the industry. In my last post this topic was brought up and I see it on the LinkedIn forums as well.

So let’s talk about this myth that TOGAF doesn’t play well with other frameworks. So what do I mean by that? The myth is that TOGAF is all about TOGAF or is monolithic in nature. This is far from the truth. TOGAF is a truly unique framework in that it really does embrace the notion of a better together story with other frameworks and approaches to solving problems. This better together story is all about bringing in other frameworks to complement, reuse and ultimately reduce the amount of duplicate methods in the industry. The thought process must be, if it works for them then it should work for us too. 

A great example of this is at the absolute core of TOGAF. A core concept of “Architecture” is not defined by TOGAF but rather by ISO/IEC 42010:2007 (formally known as IEEE 1471). Of all areas to define yourself and be justified, TOGAF doesn’t do so. It takes in the definition and applies it to the architecture framework. TOGAF provides guidance around the definition and meta-model given that it was created outside any one methodology / framework. 

Below is the actual text from TOGAF:

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 – ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts.

As you can see above, while many other frameworks feel that they have to make it their own in an self-interested type of way, this isn’t the case with TOGAF. There is clear evidence that that TOGAF is doesn’t have the “must be invented here” syndrome  and will not duplicate the approaches in other methods. I applaud them for that level of leadership in the industry where it is a common practice in the overall technology and architecture fields respectively to do deliberately duplicate meanings, approaches and overall methods for doing things. 

One last area of note, in most phases in the ADM the first step is essentially to establish how you want to perform that phase. In this step you as the EA are to select the methods, approaches, reference models, architecture or standards and apply them to the problem you are solving in that phase. This is essentially saying is:

  • Not every architectural problem needs a prescriptive process. 
  • USE YOUR JUDGEMENT when applying architecture process and rigor.
  • If TOGAF doesn’t have something that solves your problem fill the gap.
  • Reusable architecture building blocks are the key to accelerating predictable results, TOGAF is architected to support this.

Lastly, TOGAF has published many mappings to other frameworks. In the specification you can find references to ISO, IEEE , PMI, Zachman and DODAF to name a few.

Below is a listing of some of those mappings (not all inclusive):


Note: Some of these mappings were done with older versions of TOGAF. However, there should be minimal gaps and provides the intent of a better together story. 

0 thoughts on “TOGAF Demystification Series: TOGAF Doesn’t Play Well With Others”

  1. Mike,
    In the past couple of years we have worked on a series of integration or interoperability whitepapers instead of simple mappings – SABSA/TOGAF, TMForum Frameworx, DODAF 2 and BIAN (Banking Industry Architecture Network).
    The integration approach is aimed at clarifying how you take the best. The root of this work was the Open Group’s SOA/TOGAF Practical Guide


  2. @DaveHornford Thanks so much for commenting and providing these resources.
    I tend to agree with you on this. Its more than just about mapping these frameworks but really understanding the value of what these resources bring back. I started to talk about it early in the post and then simply referred to them as mapping documents.
    If you could post the links to these I will make sure they get in the main post from the comments section.
    Thanks again!


  3. Hi Mike,
    Although these frameworks exist, there doesn’t appear to be an agreed structure to classifying assets. For example, I’m working on a project that needs to model stakeholders, artifacts such as catalogs of servers, applications and the like. What’s a base template to package these e.g. Artifacts > Catalogs > Servers?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s