The TOGAF Objective
The TOGAF® framework is an approach to “rapid” architectural development and effective governance. It does not prescribe the models to be used to represent the architecture, but guides the process during the creation of the architecture. Thanks to its scalability, it can be used for government organisations, large companies and even small and medium-sized enterprises. Looking at the different levels of architecture that a framework can support, TOGAF® attempts to support all levels, from enterprise, data and application architecture to technology architecture.
TOGAF Advantages
The TOGAF Standard consists of the following advantages:
A method tested and applied by thousands of digital architects;
A common dictionary, so that everyone can understand the information provided by the resulting architecture.
TOGAF Framework
The TOGAF® framework is made up of the following main parts:
- The Capability Framework: Who? Who should be involved?
- The Architecture Development Method (ADM) Cycle: What? What should be done?
- ADM guidelines and techniques: How? How should it be done?
- The Content Framework: Which? What documentation should be produced?
- Enterprise continuum and tools: Where? Where to store documentation?
9 Phases of TOGAF ADM
The TOGAF Standard as an architectural development method is a detailed approach, divided into phases, which explains how to manage the entire life cycle of an architecture. The phases are as follows:
Preliminary Phase – Framework and Principles
In this TOGAF Phase, the enterprise architecture team, the architectural principles and the framework to be used are defined.
Phase A: Defining Architecture Visions
This TOGAF Phase identifies :
- The list of stakeholders, their roles and implications
- A consensus on the objectives, requirements, constraints and architecture rules
- The scope impacted
- The development plan for the ADM cycle, and the human, technical and financial resources required
- Large-scale mapping of the initial architecture and the target architecture
- Identification of risks and the plan to reduce them
Phase B: Developing the Business Architecture
The business, with its requirements, processes and entities, governs the enterprise architecture. The TOGAF Phase Business B phase is used to define the target architecture and measure its impact. The results of this phase can be defined using, for example, UML or IDEF-0. The choice of modelling method used is based on the views required, the viewpoints of which are identified in this phase.
Phase C: Developing Information Systems Architectures
The aim of this TOGAF Phase is to describe the data architecture and the application architecture. The views created in this phase are again modelled in the chosen model. For databases, for example, this may be relational data modelling.
Phase D: Developing Technical Architecture
The aim of this TOGAF Phase is to describe the technological architecture that will form the basis for subsequent implementation work.
Phase E: Developing Solutions and Opportunities
This TOGAF Phase identifies the characteristics of the change, determines the implementation constraints, validates the dependencies and identifies any transition architecture. The outcome of this phase will form the basis of the implementation plan required to move to the target architecture.
Phase F: Migration Planning
This TOGAF Phase focuses on prioritising the projects and estimating the migration costs of the various projects. The end result is a detailed architecture roadmap, including the implementation and migration plan.
Phase G: Implement Governance
For each implementation project, a corresponding organisation is designated to ensure its implementation. At the same time, compliance reviews will be carried out to ensure that, at the end of this TOGAF Phase, the system is fully completed and implemented in accordance with the specifications.
Phase H: Architecture Change Management
The TOGAF® framework architecture lifecycle does not stop once the system has been implemented. The aim of this phase is to manage changes to the architecture in a consistent way. In order to keep the architecture flexible and dynamic, any technological or environmental changes must be quickly incorporated into the architecture. During this phase, a decision is taken on whether to formally initiate a new architecture evolution cycle for each change request. This decision must be made on the basis of predefined criteria, which will determine whether a change request only requires an update to the current architecture or a restart of the cycle. These criteria are not predefined by the TOGAF® framework, as risk acceptance differs too widely from one organization to another.
Requirement Management
The central circle of the ADM cycle shows us that the different phases of ADM are driven by requirements. The TOGAF® framework does not prescribe a specific way of collecting and managing these requirements, it only specifies what an effective requirements management process should be.
Inputs to the requirements management process are provided by the different phases of the ADM cycle.
Final Result
When applying the TOGAF® framework to create an architecture, many organizations do not always reap the expected benefits. This is usually due to the fact that an architecture is often implemented from the bottom up, where management is not sufficiently committed to achieving business objectives with architectural goals, making it impossible to achieve the intended business objective through the leverage of the architecture. This problem occurs with every framework used to create an architecture. It is therefore essential that the strategic plan used in phase A is shared and approved by the entire organisation.
QRP International offers TOGAF Courses in TOGAF Foundation, TOGAF Practitioner and TOGAF Combi. Write to us for more information!
Skip to content
