Applying Iteration to the ADM

Chapter 19 <<< Previous | Next >>>

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.

Figure 19-1: Iteration Cycles

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.

Figure 19-2: Classes of Enterprise Architecture EngagementEach 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.

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.

Figure 19-3: A Hierarchy of ADM Processes Example

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

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

Figure 19-5: Activity by Iteration for Target First Architecture DefinitionThe 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.

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

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

<<< Previous

Home

Next >>>