TOGAF 9 - what's new?

The new version of the Open Group's enterprise architecture framework TOGAF was launched earlier this month. So what's new that it offers enterprise architects, and how can we use it in practice?

TOGAF is almost the de-facto standard for the enterprise-architecture industry. There are plenty of other frameworks around, such as FEAF, DoDAF, MoDAF - and of course Zachman's ubiquitous taxonomy - but TOGAF is one of the few that combines framework and method in a single package.

Three years of hard work has gone into the new version, and it shows: compared to version 8.1, it's much easier to navigate your way around in the new modular structure, and find the information that you need. There's a lot more information, too: the book version is now almost 800 pages of fairly dense text and graphics. In addition to a cleaned-up introduction, it now has six distinct sections:

• Architecture Development Method
• ADM Guidelines and Techniques
• Architecture Content Framework
• Enterprise Continuum and Tools
• TOGAF Reference Models
• Architecture Capability Framework

The last two sections are carried over almost unchanged from the previous version, with the 'Capability Framework' as a much better-structured container for all the information on architecture governance and the like. There's a useful new chapter on setting up the architecture capability, but that's about it for that part of the revision.

The Enterprise Continuum section is also much the same as before, with its description of two parallel frameworks: the 'Architecture Continuum', which holds the information about abstract architecture in a spectrum from generic and industry-standards to enterprise-specific needs; and the matching 'Solutions Continuum', which holds an equivalent spectrum of implementation standards and patterns. Here again there are a couple of new chapters, one on architecture partitioning in 'federated' enterprises and the like, the other containing an overview of what needs to be included with an architecture repository.

Most of the new work has been in the first three sections. The well-known Architecture Development Method (ADM), with its eight phases in a 'crop-circle' layout, has been retained from the previous version, but the detail content has been cleaned up and extended, with most of the secondary information - such as chapters on architecture deliverables and building-blocks - moved to the new 'Architecture Content Framework' and 'Architecture Capability Framework' sections. The section on guidelines and techniques for using and adapting the ADM - such as the chapters on security architecture and service-architecture - is almost all new, as is the chapter on metamodels in the Content Framework.

If you haven't used TOGAF, the core idea is the ADM - a structured method for developing 'architectures', identifying opportunities for change, and implementing them through portfolio of projects following a defined 'roadmap'. It's a cyclical, iterative process, centred around requirements. In the first phase we set up the plan for the architecture cycle. Then in the next three phases we respectively explore 'Business Architecture' - which, to be honest, is mostly about business impacts on IT - followed by 'Information Systems Architecture', looking at data and applications, and finally 'Technology Architecture', which is about the physical infrastructure for ICT. We do an assessment for 'as-is' and 'to-be' in each case, followed by a gap-analysis.

In the next three phases, we build our 'roadmap', develop a migration-plan, and shepherd each project through to implementation. The final phase returns to architecture again, with a lessons-learned review, and an assessment of any changes in the business or technical environment that might call for another architecture cycle.

It all looks good, and the hard work that's been put in to this revision really does show. There are a few significant quibbles, of course: several of the new sections feel more like useful overviews than actionable guidelines; the descriptions of roles and responsibilities - especially in the implementation phases - can often be muddled and confusing, with the enterprise architect at times apparently responsible for everything from detailed solution-design to overall portfolio management; and the 'new' techniques of 'business scenarios' turn out to be all but identical to good old-fashioned business-analysis. Some of those concerns are fairly trivial, though, and could no doubt be fixed in a future point-release.

There is, however, one serious problem. As it stands, TOGAF is excellent for IT-architecture, and for the early stages of enterprise architecture which do revolve primarily around IT. But that strength in IT soon becomes a serious weakness when we try to apply TOGAF beyond that rather narrow scope. For industries that are not centred on information, or for later-maturity enterprise architecture in any industry, the present structure of TOGAF soon becomes more of a hindrance than a help. This is a major disappointment for those of us who work in those latter business contexts - the kind of architecture work that may still be rare in seemingly IT-obsessed countries such as Britain or the US, for example, but is almost routine now in many other countries such as Australia, South Africa or the Netherlands. Even though the new version has been billed as an evolution rather than a revolution, we had hoped for more from this redesign.

It's true that some parts of the new version - such as the chapter on Capability Based Planning - do break out somewhat from the rigid IT-centrism of Version 8.1, but overall it's still not enough to make a significant difference. The metamodel in the Content Framework, for example, would in practice be usable only for IT-architecture; it also has no support for any form of versioning, which rules out its use for the kind of Agile-style development that's essential in later-maturity architecture. And the fixed IT-oriented scope inherent in the current ADM - with 'business architecture' still essentially a random grab-bag for "anything not-IT that might affect IT" - actively thwarts any attempt to use the method for anything with a broader strategic or whole-of-enterprise scope.

As I've documented in my own enterprise architecture books - such as "Bridging the Silos: enterprise architecture for IT architects" - there are ways to work around these structural flaws in TOGAF. But given that there is an increasing consensus that enterprise architecture must move beyond its roots in IT, that fact that these known problems were not resolved in the new version represents a missed opportunity that could well haunt the profession for many years to come. A pity - to say the least.

In summary, TOGAF 9 is a definite leap forward - for IT-architecture. But whilst the new version is definitely useful beyond IT, enterprise architects may still have to look elsewhere for the methods and frameworks that we really need.