18. Applying Iteration to the ADM

Chapter Contents
18.1 Overview | 18.2 Iteration Cycles | 18.3 Classes of Architecture Engagement | 18.4 Approaches to Architecture Development | 18.5 Iteration Considerations | 18.6 Conclusions

18.1 Overview

The graphical representation of the TOGAF ADM, as shown in Figure 4-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 19. 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:

Iteration within an ADM cycle (Architecture Development iteration):

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

18.2 Iteration Cycles

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



Figure 18-1: Iteration Cycles

18.3 Classes of Architecture Engagement

An architecture function or services organization may be called upon 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:

Figure 18-2 and the following table show the classes of Enterprise Architecture engagement.



Figure 18-2: Classes of Enterprise Architecture Engagement

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

Area of

Architecture

 

Engagement

Engagement

Description

Identification of Required Change

Supporting Business Strategy

As the business strategies, objectives, goals, and drivers change, it is necessary for the enterprise to change in order to maintain alignment.

The creation of new business strategies can be supported by Enterprise Architecture by:

  • Providing visibility of change opportunities
  • Providing elaboration on the practical impacts of a particular strategic choice
  • Providing tests on the feasibility or viability of a particular strategic direction


 

Architectural Portfolio Management of the Landscape

It is common practice across large organizations for a service management organization to provide operational reporting and management of the IT portfolio.

Enterprise Architecture can add a further dimension to service management reporting, by supporting a linkage between operational performance and the strategic need for IT.

Using the traceability between IT and business inherent in Enterprise Architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.

 

Architectural Portfolio Management of Projects

It is common practice across large organizations for a program management organization to provide operational reporting and management of the change portfolio.

Enterprise Architecture can add a further dimension to project portfolio management reporting, by supporting a linkage between project scope, architectural impact, and business value.

Architectural factors can be added to other quantitative project factors to support strategic decision-making on project priority and funding levels.

Definition of Change

Architectural Definition of Foundational Change Initiatives

Foundational change initiatives are change efforts that have a known objective, but are not strictly scoped or bounded by a shared vision or requirements.

In foundational change initiatives, the initial priority is to understand the nature of the problem and to bring structure to the definition of the problem.

Once the problem is more effectively understood, it is possible to define appropriate solutions and to align stakeholders around a common vision and purpose.

 

Architectural Definition of Bounded Change Initiatives

Bounded change initiatives are change efforts that typically arise as the outcome of a prior architectural strategy, evaluation, or vision.

In bounded change initiatives, the desired outcome is already understood and agreed upon. The focus of architectural effort in this class of engagement is to effectively elaborate a baseline solution that addresses the identified requirements, issues, drivers, and constraints.

Implementation of Change

Architectural Governance of Change Implementation

Once an architectural solution model has been defined, it provides a basis for design and implementation.

In order to ensure that the objectives and value of the defined architecture are appropriately realized, it is necessary for continuing Architecture Governance of the implementation process to support design review, architecture refinement, and issue escalation.


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

Engagement Type

Focus Iteration Cycles

Scope Focus

Supporting Business Strategy

Architecture Capability

Architecture Development
(Baseline First)

Broad, shallow consideration given to the Architecture Landscape in order to address a specific strategic question and define terms for more detailed architecture efforts to address strategy realization.

Architectural Portfolio Management of the Landscape

Architecture Capability

Architecture Development
(Baseline First)

Focus on physical assessment of baseline applications and technology infrastructure to identify improvement opportunities, typically within the constraints of maintaining business as usual.

Architectural Portfolio Management of Projects

Transition Planning

Architecture Governance

Focus on projects, project dependencies, and landscape impacts to align project sequencing in a way that is architecturally optimized.

Architectural Definition of Foundational Change Initiatives

Architecture Capability

Architecture Development
(Baseline First)

Transition Planning

Focus on elaborating a vision through definition of baseline and identifying what needs to change to transition the baseline to the target.

Architectural Definition of Bounded Change Initiatives

Architecture Development
(Target First)

Transition Planning

Focus on elaborating the target to meet a previously defined and agreed vision, scope, or set of constraints. Use the target as a basis for analysis to avoid perpetuation of baseline, sub-optimal architectures.

Architectural Governance of Change Implementation

Architecture Governance

Use the Architecture Vision, constraints, principles, requirements, Target Architecture definition, and transition roadmap to ensure that projects realize their intended benefit, are aligned with each other, and are aligned with wider business need.

18.4 Approaches to Architecture Development

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

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.

18.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.

18.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 18-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.



Figure 18-3: A Hierarchy of ADM Processes Example

18.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).



Figure 18-4: Activity by Iteration for Baseline First Architecture Definition




Figure 18-5: Activity by Iteration for Target First Architecture Definition

The suggested iteration cycles mapped to the TOGAF phases are described in the following table:

Iteration Cycle

Iteration

Purpose

Description

Architecture Development
(Baseline First)

Iteration 1

Define the Baseline Architecture.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the baseline.

Opportunities, solutions, and migration plans are also considered to drive out the focus for change and test feasibility.

 

Iteration 2

Define the Target Architecture and gaps.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the target and analyzing gaps against the baseline.

Opportunities, solutions, and migration plans are also considered to test viability.

 

Iteration n

Refine baseline, target, and gaps.

Subsequent Architecture Development iterations attempt to correct and refine the target to achieve an outcome that is beneficial, feasible, and viable.

Architecture Development
(Target First)

Iteration 1

Define the Target Architecture.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the target.

Opportunities, solutions, and migration plans are also considered to drive out the focus for change and test feasibility.

 

Iteration 2

Define the Baseline Architecture and gaps.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the baseline and analyzing gaps against the target.

Opportunities, solutions, and migration plans are also considered to test viability.

 

Iteration n

Refine baseline, target, and gaps.

Subsequent Architecture Development iterations attempt to correct and refine the target to achieve an outcome that is beneficial, feasible, and viable.

Transition Planning

Iteration 1

Define and agree a set of improvement opportunities, aligned against a provisional Transition Architecture.

The initial iteration of Transition Planning seeks to gain buy-in to a portfolio of solution opportunities in the Opportunities & Solutions phase of ADM.

This iteration also delivers a provisional Migration Plan.

 

Iteration n

Agree the Transition Architecture, refining the identified improvement opportunities to fit.

Subsequent iterations of Transition Planning seek to refine the Migration Plan, feeding back issues into the Opportunities & Solutions phase for refinement.

Architecture Governance

Iteration 1

Mobilize Architecture Governance and change management processes.

The initial Architecture Governance iteration establishes a process for governance of change and also puts in place the appropriate people, processes, and technology to support managed access to and change of the defined architecture.

 

Iteration n

Carry out Architecture Governance and change control.

Subsequent iterations of the Architecture Governance cycle focus on periodic reviews of change initiatives to resolve issues and ensure compliance. Results of a Change Request may trigger another phase to be revisited; for example, feeding back a new requirement to the Preliminary Phase to improve the Architecture Capability, or a new requirement for the architecture into the Architecture Development phases.

18.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:


Footnotes

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


return to top of page