TOGAF Architecture Development Method Phases Explained
At a Glance
What is the TOGAF Architecture Development Method?
Quick Explanation of Phase A: Defining Architecture Vision
Quick Explanation of Phase B: Assessing the Business Architecture
Quick Explanation of Phase C: Developing Information Systems Architectures
Quick Explanation of Phase D: Describing and Developing Technology Architecture
Quick Explanation of Phase E: Identifying Opportunities and Solutions
Quick Explanation of Phase F: Creating a Migration Plan
Quick Explanation of Phase G: Governance Implementation
Quick Explanation of Phase H: Architecture Change Management
What is the TOGAF Architecture Development Method?
The TOGAF ADM is a logical approach to creating knowledge. Knowledge that:
- finds the cause of your organization's performance and risk shortfalls
- provides alternative corrections for the shortfalls
- enables key decision makers to select between architecture alternative
- provides the means to ensure implementation teams deliver the expected benefits, follow their constraints, and do not exceed acceptable risk
This is developing and using an enterprise architecture.
Remember, Enterprise architecture is a discipline that guides effective change. You find the source of a performance shortfall, and help your decision makers address the shortfall.
The TOGAF ADM supports the analysis creating knowledge you require. It guides you through the models and views that create your knowledge.
The TOGAF ADM is a high-level model. It is applicable across industries. and across enterprise architecture use cases. You adapt the TOGAF ADM to develop strategy, support portfolio, guide projects, and drive consistent value from solution delivery. The same ADM phases actioned through effective architecture work management.
The TOGAF ADM is an Information Flow Model
Everything in the ADM is about creating knowledge. Each of the Phases tells you how to create the knowledge you need. The TOGAF ADM is inherently incremental and iterative. Best practice architecture work management iteratively creates the missing work products.
Where the information exists in your EA Repository you use it and move on to missing knowledge.
TOGAF ADM graphic is a simplified representation showing essential information flows. The TOGAF ADM is not an activity sequence. Far too many people look at the TOGAF ADM graphic and misunderstand it as a linear waterfall process model.
Every time the EA team is undertaking any activity to develop the information that comes from an ADM Phase, they are executing a Phase. An Enterprise Architect always needs to consume the inputs and the mandatory outputs.
TOGAF ADM Overview
TOGAF ADM is the core of the TOGAF Standard. The ADM scale for every level of detail - strategy, portfolio, project, and solution delivery. The ADM applies to every specialized EA use case - acquisition integration, digital transformation, or IT modernization. The ADM is applicable across industries - manufacturing, software, consumer goods, financial services, or defense.
The ADM is all about developing just enough new information to enable your decision makers to make the best choice to improve your organization.
The ADM is broken into Phases - each ADM Phase is targeted on creating a different type of information.
The logical sequence of the ADM Phases - A, B, C, D, E, F, G, and H - isn't an activity flow. It is a simplified information flows. While the information needs largely flow do not get confused and try to think of a linear waterfall process model.
Every time the EA team needs to develop new information they execute the creating Phase. When creating new information the enterprise architect consumes the inputs and produces the outputs. This applies to all ADM phases.
Quick Explanation of Phase A: Defining Architecture Vision
This section has a quick explanation. Our article Phase A: Defining Architecture Vision goes into detail of the ADM Phase.
The TOGAF ADM uses the concept of an Architecture Project. Work to develop an architecture that helps your decision makers improve your organization.
Phase A creates the information that enables good architecture project execution. Without the Phase A set-up, an enterprise architect cannot have confidence they are working on the right problem, with the right constraints, and right stakeholders.
Architecture teams that jump right in to architecting should expect to slide off-course. In our consulting experience, most architecture teams work products are 80-90% waste. They answer the wrong question, at the wrong time. Their work product is not used to inform decision making and does not support implementation governance.
Phase A uses a concept of a Request for Architecture Work.
Using the steps of Phase A, architects develop the following knowledge:
- confirm the scope of the architecture project
We call this converting the ask into the problem - key stakeholders and concerns
- existing constraints from superior architecture
It creates the following central works products:
- an architecture vision
a suitable summary of one or more candidate target architectures - statement of architecture work
exactly what you think, a SoW for the architecture team
Do not be surprised if you start with several architecture alternative expressed as different Architecture Visions. Don't expect you will have enough information to find the best-path in Phase A.
You are trying to determine if there is no acceptable path forward. It is a great success to stop all architecture development if there is no potentially acceptable way to address a shortfall.
Usually the risk is too high, or the change consumes to many available resources. In short, there isn't enough value. When you find there is no acceptable solution, stop work! You have saved saved your organization's scarce change resources.
For more detail see TOGAF ADM Phase A - Start at the Beginning with an Architecture Vision. It looks at Phase A Deliverables, enabling Architecture Governance, and Phase A Guidelines and Techniques.
Quick Explanation of Phase B: Developing the Business Architecture
This section has a quick explanation. Our article Phase B: Developing the Business Architecture goes into detail of the ADM Phase.
TOGAF uses the concept of architecture domains. This phase develops the business architecture.
In an architecture project, Phase B builds on the Architecture Vison. The work is to confirm the summary targets hold together with enough analysis to prove the theory right, or eliminate the candidate from consideration.
Using the steps of Phase B, architects develop the following knowledge:
- what reference architecture will speed architecture development
- what viewpoints will drive relevant analysis for stakeholder to select between architecture alternatives
- what business architecture models will help find the source of the deficiency and the changes that will address it
- where changes in the business architecture drive change in other domains
- where changes in other domains drive changes in the business architecture
It creates the following central works products:
- views that analyze the candidate business architecture in terms of the stakeholder's concerns
- that a current and candidate target business architecture
- business architecture gaps
- candidate work products that change the business
Phase B centers on things like organizational design, process, information flows, business capability, and change planning. Proper assessment and understanding of this phase are critical.
For more detail see TOGAF ADM Phase B – Develop the Business Architecture covers Phase B deliverables, business architecture models and Phase B Guidelines and Techniques.
Phase C: Developing Information Systems Architectures
This section has a quick explanation. Our article Phase C: Developing the Application Architecture goes into detail of the ADM Phase.
Phase C drives further on concept of architecture domains. This phase develops the application architecture and data architecture. Formally Phase C splits treats the Data Architecture Domain and the Application Architecture Domain are individually.
Like Phase B, Phase C builds on the Architecture Vison. There is a twist, Phase C has a further obligation to enable the business architecture. This is not treating the business architecture as requirements, rather to confirm the developing summary targets hold together.
Changes in one domain drive constraints and requirements into other domains. The objective is to find the best set of changes across all domains.
Using the steps of Phase C, architects develop the following knowledge:
- what reference architecture will speed architecture development
- what viewpoints will drive relevant analysis for stakeholder to select between architecture alternatives
- what application architecture models and data models will help find the source of the deficiency and the changes that will address it
- where changes in the business architecture drive change in other domains
- where changes in other domains drive changes in the business architecture
It creates the following central works products:
- views that analyze the candidate information systems architecture in terms of the stakeholder's concerns
- that a current and candidate target business architecture
- business architecture gaps
- candidate work products that change the business
Phase C centers on things like application design, data flow, integration, development approach, build vs buy, and change planning. Proper assessment and understanding of this phase are critical.
For more detail see TOGAF ADM Phase C – Develop the Application Architecture covers Phase C Application Architecture deliverables, Application Architecture Models and Phase C Guidelines and Techniques.
Phase D: Describing and Developing Technology Architecture
This section has a quick explanation. Our article Phase D: Describing and Developing Technology Architecture goes into detail of the ADM Phase.
Phase D closes the end-to-end domain architecture concept. This phase has steps that develop an infrastructure, or technology architecture.
Phase D address the last domain to refine the Architecture Vison. Like Phase D, there is an additional focus. Phase D is intended to enable the information systems architecture. Again, this does not mean the information systems architecture provides requirements. It confirms the full set of changes to hold the end-to-end architecture together.
The objective is to find the best set of changes in all domains to meet the improvement objectives.
Using the steps of Phase D, architects develop the following knowledge:
- what reference architecture will speed architecture development
- what viewpoints will drive relevant analysis for stakeholder to select between architecture alternatives
- what application architecture models and data models will help find the source of the deficiency and the changes that will address it
- where changes in the business architecture drive change in other domains
- where changes in other domains drive changes in the business architecture
It creates the following central works products:
- views that analyze the candidate information systems architecture in terms of the stakeholder's concerns
- that a current and candidate target business architecture
- business architecture gaps
- candidate work products that change the business
Phase D centers on things like infrastructure design, IT services, cloud vs on-premise, communications and network, as well as build vs buy, and change planning. Proper assessment and understanding of this phase are critical.
For more detail see TOGAF ADM Phase D – Develop the Technology Architecture covers Phase D technology architecture deliverables, technology architecture models and Phase D Guidelines and Techniques.
Phase E: Identifying Opportunities and Solutions
This section has a quick explanation. Our article TOGAF ADM Phase E goes into detail of the ADM Phase.
Phase E transitions from the development and analysis of different domain architecture to the journey. Developing a target architecture without understanding the journey is pointless.
Using the steps of Phase E, architects develop the following knowledge:
- what intermediate points can you stop, or pivot, the journey while retaining value
- how different work efforts and risks affect potential value delivery
It creates one central work product:
- the Architecture Roadmap
The roadmap will identify projects, terms of reference, implementation strategy and provide terms of reference. Terms of reference will spell out governance directions: performance expectations, constraints, and risk appetite, and implementation strategy.
For more detail see TOGAF ADM Phase E covers Phase E architecture deliverables, architecture roadmap techniques and Phase E tools.
Phase F: Crafting a Migration Plan
Here is a quick explanation of ADM Phase F. TOGAF ADM Phase F – Craft the Implementation Plan goes into detail of the ADM Phase.
Phase F transitions from the enabling choices with the architecture roadmap to planning the implementation. The implementation plan incorporates all the essential elements and spells out the mode of implementation according to priority. Cost assessment, benefits, dependency evaluation, are some of the activities factored in.
Using the steps of Phase F, architects develop the following knowledge:
- what projects will deliver which work packages and transition architectures
- dependency across the implementation plan(s)
- terms of reference
- whether this set of projects require unique implementation governance.
It creates the following central works product:
- the implementation plan
- architecture contract
- implementation governance framework
For more detail see TOGAF ADM Phase F – Craft the Implementation Plan covers Phase F Implementation Plan Deliverables, implementation plan techniques and Phase E tools.
Phase G: Governance Implementation
This is a quick explanation. TOGAF® ADM Phase G - Ensure Value goes into detail of the ADM Phase.
Phase G switches from identifying the best path forward to implementing the best path forward. All of Phase G is focused on implementation governance. It is focused on delivering the expected value.
Using the steps of Phase G, architects develop the following knowledge:
- whether the implementation project is delivering expected value
- whether the implementation project is working within its constraints
- whether the implementation project is exceeding its assigned risk appetite
It creates the following central works product:
- get-well recommendation
For more detail see TOGAF® ADM Phase G - Ensure Value covers Phase G deliverables, Phase G techniques and Phase G tools.
Phase H: Architecture Change Management
This is a quick explanation. TOGAF® ADM Phase H - Ensuring Enterprise Agility goes into detail of the ADM Phase.
Phase H is your check-step. It confirms your organization harvests the target architecture's expected benefits. It look to see if the current environment changes the foundation of architecture analysis.
Using the steps of Phase H, architects develop the following knowledge:
- whether the implemented changes are delivering the expected value
- whether changes in your organization's environment altered the basis of architecture analysis
It creates the following core works product:
- architecture change request
a specialized Request for Architecture Work that drives change into the current Target Architecture - implementation value assessment
- threat and opportunity assessment
For more detail see TOGAF® ADM Phase H - Ensure Enterprise Agility covers Phase H deliverables, Phase H techniques and Phase H tools.
TOGAF Phase H - Applying Agile and our recorded Webinar True Life EA Webinar: Agile COVID-19 Response explain real-work realization of Enterprise Agility led by best-practice enterprise architects. Enterprise agility is all about the ability to respond to unanticipated opportunities and threats.
Specialized Phase to Architect an EA Capability
In this section, we will explain the TOGAF ADM Phases establishing an enterprise architecture capability.
Preliminary Phase - Framework and Principles
The introductory, also known as the Preliminary Phase, is used to develop the enterprise architecture team. It focuses on the key issues or questions that the enterprise architecture team must address. These include:
- Who does it target?
- Where to use it
- How to use the model
- Why do you need it
The above steps make the concept clearer to the stakeholder. It also makes application/ implementation and using it more straightforward. After understanding the preliminary phase, you'll be able to:
- Define an organization or enterprise
- Identify and understand the principal elements and critical drivers in an enterprise.
- Describe the needs for architecture work
- Define the principles that affect the architecture work
- Identify the most feasible framework for the organization
- Define how the different management frameworks connect
- Assess the enterprise architecture team's maturity
Final Thoughts
Complete understanding of the Architecture Development Method Phases helps draft the most feasible plan to improve your organization. It will capture the enterprise's vision, offer the best solutions to achieve this, and be scalable to meet ever-changing needs and market. Working with a firm like Conexiam makes achieving your goals and visions easier.
Our firm prides itself on being a leader regarding TOGAF Architecture Development Method. We have been in the field for a long time and have helped many enterprises achieve their digital transformation goals. Our online enterprise architecture training platform targets different clients and keeps abreast of the latest trends and innovations. By working with us, you'll reach your visions and goals with minimal hassle.
Please contact us. With us, implementing the best enterprise architecture is a stress-free process.