A first look at TOGAF 9.0

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.

Comments

• Anonymous
  February 02, 2009
  PingBack from http://architectural-model.modelbuilders.info/inside-architecture-a-first-look-at-togaf-90/

• Anonymous
  February 03, 2009
  The enhancements in The Open Group's TOGAF 9 make enterprise architecture a bit more easy for the masses

• Anonymous
  February 03, 2009
  NickMalik: Thanks for sharing the viewpoint. Other aspects where I think there are opportunities to focus on and perhaps build on a customized/organizational viewpoint is around EA governance itself….an area of challenge for a lot of EA organizations  

• Anonymous
  February 04, 2009
  It’s just a standard day in San Diego. That is to say, the friendly people over here are kind of used to blue skies and summer temperatures at the beginning of February. On the other hand, these days are quite...

• Anonymous
  February 05, 2009
  ALT.NET Derek has Dimecast #83 - Learning to use Fluent NHibernate: Getting Started w/ Your First Mappings Software Architecture The Open Group have announced the release of TOGAF 9.0 . TOGAF (The Open Group Architecture Framework) has been in development

• Anonymous
  February 06, 2009
  Nick, good points, I particularly missed the Guidance part in the previous version(s). "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. " One of the things about TOGAF that attracted me to it is the option of using any documentation you feel fit for purpose. If you want to use BPMN to describe your processes, by all means go ahead. If you want to draw them on a whiteboard and take a picture, that's fine too. That flexibility makes it easier to integrate in an environment which currently have models in place in some areas, but not all. (I.e. COBIT for governance, PINCE2 for projects) Though, at the same time the lack of standards can bring inconsistencies in its practical implementation. But with proper guidance in future versions the risk of this might be mitigated slightly.

• Anonymous
  February 06, 2009
  This week, there were two standard announcements, one involving enterprise architecture and the other Web services. First, The Open Group Architecture Framework (TOGAF) updated . TOGAF is a vendor- and technology-neutral standard for enterprise...

• Anonymous
  February 06, 2009
  Nick, great observations. I think the service concept is certainly one of the stronger aspects of TOGAF 9, along with the new content framework as a whole. With the new architecture content framework (ACF) and guidance on using the now almost classic architecture development method (ADM), TOGAF 9 puts out the first full enterprise architecture framework to the public covering the entire spectrum from content and process to capability. This gives people an opportunity of saying "Never mind" all the other frameworks and stick to TOGAF. Indeed a step forward.

• Anonymous
  February 09, 2009
  Curious. In this economic slump, where huge budgets have been cut / decimated in enterprise IT, whether any of these "specifications" would be "open" to providing a crawl, walk, run standard to the end game. I see MOST companies (architects) wanting the end game but stalling because they are "afraid" of any strategy that doesn't fit the standards. In today's environment, tactical is more than OK but architects need to be told so, lest they fear breaking the standards. So, do nothing, or side step for a while. Small steps (tactics) breed success, leading to Nirvana (even if that's many years from now. Doing NOTHING is not an option, right? I'm curious as to the thoughts here?

• Anonymous
  February 09, 2009
  Hello Francis, I'm not sure what you are getting at.  The TOGAF can readily be adopted in a crawl-walk-run approach.  (In my opinion, that is the only way that it, or any other framework, is actually adopted, regardless of the plans of mice and men to the otherwise). If you are speaking from experience, perhaps you have met an architect that is afraid of a strategy because it doesn't fit a standard?  I, personally, find that odd.  I would think that most architects (certainly the ones I know) are focused so much on delivering value that it is tough to get their attention to spend on mundane things like consistency or standardization.   Perhaps we live in different worlds. There is nearly always a middle ground.  If you are faced with an architect that insists on a standard and you don't believe that the standard is cost-effective, work with him.  Get him to communicate.  Write down the principle that you are both willing to agree to.  Then work backwards to the present, showing how both of you can get your goals.  The answer is usually somewhere between an agreement and a roadmap.   For example, let's say the architect insists that you build a SOA app that consumes an enterprise data source.  You don't care about SOA, and you know it will be time consuming to consume the enterprise data source.  Get together. Agree that you will END UP with an app that integrates and doesn't introduce a data store. Then show how step 1 is for you to build your own little SOA service that presents local data, and an app that consumes that service.  Show how you can produce it and roll it out quickly.  Then PROMISE, in front of the customer, that Stage II will involve shifting the app to consume the enterprise service and decommissioning your local service. Now, you have a two-step roadmap.  Both you and your architect get what you want.  I make it sound easy but it is not.  This is a relationship, and a level of trust.  If you are not willing to give your word, and keep it, then give up.  But if you are honorable, and you are willing to see the world through the eyes of the architect, then you can convince him or her to join you on a quest for quality. I've done it.  It isn't easy.  But it can be done. Good Luck, --- Nick