It's logical and complete and it can be flexible enough to adapt to different dimensions of scope so it is, in my opinion providing the most value in supporting programme management. To be honest I don't think that it is realistic to use any framework (be it TOGAF or any other one) in a full enterprise-wide scope. But for programmes, why not?
There are however some things in TOGAF 9 that have the retro look of a science fiction movie from the early 90's. In most cases they are optional and I think that they should not even be part of the framework. TOGAF should describe, not prescribe.
Here are some ideas that in my opinion would, so to speak, bring TOGAF 10 to the 21st century:
1. Get rid of the outdated (almost funny except that they aren't) reference models.
I mean, what is the meaning of the Technical Reference Model, shown below? I mean, really... "Graphics & Image"? "Operating System Services"? Maybe (and I'm not even sure about that) this had some meaning back in the far past....
(Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html)
And then there's the III-RM. Again...
(Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap44.html)
It's not even worth starting a discussion is it?
Rather, instead of these simplistic and rather useless reference models The Open Group should create a community that would itself create and update reference models for all sorts of different purposes. These could be, e.g. reference models for business intelligence, document management, master data management, high performance computing, big data, advanced analytics, cloud integration, you name it. From the reference models architects could then create their reference architectures, suited to the needs of their organisations.
2. Replace Architecture Building Blocks" (ABBs) for Application Services. ABBs just don't make sense. Solution Building Blocks (SBBs) are real components, while ABBs are supposed to be logical components. But what does that actually mean? Ultimately the customer needs a service, not a logical component.
The service can be realised by an SBB or it can also be outsourced for example. And that's all there should be to it.
3. Introduce Archimate as the "lingua franca" in TOGAF at all of the logical layers. It is now owned by The Open Group anyway... and it's really good, too.
4. Require methods for designing and evaluating architectures. Here I am thinking in terms of ISO2000 and ITIL. ISO2000 requires processes and ITIL describes them. In this case I would recommend the SEI methods ADD (Attribute-Driven Design) and ATAM (Architecture Tradeoff Analysis Method) at least.
