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.
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
LikeLike
@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!
LikeLike
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?
LikeLike