This article describes some of the the strengths and weaknesses of TOGAF. Please note that these relfect our opinion which is based on our experience of using and applying TOGAF for the past 15+ years. TOGAF Strength
The primary focus of what TOGAF intended to resolve is also it strength. We are talking about the TOGAF ADM. The Architecture Development Method. This is by far the strongest side of TOGAF. A process like framework on how to develop architectures.
The Open Group who manages the TOGAF was able to create a strong community. This also aided in the credibility of the framework. Further-more the open community aspect of it is also a strong asset. All of this together is definitely considered a strength.
TOGAF also did a good job at calling out the need for EA Governance, a critical part of the enterprise architecture journey. You can break EA Governance further down into Compliance Assessments and Architecture Decision Logs.
They also did a good job at creating an initial list of 75+ enterprise architecture artifacts that could be created by architects during the ADM. This is referenced as the Architecture Content Framework within TOGAF. Now the flip side of this also created a weakness (see below).TOGAF Weaknesses
Would rather call these areas of improvements (It seems to be in our genetics to focus more on the things that could be better).
The structure of the repository is not well defined inside TOGAF. Referring to the Enterprise Continuum and Architecture Repository sections of TOGAF. I think any experienced TOGAF practitioner will agree that these areas are not very useful, they are missing depth and practical usages.
Lack of templates, probably the most heard complaint. TOGAF defined 75+ artifacts (deliverables, matrixes, catalogs, and diagrams) but doesn’t include a single template for any of these. Obvious room for improvement here.
As we called out in a previous article already the TOGAF is ignoring the Solution Architecture side of architecture. It basically stops at the implementation level (with the exception of EA Governance which does get applied at the implementation level). This should be considered a significant gap and weakness in our opinion. The good news is that you can quite easily extend TOGAF and add in support for Solution Architecture. We have helped many clients do this.
The TOGAF framework is quite large in its totality and intended to be able to handle any kind of enterprise architecture initiative. However 95% of people using TOGAF will never use it in its totality. One of the first steps in TOGAF is ‘tailoring the TOGAF to your specific needs’ but this can be quite a daunting ask and is not as easy as it might sound.
Finally we conclude our list of weaknesses with a comment about the Standards Information Base. We actually anticipate this part to be removed from TOGAF in the future, maybe even in TOGAF 10 already. It is not clear what kind of standards would be managed inside the Standards Library, the opinions vary on this. There is also a confusing with the Reference Library section inside TOGAF. Some of these standards could easily exists as Reference Library items as well. At the end it is not clear what goes where.
Now let’s close this article on a positive note. TOGAF is by far the best enterprise architecture framework out there. Best supported, most complete, well adopted, flexible enough it can be tailored and extended to support your needs. Provide a great start into structuring your enterprise architecture practice and repository, the artifacts to produce, the process to use.
keywords: togaf, enterprise architecture, togaf strength, togaf weaknesses