19.1 Overview

The Architecture Development Method (ADM) is a flexible process that can be used to support the development of architecture as a stand-alone process, or as an extension to other solution development or project management methods.

Many organizational factors will influence the extent to which the ADM should be used in an iterative fashion. Particular factors for consideration would include:

• The formality and nature of established process checkpoints within the organization. Does the organization mandate that certain groups of activities are carried out between checkpoints? Does the organization mandate that certain activities must be finalized before other activities can be carried out?
• The level of stakeholder involvement expected within the process. Are stakeholders expecting to be closely involved within the development of a solution, or are they expecting to see a complete set of deliverables for review and approval?
• The number of teams involved and the relationships between different teams. Is the entire architecture being developed by a specific team, or is there a hierarchy of teams with governance relationships between them?
• The maturity of the solution area and the expected amount of re-work and refinement required to arrive at an acceptable solution. Can the solution be achieved in a single pass, or does it require extensive proof-of-concept and prototyping work to evolve a suitable outcome?
• Attitude to risk. Does the organizational culture react negatively to partially complete work products being circulated? Does the organizational culture require solutions to be proved in a trial environment before they can be implemented for mainstream application?

The ADM supports a number of concepts that could be characterized as iteration. It is expected that:

• Project teams will iterate through the entire ADM cycle, commencing new vision activity as a result of Architecture Change Management.
• Project teams may cycle between ADM phases, in planned cycles covering multiple phases (e.g., Business Architecture, Information Systems Architecture, Technology Architecture).
• Project teams may return to previous phases in order to circle back and update work products with new information.
• Many project teams may operate their own ADM cycles concurrently, with relationships between different teams. For example, one architecture team may trigger a request for work for another architecture team.

All of these techniques are valid applications of the ADM and can be used to ensure that the approach to architecture development is sufficiently flexible to accommodate other methods and frameworks.

19.2 Iteration Cycles

When considering planned iteration cycles that span a number of ADM phases, the following guidelines can be used to effectively group related architectural activities to achieve a specific purpose.

These ADM iteration cycles are intended to span multiple phases of activity and allow formal review upon completion of each multi-phase iteration cycle (for example, an Architecture Definition should be reviewed with visibility of the Business, Data, Application, and Technology Architectures, rather than in isolation).

The suggested iteration cycles are shown in Iteration Cycles .

• Architecture Context iterations allow initial mobilization of architecture activity by establishing the architecture approach, principles, scope, and vision.
• Architecture Definition iterations allow the creation of architecture content by cycling through Business, Information Systems, and Technology Architecture phases. These iterations also allow viability and feasibility tests to be carried out by looking at opportunities and migration planning.
• Transition Planning iterations support the creation of formal change roadmaps for a defined architecture.
• Architecture Governance iterations support governance of change activity progressing towards a defined Target Architecture.

Some iteration cycles can be executed once, whereas others have a natural minimum number of cycles. For some iteration cycles, each iteration follows the same process; where there is more than one iteration within a cycle, the process differs slightly for each of the iterations.

When considering the usage of iteration cycles, it is also necessary to consider where to place appropriate checkpoints within the process. If the expected level of stakeholder involvement is high, it may be sensible to carry out very frequent but informal checkpoints to ensure that the process is moving in the intended direction. If stakeholders are less closely involved, then checkpoints may be less frequent but more formal. Checkpoints at the completion of each iteration cycle, or at the end of several iteration cycles, are common.

19.3 Two Styles of Architecture Definition

Two process styles can be adopted within the ADM for the definition of architectures:

• Baseline First: In this style, an assessment of the baseline (i.e., current state) landscape is used to identify problem areas and improvement opportunities. This process is suitable when a target solution is not clearly understood and agreed upon.
• Target First: In this style, the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to avoid proliferating current business practice into the target model.

The rationale for these two styles is that, in many cases, consideration of the target is deferred until conclusions have been made on the baseline. Premature consideration in these situations may be disruptive or politically sensitive (because the Target Architecture influences organization, roles, and responsibilities). Equally, initiatives that are examining Target Architectures run the risk of being constrained by the baseline or appearing to be constrained by the baseline if significant time is spent examining existing solutions.

In practical terms, an architecture team will always give informal consideration to the baseline when analyzing the target (and vice versa). In situations where baseline and target are expected to be considered in parallel by stakeholders, it is recommended that the architecture team focuses priority on one state within the internal structure of that engagement in order to maintain focus and consistency of execution.

19.4 Mapping TOGAF Phases to Iteration Cycles

Each iteration cycle crosses multiple TOGAF ADM phases. The following tables show at a high level which phases should be completed for which iteration cycle, showing activity that is core (i.e., the primary focus of the iteration), activity that is light (i.e., the secondary focus of the iteration), and activity that may be informally conducted (i.e., some activity may be carried out, but it is not explicitly mentioned in the ADM).

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part of the TOGAF document or go direct to a chapter within the document.
  
• Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or select Home to return to the welcome page.
  

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.