I recently passed the TOGAF 9 Certification exam. The process of studying the TOGAF material really did help to give a clearer context of the role of an Architect and how to do my job better. The content was a thick yet generally readable 800 pages and I also took a course from “Architecting the Enterprise”, which I highly recommend.
I decided to become certified in TOGAF 9 because it is generally accepted as the most well-known and respected framework for Enterprise Architecture out of the 75+ existing architecture frameworks. This doesn’t mean, however, that the TOGAF 9 is readily applicable out of the box – and it is acknowledged in the “Preliminary Phase” to customize the framework as needed before beginning the work in the ADM (Architecture Development Method). In fact, almost all other existing architecture frameworks could be viewed as some derivation and modification of the TOGAF.
The framework is very thorough and would certainly benefit an architect to have a deep understanding of it. At the same time, however, there are other frameworks (e.g. PEAF) that are simpler and easier to teach and use out of the box.
Two key concepts that the TOGAF could improve upon:
1) Phase G – “Implementation Governance” – By calling out governance during implementation, TOGAF is missing the boat in terms of emphasizing the governance needed BEFORE implementation (Phases A-E). For example, during Phase E, when solutions are first considered, there may be various solution options to choose from – ranging from the most strategic to the most tactical. Continuing with this example, the most strategic decision may cost $20M while the most tactical decision may cost $100K – and there may be options in between the two extremes. It is the job of the architect to define the various solutions options. A governance board which includes key executives should then make that important investment decision. This type of governance is equally if not more important than “Implementation Governance” in Phase G and therefore TOGAF 9 needs to change to better emphasize governance throughout the entire ADM.
2) Estimation – “Just give me a number”- In companies where products are heavily or entirely based on software/web, often business executives or product people just want to know – how much will it cost to build? This question is first asked at product conception before requirements and any of the key phases in the TOGAF such as phases B-F. An important concept that is unjustly buried deep under the 800 pages of TOGAF is that cost estimation becomes more accurate as each ADM phase is completed. For example, in Phase B we will have gathered key processes and requirements and in Phase C we become aware of the key logical application and data components. The outputs from Phase B & C is potentially sufficient detail to provide a cost estimate with, say, 70% confidence. The technology view from Phase D and the solutions in Phase E potentially enables a cost estimate with 90% confidence. The key point: From a CEO or business executive’s point of view, a big reason to “do TOGAF” or Enterprise Architecture is to define to sufficient detail the strategy, architecture, and solution (via diagrams, matrices, and views), so accurate costs can be estimated, to make go/no-go decisions of major initiatives, and to support optimal program and implementation project planning.
Eric Weinstein, MBA 