TOGAF®, The Open Group standard, is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency. It's the most prominent and reliable enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals. Enterprise architecture professionals fluent in TOGAF standards enjoy greater industry credibility, job effectiveness, and career opportunities. TOGAF helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment.
The IT architecture needs to closely reflect the business goals of the organization. Indeed, specific techniques (business scenarios) should be used to ensure that the business goals are properly understood by the IT architect, and reflected in the IT architecture developed using TOGAF.
Here are the reasons that we should adopt TOGAF ADM for architecture development:
The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organization. The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners for serving the following purposes:
ArchiMate is a modeling standard introduced by the Open Group. It provides a rich set of modeling notations and concepts that supports modeling Enterprise Architectures consistently within and across domains.
Since both TOGAF and ArchiMate are standards maintained by the Open Group and they both are used in enterprise architecture development, many people are confused between them, asking questions like "what's the difference between TOGAF and ArchiMate?", "TOGAF vs ArchiMate?", etc. The TOGAF framework and the ArchiMate modeling language are both maintained by The Open Group. The TOGAF 9.1 and ArchiMate 2.1 or above work well together and are compatible and complementary for EA development. While TOGAF ADM is an EA framework that can be used to develop and implement enterprise systems, processes, and structures, ArchiMate can be served as a visual modeling language that can be used to create EA descriptions.
It is important to reiterate that the ArchiMate standard is a modeling language and not a framework. The ArchiMate language is widely used for developing visual EA models, usually in conjunction with the TOGAF ADM. Moreover, the TOGAF and ArchiMate standards can put together to provide a set of viewpoints that can be applied for modeling the different architectures.
The ArchiMate language consists of the ArchiMate core language, which includes the Business, Application, and Technology Layers, along with elements to model the strategy and motivation underlying an architecture, as well as its implementation and migration.
The figure below shows a simplified mapping of how the ArchiMate language can be used in relation to the phases of the TOGAF Architecture Development Method (ADM).
The code ArchiMate layers enables modeling of the architecture domains defined by TOGAF.
The Business, Application, and Technology Layers support the description of the Business, Information Systems, and Technology Architecture domains defined by the TOGAF framework, as well as their interrelationships.
The strategy & motivation extension enables the modeling of stakeholders, drivers for change, business goals, principles and requirements.
The strategy and motivation elements in the ArchiMate language can be used to support the Requirements Management, Preliminary, and Architecture Vision phases of the TOGAF ADM, which establish the high level business goals, architecture principles, and initial business requirements. They are also relevant to the Architecture Change Management phase of the TOGAF ADM, since the phase deals with changing requirements.
The implementation and migration extension enables the modeling of project portfolio management, gap analysis and transition and migration planning.
The implementation and migration elements of the ArchiMate language support the implementation and migration of architectures through the Opportunities and Solutions, Migration Planning, and Implementation Governance phases of the TOGAF ADM.
The ADM supports the concept of iteration at three levels:
Cycling around the ADM: The ADM is presented in a circular manner indicating that the completion of one phase of architecture work directly feeds into subsequent phases of architecture work.
Iterating between phases: TOGAF describes the concept of iterating across phases (e.g., returning to Business Architecture on completion of Technology Architecture).
Cycling around a single phase: TOGAF supports repeated execution of the activities within a single ADM phase as a technique for elaborating architectural content.
During application of the ADM process, a number of outputs are produced based on some inputs and steps according to the phase objective provided by the ADM.
For example:
In order to collate and present these major work products in a consistent and structured manner, TOGAF defines a structural model, in which to place them.
TOGAF provides a number of input and output deliverables from each phases:
A work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. It will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model
The preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture
The initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development
Business Architecture: the development of a Business Architecture to support the agreed Architecture Vision
Information Systems Architectures: the development of Information Systems Architectures to support the agreed Architecture Vision
Technology Architecture: the development of the Technology Architecture to support the agreed Architecture Vision
Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan
Implementation Governance provides an architectural oversight of the implementation
Architecture Change Management establishes procedures for managing change to the new architecture Requirements Management examines the process of managing architecture requirements throughout the ADM
The ADM is a comprehensive general method
Here is the overview of the TOGAF ADM for each of the development phase as shown in the following Figure:
| TOGAF ADM Phase | Phase Objective |
|---|---|
| Preliminary | Prepares the organization for a successful architecture project |
| A. Architecture Vision | Sets the scope, constraints and expectations for the project. Validate the business context and create the Statement of Architecture Work |
| B. Business Architecture | Develop Business Architecture. Develop baseline as-is and target to-be and analyze the gaps. |
| C. Information Systems Architectures | Develop Information Systems Architectures. Develop baseline as-is and target to-be and analyze the gaps. |
| D. Technology Architecture | Develop Technology Architecture. Develop baseline as-is and target to-be and analyze the gaps. |
| E. Opportunities and Solutions | Identify major implementation projects |
| F. Migration Planning | Analyze the costs, benefits and risks. Produce an implementation roadmap. |
| G. Implementation Governance | Ensure that the implementation projects conforms to the architecture |
| H. Architecture Change Management | Ensure that the architecture responds to the needs of the enterprise as changes arise |
| Requirements Management | Every stage of the project should be based on and validate business requirements. |
