Introduction to TOGAF Architecture Development Method (ADM)

TOGAF (The Open Group Architecture Framework) is an open organizational framework. The framework itself is a well-documented body of knowledge, including detailed methods and a set of supporting tools for developing enterprise architecture. TOGAF 9.2 is the latest version of the framework.

• TOGAF is developed and maintained by members of The Open Group and works in a team called Architecture Forum. The first development of TOGAF version 1 was produced in 1995, and subsequent versions of TOGAF expanded and improved this knowledge system.
• TOGAF was developed through the joint efforts of more than 300 architecture forum members representing some of the world’s leading companies and organizations-so it is a good summary of general enterprise architecture practices.
• Developing and maintaining an enterprise architecture is a complex process involving many stakeholders and decision-making processes. TOGAF helps by documenting corporate architecture specifications, processes and work products.
• By using TOGAF, organizations can develop a consistent enterprise architecture that reflects the needs of stakeholders, adopts best practices, and appropriately considers current needs and perceived business needs in the future.

Where does TOGAF come from?

TOGAF originated from the U.S. Department of Defense’s Information Management Technology Architecture Framework (TAFIM). TOGAF 1.0 was finally released in 1995 after years of exploration, with permission from the US Department of Defense and the help of a large investment from the US government. TOGAF has released its ninth release so far, TOGAF 9 (the latest release is TOGAF 9.2)

Why TOGAF?

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:

• A comprehensive general method
• Complementary to, not competing with, other frameworks
• Widely adopted in the market
• Tailorable to meet an organization and industry needs
• Available under a free perpetual license
• Vendor, tool and technology neutral open standard
• Avoids re-inventing the wheel
• Business IT alignment
• Based in best practices
• Possible to participate in the evolution of the framework

What is ADM?

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:

• It describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF.
• It may be tailored to the organization’s needs and is then employed to manage the execution of architecture planning activities.

The architecture development method-often referred to as the abbreviation of ADM-is a detailed step-by-step process used to develop or change an enterprise’s architecture.

ADM describes 10 phases covering the architecture development cycle.

These phases are:

• Preliminary stage
• Phase A: Architectural Vision
• Phase B: Business Architecture
• Phase C: Information System Architecture
• Phase D: Technical Architecture
• Phase E: Opportunities and Solutions
• Phase F: Migration planning
• Stage G: Implement governance
• Phase H: Architecture change management
• Requirement management

ADM Input and Output

TOGAF provides a number of input and output deliverables from each phases:

• These are suggestions and need not be followed exactly
• Each deliverable produced should be versioned to indicate when a change has occurred
• The version numbering shown is also a suggestion and need not be followed

Deliverables

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

Initial stage:

The main goal of the initial stage is to determine and establish the required architectural capabilities of the organization.

One of the key parts is to determine what needs to be done and how to implement it. For example, the main output is an architectural work request that outlines the requirements and decides what scope, structure, tools, or architectural framework is needed to support this work.

At this stage, TOGAF is specifically tailored to meet the upcoming ADM iteration needs. We define basic principles, evaluate the ability of the enterprise structure and business to make required changes, and integrate TOGAF with other management frameworks. There are steps at this stage to limit the corporate organization affected by the proposed changes, confirm the correct governance and support framework, define and establish an EA team and organization, identify and establish architectural principles, customize TOGAF and any other frameworks, and implement tools. At the end of this phase, the EA team should be ready to follow the iterations of the ADM cycle. This is partly because the preliminary stage is shown at the top of the ADM diagram and outside the main loop of stages A to H.

Phase A: Architecture vision:

Phase A provides a clear architectural work statement that will be provided in the iteration of ADM. It also provides a vision for the proposed enterprise architecture. This sense of direction is essential to guide the work of ADM throughout the iteration process. The statement of architectural work defines the procedures for developing and deploying the architecture outlined in the architectural vision. It is the vision that provides the high-level desire for the functionality and business value that the proposed enterprise architecture will provide. Starting with the construction job application, Phase A provides a tool (this vision) to sell the benefits of the proposed capabilities to stakeholders and decision makers in the enterprise. Business scenarios are used to understand business requirements and help clarify the architectural requirements implied by the required functions. This is documented in the architecture work statement and is used to build consensus to support the final architecture. When the sponsoring organization signs the document, a consensus will emerge.

The steps in Phase A are to transform the construction work request into a clear architectural work statement, and to ensure that the company is able, ready, willing and committed to make the necessary architectural changes. This involves establishing an architecture project, including defining its scope, as well as confirming and elaborating the architecture and business principles. Phase A identifies stakeholders and their concerns and requirements, and confirms the business objectives, driving factors and constraints of the preliminary phase. To ensure success, it also assesses business capabilities, assesses the readiness for business transformation, and resolves any transformation risks.

Phase B: Business architecture:

TOGAF regards enterprise architecture as a way to improve business capabilities-this is why the first architecture development phase deals with business architecture .

ADM from the business point of view — in the preliminary stages of infrastructure work requests to determine the strong business demand, and further refined for Phase A in infrastructure work and architecture vision statement .

A key goal of the business architecture phase is to develop the target business architecture, which shows how the enterprise realizes the architecture vision and solves the architecture work request. Its second goal is to first identify candidate architecture roadmap components to bridge the gap between the baseline and the target business architecture. TOGAF regards business architecture knowledge as a prerequisite for architecture work in other fields (such as data, applications, and technology). Business architecture also demonstrates to key stakeholders the commercial value and return on investment of architecture work. Business models, such as activity or process models, use cases and class models, or node connection diagrams,

All three architecture development phases (B, C, and D) follow similar steps. It is important to reuse any available reference model and customize all outputs to address the stakeholder’s point of view. Then, the architect develops a baseline and goal description of the business architecture, and performs a gap analysis to determine how to transform from one to another.

Phase C: Information System Architecture:

TOGAF divides Phase C-Information System Architecture-into two parts, covering the development of data and application architecture. The TOGAF document has a short introductory chapter covering two domains, followed by separate chapters on data and applications. As with other architecture development stages (B&D), the goal is to develop the target information system architecture for data and applications, and to determine candidate architecture roadmap components based on the gap between the baseline and the target architecture.

Phase C always involves the combination of data and application architecture. Providing both are included, and it doesn’t matter in any order-there are advocates for both methods. The steps for data and applications are very similar-select reference models, viewpoints and tools; develop baselines and then locate architecture descriptions, perform gap analysis and define candidate roadmap components; and resolve any impacts in the overall architecture environment. After a formal stakeholder review, the architecture was finally determined and an architecture definition document was created.

The main difference between data and applications lies in the theme, which is reflected in the use of different reference models, technologies, and architectural representations. For example, data architecture may use entity relationships or class diagrams, while application architecture may use application communication diagrams or software engineering diagrams.

Phase D: Technical architecture:

Phase D is the phase of TOGAF, which develops the technical architecture for the architecture project. The technology architecture describes the structure and interaction of platform services and logical and physical technology components. Phase D develops the target technology architecture, which supports data and application components (developed in phase C) to realize business components.

The architectures developed in phases B, C and D are combined to realize the architecture vision-solving stakeholders’ concerns and construction work requests. As with other architecture development phases, Phase D identifies candidate architecture roadmap components to achieve the transition from Baseline to Target. The steps in Phase D are almost the same as those in Phase B and Phase C-the main difference is that the focus is now on technology. Therefore, this includes technical reference models and technical standards or measurements-such as performance, maintainability, location and latency or availability.

Determining the output and deliverables is very important to help build the technical architecture that truly supports the information system and business architecture. Obtaining the correct scope can speed up returns, while an overly large scope will hinder successful implementation. This is not about the deployment technology itself, but the development of a technical architecture that truly addresses the architectural vision and work requests.

Phase E: Opportunities and solutions:

Phase E gets its name-it is to find opportunities to provide the target architecture by implementing specific solutions. Phase E generates the first complete version of the architecture roadmap by combining the recommendations of the analysis and building development phases-B, C, and D.

At this stage, the main focus is on how to provide the architecture. Therefore, it focuses on creating an architecture roadmap, listing work packages in a timeline to achieve the target architecture. When the change is so large that it is impossible to go directly from the baseline to the target architecture, then stage E will produce an incremental approach, consisting of intermediate or transitional architectures. Phase E maps the required architectural changes to investment procedures and projects that have the funds and resources to execute the work package, and provide transition and target architectures. The input at this stage is almost everything output from the early stage. These steps take these outputs; consolidate them, analyze dependencies and reconcile differences; and reconfirm that the organization can make changes. Phase E improves and updates requirements, architecture documents and architecture roadmaps. The key output is the first step in the implementation and migration plan.

Phase F: Migration planning:

The early stages of ADM identified the need for architectural changes and then developed the business, data, application, and technical architectures to support this need. Then, in the second phase, a high-level implementation and migration plan is developed to take advantage of investment opportunities and identify specific solutions. Target Architecture: Phase F finalizes the detailed implementation and migration plan, as well as the final architecture roadmap.

It also ensures that the plan is coordinated with the change management methods used within the company and other plans in the overall change portfolio. Finally, Phase F ensures that key stakeholders fully understand the business value, the cost of the work package, and the transition and future architecture. Although the early stages of ADM are very guided by the enterprise architecture team, the stage from E to H requires collaboration with other change agents.

Phase F particularly requires close cooperation among the four management frameworks in order to make the implementation and resettlement plan a success.

The four areas are:

1. business plan
2. Enterprise Architecture
3. Portfolio management
4. project management

Through cooperation, these four areas must prioritize work, using criteria such as performance evaluation, return on investment, business value, key success factors, effectiveness measurement, and strategic fit.

Stage G: Implement governance:

The actual development and implementation takes place in parallel with phase G. Phase G ensures that the implementation project and other ongoing projects conform to the defined architecture.

Typically, the target architecture is developed as a series of transformations to achieve business value and benefits as quickly as possible and to mitigate the risks in the transformation plan. Each transformation is a step towards the target company to realize its own business interests.

By the time we reach phase G, the architecture has been developed (in phases A through D), opportunities and solutions to provide the architecture have been identified (in phase E), and detailed implementation and migration plans have been completed (in phase F). Thus, the role of the Phase G architecture team is to provide oversight of the architecture implementation. This is done by validating the scope and priorities of the deployment, guiding development and solution deployment, and performing compliance reviews.

Architecture contract documents are used to drive architecture changes. Generated at the beginning of phase G and approved by architecture functionality and those responsible for implementation, it is a mechanism for assessing the governance compliance of the architecture.

Phase H: Structure change management:

Nothing went according to plan-there will always be new requirements and changes to the architecture. Phase H describes the change management process to manage changes to the architecture in a cohesive and structured way. Usually, this requires continuous monitoring of governance requests, new technologies or changes in the business environment.

The process should support the realized enterprise architecture as a dynamic environment that can flexibly respond to these changes and develop rapidly. In Phase H, it is important for the governance body to set standards to determine whether a change request requires a simple architecture update, or whether it needs to initiate a new cycle of architecture development method (ADM). Changes must be directly related to business value. How to use the enterprise architecture is the most important part of the architecture development cycle, so it is crucial to monitor business growth and decline in Phase H.

In the end, the enterprise architecture that worked for the organization yesterday no longer supports current or future functions. The output of a change request in Phase H can be classified as simplification-usually driven by the requirement to reduce investment; incremental change-requiring additional value from existing investment; or redesign change, which is a requirement to increase investment and create new value driven by.

Architecture requirements management:

At each stage of ADM, requirements for generation, analysis and review are required. The requirements management phase describes the process of managing these architectural requirements throughout the ADM. The requirements management phase is the core of ADM-that’s why it is shown in the center of the ADM crop circle. This stage describes the requirements management process and how the process is linked to other stages of ADM. Requirements are not static-they dynamically evolve between each stage of our completion of ADM and the cycle of ADM.

The requirements of the enterprise architecture and subsequent changes to these requirements will be identified, stored and input and output related to the ADM phases, and between the ADM cycles. Dealing with changes in demand is crucial. Architecture deals with uncertainty and change-the “grey area” between stakeholder expectations and possibilities! Therefore, the architectural requirements will always change.

In addition, the architecture involves many driving factors and constraints that are beyond the control of the enterprise-such as changing market conditions or new legislation-which will produce changes in requirement in unforeseen ways.

TOGAF emphasizes that the requirements management process itself will not deal with, solve or prioritize requirements, because this is done in the relevant phase of ADM. The demand management stage is just the process of managing the demands in the entire ADM.

ADM Preliminary Phase

The preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture

Output Deliverables:

• Architecture principles
• Architecture repository
• Business principles, business goals, and business drivers
• Organization model for enterprise architecture
• Request for architecture work
• Tailored architecture framework

ADM Phase A: Architecture Vision

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

Output Deliverables:

• Architecture principles
• Architecture roadmap
• Architecture vision
• Business principles, business goals, and business drivers
• Capability assessment
• Communications plan
• Statement of architecture work
• Tailored architecture framework

ADM Phase B: Business Architecture

Business Architecture: the development of a Business Architecture to support the agreed Architecture Vision

Output Deliverables:

• Architecture definition document
• Architecture principles
• Architecture requirements specification
• Architecture roadmap
• Business principles, business goals, and business drivers
• Statement of architecture work

ADM Phase C: Information Systems Architecture

Information Systems Architectures: the development of Information Systems Architectures to support the agreed Architecture Vision

• Architecture definition document
• Architecture principles
• Architecture requirements specification
• Architecture roadmap
• Statement of architecture work

ADM Phase D: Technology Architecture

Technology Architecture: the development of the Technology Architecture to support the agreed Architecture Vision

Output Deliverables:

• Architecture definition document
• Architecture principles
• Architecture requirements specification
• Architecture roadmap
• Statement of architecture work

ADM Phase E: Opportunities & Solutions

Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases

Output Deliverables:

• Architecture definition document
• Architecture requirements specification
• Architecture roadmap
• Architecture vision
• Capability assessment
• Implementation and migration plan
• Statement of architecture work

ADM Phase F: Migration Planning

Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan

• Architecture building blocks
• Architecture definition document
• Architecture requirements specification
• Architecture roadmap
• Change request Implementation and migration plan
• Implementations governance plan
• Request for architecture work
• Statement of architecture work

ADM Phase G: Implementation Governance

Implementation Governance provides an architectural oversight of the implementation

Output Deliverables:

• Change request
• Compliance assessment
• Solution building blocks
• Statement of architecture work

ADM Phase H: Architecture Change Management

Architecture Change Management establishes procedures for managing change to the new architecture Requirements Management examines the process of managing architecture requirements throughout the ADM

Summary

The ADM is a comprehensive general method

• It recommends a sequence for various phases and steps involved in developing an architecture
• It is an iterative method
• It draws on the other parts of TOGAF for assets and processes
• It can be used with other deliverables from other frameworks

Here is the overview of the TOGAF ADM for each of the development phase as shown in the following Figure:

1. More about TOGAF ADM Guide-through
2. More about Just-in-Time TOGAF Templates
3. More about ArchiMate tools
4. Try Visual Paradigm FREE

TOGAF Introductory References

• What is TOGAF?
• TOGAF ADM Tutorial
• TOGAF 9.1 Framework-A Comprehensive Guide
• TOGAF Software for Enterprise Architecture
• The Best TOGAF Software

ArchiMate 3

• What is ArchiMate?
• Full ArchiMate Viewpoints Guide
• ArchiMate 3 Update
• What’s New in ArchiMate 3?
• Using ArchiMate Tool with TOGAF ADM