Well, it is February 2nd, and today, the Open Group is announcing the general availability of TOGAF version 9.0.  For those of you not familiar with TOGAF, it is an ambitious and maturing Enterprise Architecture Framework created by the members of the Open Group.

I’ve had the good fortune to be allowed early access to the TOGAF 9.0 specification, so while most of the readers of this blog will be seeing TOGAF for the first time today, I’ve been typing these notes for about a week now.  This is going to be a bit of a random discussion of good points and opportunities to improve the TOGAF, now that their new direction is clear.

Overview and Impressions of TOGAF 9.0

I’m not a certified TOGAF practitioner.  That caveat aside, I am someone who has studied multiple frameworks, and created an architectural framework, so I can draw on a good bit of experience when reviewing one.  I spent some time reviewing the prior version of TOGAF, and my first impression of the new version is this: Substantial and Deep Improvements.

The new version has a comprehensive model for the content, insuring that the stakeholders for architecture have separate sections of the framework dedicated to each of their varied concerns.  This makes navigation and adoption considerably easier.  In addition, substantially new content, along with new models and a richer set of descriptions, have been added.  The new framework is more readable and more usable than it’s predecessor.

The focus of TOGAF 9.0 has been sharpened, drawing the distinctions between different concepts and activities into the light.  This was needed for strategic architecture to be successful in to TOGAF model.  The terminology is more consistently described and used, and the attention to detail is refreshing.

The TOGAF is, and probably always will be, a work in progress.  It is a community effort, and the community that worked on this version have expended considerable effort.  That effort shows.  I really like where this framework is going.

Here is my call to action: for the first time, I’m willing to say this: The TOGAF is enterprise ready.  If your organization does not have a framework, or if you are using Zachman with some home-grown methods, I recommend that you serious consider TOGAF 9 for adoption. 

Specific things that I appreciate

The use of a metamodel

While the TOGAF metamodel is new and untested, I strongly appreciate that the framers of TOGAF were aware of metamodels at a sufficient level to include one at all.  This is a huge improvement.  In the coming weeks, I may get a chance to review the TOGAF metamodel in detail and provide insight into specific elements. 

Partitioned Architecture 

For years, the Zachman framework (ZF) has stood as the de-facto partitioning model for architecture.  In many organizations, the only thing that the CIO knew about enterprise architecture was a single word: Zachman. 

So teams around the world adopted John Zachman’s framework.  The problem is: the framework is not universally useful.  It is an implementation of a core concept: separate the different attributes of an architectural description and categorize your model.  Zachman not only demonstrates the concept, he implements it, and as a result, obscures the right of others to implement the same concept in a different way.

But there are other viewpoints than the rows represented in the Zachman Framework, and other subject areas than the columns he chose.  The concept is good, but the ZF implementation is not the only rational view. 

The TOGAF 9 takes a “metamodel” view of Zachman, providing a set of attributes that can be used to partition architectural models.  The ZF can easily be viewed as one implementation within the Partitioned Architecture mechanism described in TOGAF. 

In this way, the framers of TOGAF have given us the language to get past the ZF and allow many more views to emerge, without being bound to the ZF partitioning model, while remaining respectful of the ZF implementation as a valuable contribution to Enterprise Architecture.

Clarification of “Service”

TOGAF defines Information System Services as being different from Business Services.  As my prior blog points out, I couldn’t be happier!

The addition of Guidance

The good folks who worked on this current version are clearly in touch with the pain points that any adopting organization would feel when attempting to use the TOGAF, especially if they are not familiar with Enterprise Architecture already.  One of those pain points goes like this:  This is a great way to “think” about architecture, and “develop” architecture, but how do I “use” the framework in my business?  A new guidance section attempts to begin to answer that question. 

The guidance section is currently small, and I think it should be quite large (suggestions for improvement follow).  However, it is a start, and I’m glad to see that the start is there.

Opportunities to improve

1. Use process models to illustrate processes: A big chunk of TOGAF is dedicated to the methods used to develop architectural artifacts, called the ADM (Architectural Development Method).  It contains processes and terms and descriptions… good stuff.  However, when we, as architects, are called upon to describe methods and processes for our customers, we use diagrams, not just text.  The ADM does not use diagrams to explain the processes.  BPMN, please.
    
2. Include all the core terms in the metamodel: The Content Framework specifies a wide set of concepts.  In addition, various models in the TOGAF provide even more.  The metamodel does not cover all of them, nor does it provide any view that actually matches the other diagrams.  This is a point of incompleteness, and is not a criticism, since this is a new area of the TOGAF.  It is simply a suggestion for improvement.  I’m happy to help.
    
3. Adopt existing standard definitions – It is one thing to call an object by two names.  We can refer to a “business objective” by many different phrases, as long as we use the same definition.  It is another thing altogether to take an existing word, like Project, Business Process, Architecture, and API, and create an alternative definition for it.  (All three of these terms have definitions that are at variance with established standards).  That means creates an increasingly difficult problem for organizations that adopt TOGAF.  Writing your own definitions to common terms is a bad habit.  
    
4. Branch out into IT Management Processes – It should be no surprise that a framework, ostensibly targeting Enterprise Architecture, would be used by the strategic planning organization within an IT shop.  Yet, there is no specific description of a process where a planning organization would actually use an architectural model to fulfill their plans.  This is where the guidance section can go, and should go.
    
   That is not to say that TOGAF doesn’t have processes.  The ADM is basically a large set of processes.  There are plenty of discussions of the process of creating an artifact or model, but minimal descriptions of how an organization uses any of them.
   
   In the past, leaving out these business processes was a good thing.  Not any more.  I’d like to see processes specifically describing IT Project Portfolio Management, IT Application Portfolio Management, IT innovation funding, IT standards governance, and IT operations management.
    
5. Clarify the distinction between a generic business capability and an  architecture capability – The TOGAF is often adopted by organizations that are in the early stages of adopting Enterprise Architecture or attempting to improve EA maturity.  That adoption process requires that the adopting organization must turn “the lens of architecture” upon themselves, and when they do, they need to rationally discuss the business capabilities needed, by the architecture team, in order to perform a strategic enterprise architecture function.  This is a subset of overall business capabilities, specific for EA.  I call them architecture capabilities. 
   
   However, at some point, the newly minted architecture team must turn that architectural lens back to the business.  When what occurs, we use the term “business capability” in a more generic sense, to refer to the capabilities needed by any of the core business functions like Sales, Manufacturing, Fulfillment, and Customer Service (among others). 
   
   Unfortunately, the framework text frequently uses the word “capability” without any qualifier, leaving the reader to figure out which context the word is being used in.  In some places, the authors meant ‘architecture capability’ while in others, they meant ‘business capability.’  The concept of capabilities can be confusing to many business leaders as it is.  If the architect cannot eloquently describe the concept, adoption can be slowed.
    
   We need to make sure that we empower the adopting organization with a clear distinction between these two uses of the term “capability.” One suggestion is to add a strong differentiation into the text of the framework itself.  Another is by consistently avoiding the use of the unadorned term “capability” and instead using the more accurate qualified terms of ‘architecture capability’ or ‘business capability.’

Conclusion

Use TOGAF 9.0.  It is major step forward in architectural development.  While I had a few suggestions, they are not obstacles.  There is nothing in the TOGAF that prevents TOGAF v.9 from being useful as it stands today.