19.1 Overview

The graphical representation of the TOGAF ADM, as shown in Figure 5-1, and the description of the ADM phases discretely in order in Part II, can be read to imply a deterministic waterfall methodology. This method of presentation is provided for the purpose of quickly communicating the basics of architecture development and the architecture lifecycle. In practice, two key concepts are used to manage the complexity of developing an enterprise architecture and managing its lifecycle - iteration and levels (see 20. Applying the ADM across the Architecture Landscape). The two concepts are tightly linked.

The ADM supports a number of concepts that are characterized as iteration. First, iteration describes the process of both describing a comprehensive Architecture Landscape through multiple ADM cycles based upon individual initiatives bound to the scope of the Request for Architecture Work. Second, iteration describes the integrated process of developing an architecture where the activities described in different ADM phases interact to produce an integrated architecture. In order to concisely describe the activity and outputs, this latter iteration is described in sequential terms. Third, iteration describes the process of managing change to the organization's Architecture Capability.

Iteration to develop a comprehensive Architecture Landscape:

• Projects will exercise through the entire ADM cycle, commencing with Phase A. Each cycle of the ADM will be bound by a Request for Architecture Work. The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required.
• Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects.
• One project may trigger the initiation of another project. Typically, this is used when higher-level architecture initiatives identify opportunities or solutions that require more detailed architecture, or when a project identifies landscape impacts outside the scope of its Request for Architecture Work.

Iteration within an ADM cycle (Architecture Development iteration):

• Projects may operate multiple ADM phases concurrently. Typically, this is used to manage the inter-relationship between Business Architecture, Information Systems Architecture, and Technology Architecture.
• Projects may cycle between ADM phases, in planned cycles covering multiple phases. Typically, this is used to converge on a detailed Target Architecture when higher-level architecture does not exist to provide context and constraint.
• Projects may return to previous phases in order to circle back and update work products with new information. Typically, this is used to converge on an executable Architecture Roadmap or Implementation and Migration Plan, when the implementation details and scope of change trigger a change or re-prioritization of stakeholder requirements.

Iteration to manage the Architecture Capability (Architecture Capability iteration):

• Projects may require a new iteration of the Preliminary Phase to (re-)establish aspects of the Architecture Capability identified in Phase A to address a Request for Architecture Work.
• Projects may require a new iteration of the Preliminary Phase to adjust the organization's Architecture Capability as a result of identifying new or changed requirements for Architecture Capability as a result of a Change Request in Phase H.

19.2 Iteration Cycles

The suggested iteration cycles for the TOGAF ADM are shown in Figure 19-1, and can be used to effectively group related architectural activities to achieve a specific purpose. These iteration cycles are referenced in 19.3 Classes of Architecture Engagement and 19.5 Iteration Considerations.

• Architecture Capability iterations support the creation¹ and evolution of the required Architecture Capability. This includes the initial mobilization of the architecture activity for a given purpose or architecture engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.
• Architecture Development iterations allow the creation of architecture content by cycling through, or integrating, Business, Information Systems, and Technology Architecture phases. These iterations ensure that the architecture is considered as a whole. In this type of iteration stakeholder reviews are typically broader. As the iterations converge on a target, extensions into the Opportunities and Solutions and Migration Planning phases ensure that the architecture's implementability is considered as the architecture is finalized.
• 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.

19.3 Classes of Architecture Engagement

An architecture function or services organization may be called on to assist an enterprise in a number of different contexts, as the architectures developed can range from summary to detail, broad to narrow coverage, and current state to future state. In these contexts the concept of iteration should be used in developing the architecture.

Typically, there are three areas of engagement for architects:

• Identification of Required Change: Outside the context of any change initiative, architecture can be used as a technique to provide visibility of the IT capability in order to support strategic decision-making and alignment of execution.
• Definition of Change: Where a need to change has been identified, architecture can be used as a technique to define the nature and extent of change in a structured fashion. Within largescale change initiatives, architectures can be developed to provide detailed Architecture Definition for change initiatives that are bounded by the scope of a program or portfolio.
• Implementation of Change: Architecture at all levels of the enterprise can be used as a technique to provide design governance to change initiatives by providing big-picture visibility, supplying structural constraints, and defining criteria on which to evaluate technical decisions.

Figure 19-2 and the following table show the classes of enterprise architecture engagement.

Each of these architecture engagement types is described in the table below.

Different classes of architecture engagement at different levels of the enterprise will require focus in specific areas, as shown below.

19.4 Approaches to Architecture Development

Two approaches can be adopted within the ADM for the development of architectures:

• Baseline First: In this style, an assessment of the baseline landscape is used to identify problem areas and improvement opportunities. This process is most suitable when the baseline is complex, not clearly understood, or agreed upon. This approach is common where organizational units have had a high degree of autonomy.
• 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 effectively transition to the target model.

Typically, if the baseline is broadly understood a higher value will be obtained focusing on the target first then baseline to the extent necessary to identify changes.

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 in order to maintain focus and consistency of execution.

19.5 Iteration Considerations

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.5.1 Iteration between ADM Cycles

Each iteration completes an ADM cycle at a single level of architecture description. This approach to the ADM uses Phase F (Migration Planning) to initiate new more detailed architecture development projects. This approach is illustrated in Figure 19-3. This type of iteration highlights the need for higher-level architecture to guide and constrain more detailed architecture. It also highlights that the complete Architecture Landscape is developed by multiple ADM iterations.

19.5.2 Iteration within an ADM Cycle

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 suggested iteration cycles mapped to the TOGAF phases are described in the following table:

19.6 Conclusions

All of these techniques are valid applications of the ADM. Combined together, they represent how the ADM can be used in practice. The ADM should always be used in an iterative process. How this process is exercised is dependent upon organizational factors. Particular factors for consideration 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 rework 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 class of engagement. What is the context for development of the enterprise architecture?

Footnotes

1. Guidance on how to use a full ADM cycle for initially establishing an organization's Architecture Capability is found in Part VII, 46. Establishing an Architecture Capability.

return to top of page