Welcome to GTRA

Federal enterprise architects who have adopted aspects of TOGAF have done it for one primary reason - TOGAF provides process detail that is missing from FEA, DoDAF and Zachman. This process detail is provided through the Architectural Development Method (ADM), which remains the same in TOGAF 9 as in TOGAF 8 at the highest level. This high level view, common to both versions, is shown in the diagram below.

The high level mapping of the ADM to Federal practice also remains the same and is shown in the next diagram.

TOGAF 9 gives us significant changes at the ADM Phase level. In the coming months I'll be attempting, with some colleagues, to understand what these changes mean for architects dealing with FEA, FSAM, DoDAF, etc. For now I'd like to discuss the enhancements and changes in more general terms. I'll go through the ADM, pointing out and commenting on key changes.

The TOGAF 9 ADM Preliminary Phase has increased guidance on establishing an enterprise architecture framework and planning for architecture development.  It also provides more advice for the definition of a governance model to enable architecture benefit realization. It also discusses how TOGAF relates to other management frameworks such as ITIL, COBIT, PMBOK and the established frameworks unique to a particular enterprise.

Phase A - The Vision Phase - has been considerably expanded, with added emphasis on the readiness of an organization to undergo change and the risks inherent in doing so (overall greater attention to risk in TOGAF 9). The bolded steps in the list below are those which are new or have seen substantial change in TOGAF 9:

• Establish the Architecture Project
• Identify Stakeholders, Concerns, and Business Requirements
• Confirm and Elaborate Business Goals, Business Drivers, and Constraints
• Evaluate Business Capabilities
• Assess Readiness for Business Transformation
• Define Scope
• Confirm and Elaborate Architecture Principles, including Business Principles
• Develop Architecture Vision
• Define the Target Architecture Value Propositions and KPI
• Identify the Business Transformation Risks and Mitigation Activities
• Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval

Phases B-D - Business Architecture, Application Architecture, Data Architecture, Technology Architecture - have had the steps within each rationalized against te other three in TOGAF 9. These phases, where enterprise architects are in most direct control of the EA process, had a different set of steps for each of the four phases in version 8. These are the new steps, common to all four phases (I use the Data Architecture example, the other lists are the same except for the word "data"):

• Select Reference Models, Viewpoints, and Tools
• Develop Baseline Data Architecture Description
• Develop Target Data Architecture Description
• Perform Gap Analysis
• Define Roadmap Components
• Resolve Impacts Across the Architecture Landscape
• Conduct Formal Stakeholder Review
• Finalize the Data Architecture
• Create Architecture Definition Document

Rationalizing the steps like this improves intra-team ccommunication, since everyone is operating off basically the same playbook. There is considerable frontloading - the "Select Reference Models, Viewpoints, and Tools" step seems to have gained emphasis - 'get this stuff right and everyting else is easier' seems to be the message.   

Phases E and F - Opportunities & Solutions phase and Migration Planning phase feature a more detailed method for defining and planning enterprise transformation, based on the principles of capability-based planning. This connection could be useful to Agencies in Departments like DoD and DHS which are already doing things with capability-based planning.

I find a couple problems with these Phases. First, the new material doesn't fit well into the rest of the ADM. Second, it seems that enterprise architects need to consider the outputs of capability-based planning - but not undertake the planning themselves as part of the EA process. In this sense I think capability-based planning is like ITIL, COBIT and PMBOK, in that architects must understand how their processes interact with the ADM. They also need to tailor the ADM to deal most effectively with them. I suspect this is a more useful way of seeing the relationship between capability-based planning and the ADM. TOGAF 8 certainly lacked specificity inn these two phases, but the current aapproach probably doessn't offer the best way to address this problem. 

Phases G, H and Requirements Management - have not changed very much in TOGAF 9, and perhaps they neeed to, especially to deal with changes in scoping concepts written into the new version. These changes open up the possibility of several ADM cycles running concurrently - one at the 'strategic' level, a few at the 'segment' level, and potentially several at the 'capability' level. Stuctures and processes for requirements management, governance at the project level and change management are all inadequate in version 9 to deal with this potential complexity.

Notice my criticism of the ADM in TOGAF 9 has been directed at the later phases of the ADM - E-H - where enterprise architects have fairly little influence. In the Federal government, as in most large organizations, architects usually have to work with the existing processes of the organization. TOGAF 9 continues to be quite adamant TOGAF should be tailored to meet existing processes and structures, not vice versa. If enterprise architects look at TOGAF and EA in this spirit, they will get the most value.