The ADM (Architectural Development Method) is the core of the TOGAF framework. Each phase in the ADM provides for specific step in the development of an enterprise architecture. In order to understand these phases, it is important to understand the objectives and individual steps in a given phase.
Let us look at them one by one.
The preliminary phase is the first and foremost in the ADM. Here, we ensure that the enterprise is ready for what we want to do.
Our first objective is to determine the Architecture Capability desired by the organization. In order to do this, we have to take understand the current state of the organization and get it to a level where we can go ahead.
We should review the current status of the organization as a whole and specific parts of the organization (IT, Management approval, readiness, etc). Is this favorable to conduct the enterprise architecture we plan? With this, we identify the elements of the organization that would be required by the architecture capability in mind. This is required to ensure that we restrict ourselves from tampering with unrelated parts of the organization. Any organization, however disorganized, has a set of methods and processes (that may or may not be documented). Before we can work with the architecture, it is important to understand these. Based on all these observations, we need to establish the level of maturity of the organization. Is it mature enough for an enterprise architecture?
The objective of the preliminary phase is not just to understand the organization, it is also to make the organization ready for enterprise architecture.
We need to define an appropriate organizational model required for the enterprise architecture. We need to identify and propose a detailed set of processes resources and tools required for a good architecture governance. And most important, we need to define a set of architecture principles that can help us with developing the enterprise architecture.
Here, we define and establish the Enterprise Architecture team and the organization.
An important goal here is to tailor the TOGAF framework and, if any, other selected architecture frameworks. Along with this, we develop strategy and implementation plans for tools and techniques
As the name suggests, the architecture vision is about creating the architecture vision; conveying it to those who need to know; and getting a sign off to confirm if we have enough support to proceed.
Here, we develop a high-level aspirational vision of the capabilities and business value that we plan to deliver as a result of the proposed Enterprise Architecture.
The Preliminary Phase is about the organization, while the Phase A is about the project. Here, we establish the architecture project. We need to identify the stakeholders along with their concerns.
We identify the business requirements for the project. Based on this, we confirm and elaborate business goals, business drivers, and constraints. We evaluate the current capabilities and assess readiness for the business transformation. We should define scope for the project.
We also confirm and elaborate architecture principles and business principles that were defined in the Preliminary Phase
The Architecture Vision is developed in this phase. That should define a value proposal and KPI's for the Target Architecture. We need to identify and mitigate the risks of business transformation.
All these go into the Statement of Architecture Work defined in this phase. This Statement of Architecture Work is finalized and approved and signed off by the end of this process.
This vision should be conveyed to the concerned stakeholders and we need to obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision
The business architecture defines the business aspects of the enterprise being developed.
We need to develop the Target Business Architecture that describes how the enterprise needs to operate. The target business architecture should achieve the defined business goals defined in the Preliminary Phase and refined in the Phase A.
The target business architecture should respond to the strategic drivers that we set out in the Architecture Vision and addresses the Statement of Architecture Work, along with the stakeholder concerns.
The business architecture phase should also identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures. These, along with those defined in phase C and D, will be finalized downstream in the phase E.
In order to achieve this, we start with selecting reference models, viewpoints and tools to develop the Baseline and Target Business Architecture Description, and to identify the roadmap based on the gaps. We need to identify and resolve impacts of the architecture development across the Architecture Landscape.
Having developed these, we go ahead to conduct a formal stakeholder review and finalize the Business Architecture. Finally, we create the Business Architecture Definition Document.
The Phase C has two components Data and Application architecture. TOGAF does not insist on a sequence for these. Theory requires Data first, practice requires Application first. We might also have an iterative approach. The objectives of either are defined by TOGAF
Here, we want to develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision. While doing this, it should addresses the Statement of Architecture Work and stakeholder concerns.
In this phase, we need to identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Data Architectures
We start by selecting the reference models, viewpoints, and tools to develop the Baseline and Target Data Architecture Description, and perform a gap analysis to define the candidate roadmap components. Based on these gaps, we resolve impacts across the Architecture Landscape.
With this in place, we conduct a formal stakeholder review and finalize the data architecture. Finally we create the relevant part of the Architecture Definition Document.
Similarly, we also develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
Along with the target architecture, we need to identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures.
We start by selecting the reference models, viewpoints, and tools to develop the Baseline and Target Application Architecture Description, and perform a gap analysis to define the candidate roadmap components. Based on these gaps, we resolve impacts across the Architecture Landscape.
With this in place, we conduct a formal stakeholder review and finalize the application architecture. Finally we create the relevant part of the Architecture Definition Document.
n this phase, we develop the Target Technology Architecture. This Technology Architecture should enables the Architecture Vision and the target business, data and application architectures defined in the previous phases. It should enable the individual building blocks of business, application and data architecture. It should identify technology components and technology services that can do this. Thus, it should addresses the core Statement of Architecture Work and stakeholder concerns.
While doing this, we also identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
We start by selecting the reference models, viewpoints, and tools required to develop the Baseline and Target Technology Architecture Description. We perform a gap analysis to define the candidate components for the architecture roadmap. Based on these gaps, we resolve impacts across the Architecture Landscape.
With this in place, we conduct a formal stakeholder review and finalize the technology architecture. Finally we create the relevant part of the Architecture Definition Document.
By the time we enter this phase, we have the overall architecture ready and documented. Now, we start looking at how it can be implemented. The previous three phases of business, data, application and target architecture had defined the candidate roadmaps, based on the gap analysis from the respective point of view. Here, we collate them and generate the initial complete version of the Architecture Roadmap - based upon the gap analysis and candidate Architecture Roadmap components from from previous phases.
Based on the kind of gaps we identify, we need to determine whether an incremental approach is required. If so, we identify Transition Architectures that will deliver continuous business value. Each of the individual transition architectures should be a stable business solution, so that it can be implemented independently.
We also need to define the overall Solution Building Blocks (SBBs) to finalize the Target Architecture based on the Architecture Building Blocks (ABBs).
We confirm readiness and risk for the business transformation and formulate Implementation and Migration Strategy. Next, we identify and group major work packages on the roadmap. We identify the Transition Architectures and create the Architecture Roadmap & Implementation and Migration Plan
In this phase, we build on the Phase E, and finalize the Architecture Roadmap and the supporting Implementation and Migration Plan.
We need to ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio.
Also, ensure that the business value and cost of work packages and Transition Architectures is understood by the key stakeholders.
We start by confirming the management framework interactions for the Implementation and Migration Plan. Based on the roadmap created in the phase E, we assign a business value to each work package. Next, we estimate the resource requirements, project timings, and availability/delivery vehicle.
We have to prioritize the various migration projects defined, by conducting of a cost/benefit assessment and risk validation.
Such architecture road map has to be confirmed with the stakeholders and updated in the Architecture Definition Document. Based on this , the Implementation and Migration Plan is completed.
The Architecture Development cycle completes with this phase. Here, we document lessons learned in the process.
In this phase, we ensure that the implementation projects conform with the Target Architecture. We ensure that the implementation projects perform appropriate Architecture Governance functions for the solution and any implementation driven architecture Change Requests.
We confirm scope and priorities for deployment with the development management. Identify the deployment resources and skills required for the implementation of the architecture. We need to guide development of solutions and deployment.
In the process, we should perform enterprise architecture compliance reviews. We should implement the various business and IT operations to enable the implementation. And once the implementation is complete, we should perform post-implementation review so that we can close the implementation phase.
In this phase, we ensure that the architecture lifecycle is maintained while it is updated and modified in the steady maintenance phase. We need to ensure that the Architecture Governance Framework is executed correctly. We must ensure that the Enterprise Architecture Capability that we developed, meets current requirements.
In order to do this, we establish a value realization process - that tracks the steps from requirement change to deployment of architecture capability. We need to deploy the relevant monitoring tools and manage risks. We should manage the entire governance process; and activate the process for implement architecture changes.
Here, we identify and develop change requirements to meet the required performance targets, and provide analysis for architecture change management.
Central to the entire ADM cycle is the requirement management. This is defined to ensure that the Requirements Management process is sustained and operates for all relevant ADM phases. Here, we manage architecture requirements identified during any execution of the ADM cycle or a phase. We ensure that relevant architecture requirements are available for use by each phase as the phase is executed.
In order to achieve this, we should Identify/document the baseline requirements. We monitor the baseline requirements to identify any changed requirements. We remove, add, modify, and re-assess priorities to these changed requirements. This also requires us to identify and resolve conflicts between requirements.
We assess individual changes by generating requirements impact statements. Based on this, we assess impact of changed requirements on current and previous ADM phases. We implement change in the current phase. We also need to assess and revise gap analysis for past phases.
Phase H is focused to managing changes - naturally produces changes in requirements. These are captured and the Architecture Requirements Repository is updated accordingly.