TOGAF? 10.0 Architecture Development Method (ADM) in detail

TOGAF 10.0 is a comprehensive framework for developing and managing enterprise architecture. For more details please refer TOGAF 10.0 High Level Standards.

The Architecture Development Method (ADM) is its core component, providing a structured approach to guide organizations through the architecture lifecycle. ?

• Provides a structured approach: The ADM offers a clear framework for developing and managing enterprise architecture.
• Ensures alignment: It helps align IT systems with business objectives. ?
• Facilitates decision-making: The ADM provides a framework for making informed decisions.
• Manages change: It helps organizations adapt to changing business needs and technologies.
• Improves efficiency: The ADM can streamline processes and reduce waste.
• Reduces risk: By following the ADM, organizations can identify and mitigate potential risks. ?

The ADM is a cyclical process consisting of eight phases

Preliminary Stage

The Preliminary is the foundational stage of the TOGAF ADM. It sets the stage for the entire architecture development process.

Key Objectives:

• Define the desired architecture capability.
• Establish the architecture capability, including architecture principles.

The Preliminary Phase is crucial for establishing a solid foundation for the architecture development process. It ensures that the organization is prepared to undertake the subsequent phases of the ADM.

Phase A: Architecture Vision

Phase A: Architecture Vision is the initial phase of the ADM cycle. It establishes the foundation for the entire architecture development process.

Objectives:

• Develop a high-level aspirational vision of the business value and capabilities.
• Obtain approval for the Statement of Architecture Work (SoAW).

Key Points:

• Phase A is about setting the direction and gaining organizational buy-in.
• The architecture vision is a high-level roadmap for the organization.
• The SoAW is a formal document that outlines the scope and objectives of the architecture project.
• Stakeholder management is crucial throughout the phase.

By successfully completing Phase A, the organization establishes a clear vision for its architecture and gains the necessary support to proceed to the subsequent phases of the ADM.

Phase B: Business Architecture

Phase B of the TOGAF ADM focuses on defining the current and desired state of the business. It involves understanding the organization's processes, capabilities, and structures to identify areas for improvement and development.

By the end of Phase B, the organization should have a clear understanding of its current business operations and a roadmap for achieving its desired future state. This information will serve as the foundation for subsequent phases of the ADM, such as data, application, and technology architecture.

Phase C: Information Systems Architectures

• Combination of Data and Application Architectures: This phase encompasses both data and application architecture development.
• Similar Approach: The processes for developing both data and application architectures are largely the same.
• Objective: Develop target architectures for both data and applications, identify gaps, and create a roadmap for transition.
• Odd Duck: This phase is considered unique due to its dual focus on data and applications.

Data Architecture

Data Architecture is the first half of the Information Systems Architectures phase within the TOGAF ADM.

Objectives:

• Develop a target data architecture aligned with the business architecture.
• Identify gaps between the current and desired data state.
• Create a data architecture roadmap.

By effectively defining the data architecture, organizations can ensure data quality, consistency, and accessibility to support business operations

Application Architecture

Application Architecture is the second half of the Information Systems Architectures phase within the TOGAF ADM.

Objectives:

• Develop a target application architecture aligned with the business and data architectures.
• Identify gaps between the current and desired application state.
• Create an application architecture roadmap.

By effectively defining the application architecture, organizations can ensure that their software applications support business objectives, are efficient, and can be easily integrated and maintained.

Phase D: Technology Architecture

Phase D: Technology Architecture is the final phase in defining the core architecture domains. It focuses on the infrastructure that supports the business, data, and application architectures.

Objectives:

• Develop a target technology architecture aligned with the business, data, and application architectures.
• Identify gaps between the current and desired technology state.
• Create a technology architecture roadmap.

By effectively defining the technology architecture, organizations can ensure that their IT infrastructure supports business objectives, is efficient, and can adapt to changing needs.

Phase E: Opportunities and Solutions

This is a critical stage in the TOGAF ADM where the focus shifts from defining architectures to identifying opportunities for improvement and developing potential solutions.

Objectives:

• Consolidate architecture roadmaps and identify potential transition architectures.
• Define solution building blocks.
• Develop an implementation strategy.

By effectively executing Phase E, organizations can develop a clear and actionable plan for transitioning to their target architecture while maximizing the benefits of new technologies and solutions.

Phase F: Migration Planning

Phase F: Migration Planning is the penultimate phase of the TOGAF ADM, focusing on translating the architecture vision into actionable plans.

Objectives:

• Develop a detailed implementation plan for the target architecture.
• Assign responsibilities and resources for migration activities.
• Assess the business value and costs associated with migration.

By effectively executing Phase F, organizations can create a well-defined roadmap for transitioning to the target architecture, minimizing risks, and maximizing the return on investment.

Phase G: Implementation Governance

Phase G: Implementation Governance marks the transition from planning to execution in the TOGAF ADM.

Objectives:

• Oversee the implementation of the architecture roadmap.
• Ensure adherence to architectural principles and standards.
• Monitor project progress and manage changes.

By effectively managing the implementation governance process, organizations can increase the likelihood of successful project outcomes and maximize the return on their architecture investments.

Phase H: Architecture Change Management

Phase H: Architecture Change Management is the final phase of the TOGAF ADM, focusing on ongoing monitoring, evaluation, and adaptation of the enterprise architecture.

Objectives:

• Ensure alignment between the architecture and the business.
• Manage changes to the architecture.
• Evaluate the effectiveness of the architecture.
• Identify opportunities for improvement.

By effectively managing architecture change, organizations can ensure that their architecture remains relevant and supports the business's evolving needs.

The TOGAF ADM is a cyclical process, and after completing Phase H, organizations can initiate a new ADM cycle to address emerging challenges and opportunities.

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 fashionWithin large-scale 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

Requirements Management

Requirements Management is a continuous process that spans all phases of the TOGAF ADM. It ensures that changes to the architecture are managed effectively and that the architecture remains aligned with business objectives.

Key Functions:

• Change management: Handles modifications to architecture requirements throughout the ADM cycle.
• Process management: Defines and manages the flow of requirements between phases.
• Governance: Ensures compliance with architectural standards and principles.
• Communication: Facilitates information sharing and collaboration among stakeholders.

Importance:

• Maintains the integrity of the architecture.
• Enables efficient change management.
• Supports decision-making.
• Improves overall project success.

By effectively managing requirements, organizations can increase the likelihood of achieving their desired business outcomes through the implementation of the enterprise architecture.

Iteration Cycles of ADM

• Architecture Capability iterations support the creation and evolution of the required Architecture CapabilityThis 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 phasesThese 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 & 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

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

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

Further more, please refer to Key ADM Techniques for more info

Applying ADM across the Architecture Landscape

The following characteristics are typically used to organize the Architecture Landscape:

• Breadth: the breadth (subject matter) area is generally the primary organizing characteristic for describing an Architecture LandscapeArchitectures are functionally decomposed into a hierarchy of specific subject areas or segments.
• Depth: with broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexityMore specific subject matter areas will generally permit (and require) more detailed architectures.
• Time: for a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the futureBroader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.
• Recency: finally, each architecture view will progress through a development cycle where it increases in accuracy until finally approvedAfter approval, an architecture will begin to decrease in accuracy if not actively maintained. In some cases recency may be used as an organizing factor for historic architectures.

Using the criteria above, architectures can be grouped into Strategic, Segment, and Capability Architecture levels:

1. Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
2. Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
3. Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

A number of techniques can be employed to use the ADM as a process that supports such hierarchies of architectures. Essentially there are two strategies that can be applied:

1. Architectures at different levels can be developed through iterations within a single cycle of the ADM process
2. Architectures at different levels can be developed through a hierarchy of ADM processes, executed concurrently

At the extreme ends of the scale, either of these two options can be fully adopted. In practice, an architect is likely to need to blend elements of each to fit the exact requirements of their Request for Architecture Work. These were explained during early iteration cycles of this article.

How does all these architectures transform into individual project teams mapping ?

Steps within the Preliminary Phase to support architecture partitioning are as follows:

• Determine the organization structure for architecture within the enterprise: the various standing teams that will create the architecture should be identifiedFor each of these teams, appropriate boundaries should be established, including:Governance bodies that are applicable to the teamTeam membershipTeam reporting lines
• Determine the responsibilities for each standing architecture team: for each architecture team, the responsibilities should be identifiedThis step applies partitioning logic to the Enterprise Architecture in order to firstly identify the scope of each team and secondly to partition the architecture under the remit of a single team. Once complete, this step should have partitioned the entire scope of the enterprise and should have assigned responsibility for each partitioned architecture to a single team. Partitioning should create a definition of each architecture that includes:Subject matter areas being coveredLevel of detail at which the team will workTime periods to be coveredStakeholders
• Determine the relationships between architectures: once a set of partitioned architectures has been created, the relationships between architectures should be developedThis step allows governance relationships to be formalized and also shows where artifacts from one architecture are expected to be re-used within other architectures.Areas of consideration include:Where do different architectures overlap/dovetail/drill-down?What are the compliance requirements between architectures?

Once the Preliminary Phase is complete, the teams conducting the architecture should be understood. Each team should have a defined scope and the relationships between teams and architecture should be understood. Allocation of teams to architecture scope is illustrated below

Conclusion

The TOGAF ADM cycle is a powerful tool for organizations seeking to develop and manage their enterprise architecture effectively. By following the structured approach outlined in the ADM, organizations can:

• Align IT with business goals: Ensure that IT systems support the organization's strategic objectives.
• Improve decision-making: Make informed choices based on data and analysis.
• Enhance efficiency: Streamline processes and reduce waste.
• Manage change effectively: Adapt to evolving business needs and technologies.
• Reduce risks: Identify and mitigate potential challenges.

By leveraging the tailored TOGAF ADM, organizations can gain a competitive advantage, drive innovation, and achieve long-term success.

References:

1. The TOGAF? Standard — Digital Edition - Introduction

2. TOGAF? Standard — Introduction - The Open Group Publications Catalog

• pubs.opengroup.org