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.

Iterative architecture development and tooling

I have recently blogged about the work on enterprise architecture by Tom Graves, an independent consultant from Tetradian. Tom has authores several books, including Real Enterprise Architecture - Beyond IT to the whole enterprise (see the books section of Tetradian). I had briefly scanned this book before, but I'm currently reading it cover to cover and must say that I'm increasingly enthousiastic about it.

The core assumption in the book, as in many books on architecture, is that the enterprise is a system. Architecture, then, is a property of the system: 

Architecture is the integration of everything the organization is or does.

As many books on architecture, this book also uses a framework. This one, however, focuses not only on results (e.g. Zachman) or process (e.g. TOGAF's ADM) but on both. So far the meat of TOGAF has always been the ADM. I'm not exactly sure how good the content-framework of TOGAF 9 is as I haven't studied it in detail yet. More on that soon. Either way, a other strong points about this framework are the iterative nature, allowing several degrees of freedom in developing architecture, considering architecture maturity as part of the framework etcetera. The core of the approach is illustrated by the following figure:

Requirements (with respect to the architecture) play a central role in the framework. Even more, 5 distinct views on the architecture are considered to derive / structure these requirements. These 5 views are dubbed the 5 p's: People, Purpose, Preparation, Process, and Performance. As architecture is assumed to provide a holistic view on the enterprise, each of these views includes, within itself, a sense of all perspectives as illustrated by the following figure:

This "sensse of all perspectives" has a slight twist, leading to the keywords Elegant, Appropriate, Efficient, Integrated, and Reliable. This leads in total to 25 perspectives on the enterprise architecture, each with its own theme. For example:

• Purpose - Appropriate : focuses on the goals of the architecture function in the organization
• People - Elegant : focuses on the composition of the architecture team
• Preparation -Effective : focuses on the effectiveness of the archtiecture efforts in the context of the organizational goals (mission/ vision/ straegy)
• Performance - Reliable : focuses on the rol of real-time scoreboards / dashboards 
• Process - Integrated : focuses on managing services in the broadest sense of the word.

For each of the perspectives the role with respect to deliverables is discussed. This got me thinking: there are a lot of architecture frameworks out there (Zachman, FEAF, IAF, TOGAF, DYA). Most of the mare "cell orriented". Different stakeholders of the architecture require different views on the contents of these cells (to put it differently: filling the framework is the 'homework' of the architecture team. The team should also prepare different views on the framework for specific stakeholder groups). It isn't always apparent how the contents of the cells are "transformed" into deliverables by the architecture team. 

Working with different views on data is relatively well research in e.g. the database community. Even more, transforming information / documents is also relatively well researched (see e.g. my dissertation Aptness on the Web). It would be interesting to see how these two fields can be combined in the context of enterprise architecture documentation. 

(Perhaps this is a nice topic for students to work on as it contains a practical component as well as a theoretical one. If you're interested, please leave a comment or send me an E-mail!)

Paper accepted at PRET'09

Last weekend I received word that my paper for the PRET'09 conference is accepted with some minor revisions to implement. The abstract of my paper is as follows:

The relationship between strategy and enterprise architecture is troublesome in many organizations. It seems that this cumbersome relationship is similar to the more ‘traditional’ tension that seemingly exists between business and IT. This paper explores three underlying causes of this tension, most notably (1) overlap in domain of expertise, (2) different languages and (3) different underlying worldviews. It is argued that there is no single solution to resolving this tension. Instead, the tension should be seen as a polarity that must be managed continuously. Only by ensuring that both groups of practitioners have a shared understanding of the issues that the firm faces and are committed to resolving them together can the tension between these groups be relieved.

I'm looking forward to presenting my work on the conference in Amsterdam, esepcially since I know that several other interesting papers will be presented there. Hope to see you all in Amsterdam!