Introduction
The Architecture Development Method (ADM) is a core component of the TOGAF (The Open Group Architecture Framework) standard, providing a structured approach for developing and managing enterprise architecture. One of the key features of the ADM is its iterative nature, which allows practitioners to adapt and refine their work based on evolving information needs and stakeholder feedback. This guide explores the iterative process of the ADM, key concepts, and practical examples to illustrate its application.
Understanding the Iterative Nature of ADM
The Central Question
At the heart of the ADM is a central question: Is there a need for the essential purpose of a phase on a particular Architecture Project? If the answer is yes, the project will enter that phase at some point. If the essential purpose has already been addressed or is not needed, the project will not enter that phase. This flexibility allows practitioners to focus on what is most relevant to their current context.
Information Needs and the EA Landscape
The ADM emphasizes the importance of having the right information available in the Enterprise Architecture (EA) Landscape. If the necessary information is not readily available, practitioners must produce it. This process is not merely about following a linear sequence of activities; rather, it involves exploring the EA Landscape to determine what information is required in terms of subject, detail, time, and recency.
Activity vs. Output
Most commentary in the TOGAF Standard regarding iteration focuses on activity rather than output. Practitioners should not view iteration as merely re-sequencing or looping through the ADM phases. Instead, they should assess the EA Landscape and determine whether the required information is available. If it is, they can move forward; if not, they must produce the necessary material, effectively executing a TOGAF ADM phase.
Key Concepts of the Iterative ADM Process
Simultaneous Execution of Phases
The ADM allows for the simultaneous execution of phases, as illustrated in a stylized Gantt chart (Figure 10). This chart highlights the interdependent nature of the EA, where multiple phases can be open at the same time to address the information required. Once the necessary information is provided, those phases can close.
Continuous Reassessment
Practitioners continually revisit required phases at the appropriate level of detail. This iterative approach ensures that the architecture remains aligned with stakeholder concerns and business needs. For example, if a practitioner is developing the Business Architecture (Phase B), they will consistently address stakeholder concerns, identify gaps, and assess impacts across the entire EA Landscape.
Problem-Solving Models
Traditional problem-solving models often present linear approaches with step gates. While these models help understand the process, they do not accurately reflect how professionals typically solve problems. Figure 11, derived from Jeff Conklin’s work on Wicked Problems, illustrates a standard linear problem-solving progression and how professionals interactively address issues. This iterative consideration of high-level direction and execution is a best practice in the ADM.
Practical Examples of Iteration in ADM
Example 1: Developing a Business Architecture
In a retail organization, a practitioner may begin by developing the Business Architecture (Phase B). They gather stakeholder input to identify gaps in the current architecture. As they progress, they realize that additional information about customer preferences is needed. Instead of moving linearly to the next phase, they revisit Phase A to refine the architecture vision based on this new information, ensuring that the architecture aligns with stakeholder needs.
Example 2: Implementing a New IT System
Consider a financial services firm planning to implement a new IT system. During Phase E (Opportunities & Solutions), the practitioner identifies several work packages to address gaps in the current system. However, as they assess the dependencies between these packages, they discover that additional resources are required. They iterate back to Phase F (Migration Planning) to adjust the project plan, ensuring that the necessary resources are allocated before proceeding.
Example 3: Continuous Stakeholder Engagement
In a healthcare organization, the practitioner is tasked with developing an architecture that improves patient data management. Throughout the ADM process, they maintain continuous engagement with stakeholders, revisiting Phase B to address new concerns as they arise. This iterative feedback loop allows the practitioner to adapt the architecture in real-time, ensuring that it meets the evolving needs of the organization and its stakeholders.
Conclusion
The iterative nature of the TOGAF ADM is essential for effectively managing enterprise architecture projects. By continuously assessing information needs, engaging stakeholders, and revisiting phases as necessary, practitioners can ensure that their architectural efforts remain relevant and aligned with organizational goals. This flexibility not only enhances the quality of the architecture but also fosters a culture of collaboration and responsiveness within the organization. As businesses face ever-changing environments, the iterative approach of the ADM will continue to be a valuable asset in guiding successful transformations.