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

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):

• Zachman 
• SABSA 
• Business Technology Management (BTM) 
• DODAF
• COBIT – Part 1 | Part 2
• TMForum Framworx 
• C4ISR Architecture Framework
• CORBA 
• Enterprise Architecture Planning (EAP) 
• Federal Enterprise Architecture: Practical Guide – 
• FEAF 
• ISO/IEC TR 14252 (IEEE Std 1003.0) 
• NCR Enterprise Architecture Framework 
• ISO RM-ODP
• SPIRIT Platform Blueprint Issue 3.0
• TAFIM 
• TEAF 

 

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. 

Advertisements