Copyright Avancier Limited. All rights reserved.
TOGAF is not an easy read. TOGAF’s strength derives from it being a multi-authored product. That creates challenges for editors.
For example:
· TOGAF 7 focuses on strategic IT architecture. It maps technology building blocks directly to business goals and business strategy, largely without reference to applications.
· TOGAF 8 is a much wider enterprise architecture framework that firmly places applications architecture between business architecture and technology architecture.
· Much of TOGAF 7 appears within TOGAF 8 – largely unchanged – as phase D. That is mostly a good thing, but not entirely.
TOGAF 7 and 8 share the same philosophy. They both bang on about the importance of defining business goals and strategy, and tracing architecture building blocks to them. They stress the futility of developing an IT architecture that is not traced to measureable business goals and objectives. They promote the use of business scenarios to identify business requirements and engage business people with architecture descriptions.
But different authors, some of them writing years apart, use the same words in different ways. Not every author can be a first-rate writer. Not every author can fully understand all of the material they are extending, and fully appreciate how old and new contributions might be integrated. Not every editor recognises every place they need to update older contributions.
I believe that is largely why TOGAF is a tough read. And you need to go on proper TOGAF training course if you want to use it.
We recommend TOGAF for enterprise architecture. It has to be every enterprise architect’s starting point and default approach. Our implicit TOGAF 8 meta model gives you some idea of its core. But it has a much wider scope than the meta model reveals.
We are aware of TOGAF 9 and will update this advice after that is published.