TOGAF ADM: What is it and why is it so important?

Table of Contents hide

1 What is ADM?

2 Preliminary stage:

3 Phase A: Architecture Vision:

4 Phase B: Business Architecture:

5 Phase C: Information System Architecture:

6 Phase D: Technical Architecture:

7 Phase E: Opportunities and Solutions:

8 Phase F: Migration Planning:

9 Phase G: Implementing Governance:

10 Phase H: Architecture Change Management:

11 Architecture Requirements Management:

TOGAF is an open organizational framework. The framework itself is a well-documented body of knowledge, including a detailed methodology and a set of supporting tools for developing enterprise architectures. TOGAF 9.2 is the latest version of the framework.

TOGAF is developed and maintained by members of The Open Group, working in a team called the Architecture Forum. The initial development of TOGAF version 1 was made in 1995, and subsequent versions of TOGAF have expanded and improved this body of knowledge.
TOGAF was developed through the combined efforts of over 300 Architecture Forum members representing some of the world’s leading companies and organizations – so it is an excellent 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 enterprise architecture specifications, processes, and work products.
By using TOGAF, organizations can develop a consistent enterprise architecture that reflects stakeholder needs, adopts best practices, and takes due account of current needs and future-perceived business needs.

What is ADM?

Architecture Development Methodology – often referred to as an acronym for ADM – is a detailed step-by-step process for developing or changing an enterprise architecture.

TOGAF ADM Iteration Cycles

ADM describes 10 phases covering the architecture development cycle.

These steps are:

preliminary stage
Phase A: Architecture Vision
Phase B: Business Architecture
Phase C: Information System Architecture
Phase D: Technical Architecture
Phase E: Opportunities and Solutions
Phase F: Migration Planning
Phase G: Implementing Governance
Phase H: Architecture Change Management
ADM Architecture Requirements Management

Preliminary stage:

The primary objective of the preliminary phase is to identify and establish the architectural capabilities required by the organization.

A key part of this is identifying what needs to be done and how to implement it. For example, the primary output is an architecture work request that outlines the requirements and decides what scope, structure, tooling, or architectural framework is needed to support this work.

At this stage, TOGAF is tailored to meet the needs of the upcoming ADM iteration. We define fundamental principles, assess the ability of the enterprise architecture and business to make the required changes, and integrate TOGAF with other management frameworks. There are steps in this phase to limit the enterprise organization affected by the proposed change, identify the correct governance and support framework, define and establish the 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 an iteration 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 statement of work that will be provided in iterations of the ADM. It also provides a vision of the proposed enterprise architecture. This sense of direction is critical in guiding the work of ADM throughout the iteration. This statement of architectural work defines the work procedures for developing and deploying the architecture outlined in the architectural vision. It is the vision that provides the high-level desire for the capabilities and business value that the proposed enterprise architecture will provide. Beginning with a construction job application, Phase A provides a tool (this vision) to sell the benefits of the proposed capability to stakeholders and decision makers within the business. Business scenarios are used to understand business requirements and help clarify the architectural requirements implied by the required functionality. This is documented in the Architecture Work Statement, which is used to build consensus to support the final architecture. Consensus occurs when the sponsoring organization signs the document.

The steps in Phase A are all about transforming a construction work request into a clear architectural work statement and ensuring that the business is able, ready, willing and committed to make the necessary architectural changes. This involves establishing the architecture project, including defining its scope, as well as identifying and elaborating the architecture and business principles. Phase A identifies stakeholders and their concerns and requirements, and identifies business goals, drivers and constraints in the preliminary phase. To ensure success, it also assesses business capabilities, assesses business transformation readiness, and addresses any transformation risks.

Phase B: Business Architecture:

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

ADM starts from a business perspective – strong business requirements are identified in the Architecture Work Request in the Preliminary Phase and further refined into the Architecture Work and Architecture Vision Statement in Phase A.

A key objective of the business architecture phase is to develop a target business architecture that demonstrates how the enterprise realizes the architecture vision and addresses architecture work requests. Its second goal is to first identify candidate architecture roadmap components to bridge the gap between the baseline and target business architecture. TOGAF considers business architecture knowledge as a prerequisite for architecture work in other domains such as data, applications, and technology. Business architecture also demonstrates the business value and return on investment of the architecture effort to key stakeholders. business models, such as activity or process models, use case and class models, or node connection diagrams,

Similar steps are followed for all three architecture development phases (B, C, and D). It is important to reuse any available reference models and customize all outputs to address stakeholder views. The architect then develops a baseline and target description of the business architecture and performs a gap analysis to determine how to transition from one to the other.

Phase C: Information System Architecture:

TOGAF divides Phase C – Information Systems Architecture – into two parts, covering the development of data and application architectures. The TOGAF documentation has a short introductory chapter covering both domains, followed by separate chapters for data and applications. As with other architecture development phases (B&D), the goal is to develop a target information system architecture for data and applications, and to identify candidate architecture roadmap components based on the gaps between the baseline and target architectures.

Phase C always involves a combination of data and application architecture. It doesn’t matter in which order it is provided that both are included – there are advocates for both approaches. The steps for data and applications are very similar – select reference models, viewpoints and tools; develop a baseline then locate an architectural description, perform a gap analysis and define candidate roadmap components; and address any impacts across the architectural context. Following a formal stakeholder review, the architecture was finalized and an architecture definition document was created.

The main difference between data and applications is the subject, which is reflected in the use of different reference models, techniques and architectural representations. For example, data architecture might use entity-relationship or class diagrams, while application architecture might 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. Technology architecture describes the structure and interaction of platform services and logical and physical technology components. Phase D develops the target technology architecture that supports the data and application components (developed in Phase C), enabling the business components.

The architectures developed in Phases B, C and D combine to realize the architectural vision – addressing stakeholder concerns and requests for construction work. Like other architecture development phases, Phase D identifies candidate architecture roadmap components to enable the transition from Baseline to Target. The steps in Phase D are almost identical to those in Phases B and C – the main difference being 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.

It is important to identify outputs and deliverables to help build the technical architecture that truly supports the information system and business architecture. Getting the right scope can speed up payback, while too much scope will hinder successful implementation. It’s not about deploying the technology itself, it’s about developing the technical architecture that really addresses the architectural vision and work requests.

Phase E: Opportunities and Solutions:

Phase E gets its name – it is looking for opportunities to deliver the target architecture by implementing a specific solution. Phase E generates the first full version of the architectural roadmap by combining the analysis and recommendations of the building development phases – B, C and D.

This phase focuses on how to provide the schema. Therefore, it looks at creating an architectural 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 Phase E results in an incremental approach, consisting of intermediate or transitional architectures. Phase E maps required architectural changes to investment programs and projects with funding and resources to execute work packages and provide transition and target architectures. The input to this stage is pretty much everything that was output from the earlier stages. These steps take those outputs; consolidate them, analyze dependencies and reconcile differences; and reaffirm that the organization is capable of making changes. Phase E refines and updates requirements, architecture documentation, and architecture roadmap. A key output is the first step in an implementation and migration plan.

Phase F: Migration Planning:

The early stages of ADM identify the need for architectural changes and then develop business, data, application and technical architectures to support this need. The second phase then develops a high-level implementation and migration plan to capitalize on investment opportunities and identify specific solutions. target architecture . Phase F finalizes the detailed implementation and migration plan , as well as the final architectural roadmap.

It also ensures that the plan is aligned with the change management approach used within the enterprise and with other plans across the 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. While the early stages of ADM are very much guided by the Enterprise Architecture team, the stages from E to H require collaboration with other change agents. Phase F specifically requires the four management frameworks to work closely together for the implementation and resettlement program to be successful. The four areas are:

business plan
Enterprise Architecture
Portfolio Management
project management

Working together, these four areas must prioritize work, using criteria such as performance measurement, return on investment, business value, critical success factors, effectiveness measures, and strategic fit.

Phase G: Implementing Governance:

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

Typically, the target architecture is developed as a series of transitions to realize business value and benefits as quickly as possible and reduce risk in the transformation plan. Each transformation represents a step towards the target company and realizes its own business interests.

When we reach Phase G, the architecture has been developed (in Phase A to Phase D), the opportunities and solutions to deliver the architecture have been identified (in Phase E), and a detailed implementation and migration plan has been completed (in Phase F) ). Therefore, the role of the Phase G architecture team is to provide oversight of the implementation of the architecture. This is done by confirming the scope and priority of deployment, guiding development and solution deployment, and performing compliance reviews. Architectural contract documents are used to drive architectural changes. Generated at the beginning of Phase G and approved by the architecture function and those responsible for implementation, it is the mechanism for assessing architecture governance compliance.

Phase H: Architecture Change Management:

Nothing goes exactly as planned – there will always be new requirements and requirements to change the architecture. Phase H describes the change management process to manage changes to the architecture in a cohesive and architectural manner. Often, this requires continuous monitoring of governance requests, new technologies, or changes in the business environment.

The process should support the implemented enterprise architecture as a dynamic environment that can flexibly evolve rapidly in response to these changes. In Phase H, it is critical that the governing body sets the criteria to judge whether a change request requires a simple architectural update, or whether a new cycle of the Architecture Development Method (ADM) needs to be initiated. It is important to avoid “crawling graceful”, so changes must be directly related to business value. How the enterprise architecture is used is the most important part of the architecture development cycle, so monitoring business growth and decline in Phase H is critical. Ultimately, the enterprise architecture that worked for an organization yesterday no longer supports current or future functionality. Change request outputs from Phase H can be categorized as simplification – typically driven by a requirement to reduce investment; incremental change – required to capture additional value from existing investment; or redesign change, which is driven by a requirement to increase investment and create new value driven.

Architecture Requirements Management:

Requirements are generated, analyzed and reviewed at each stage of ADM. The requirements management phase describes the process of managing these architectural requirements throughout ADM. The Requirements Management stage is the heart of ADM – that’s why it’s shown in the center of the ADM Clipping Circle. This phase describes the process of requirements management and how that process links to the other phases of ADM. Requirements are not static – they evolve dynamically as we complete each stage of ADM and between cycles of ADM. The requirements of the enterprise architecture and subsequent changes to those requirements will be identified, stored and input and output related to the ADM phases, and between the cycles of the ADM. Handling changes in demand is critical. Architecture deals with uncertainty and change – the ‘grey area’ between stakeholder expectations and possibilities! Therefore, architectural requirements are always subject to change. Furthermore, architecture involves many drivers and constraints that are beyond the control of the business – such as changing market conditions or new legislation – which can create changes in demand in unforeseen ways. TOGAF emphasizes that the requirements management process itself does not address, resolve or prioritize requirements as this is done in the relevant phase of ADM. The requirements management phase is simply the process of managing requirements throughout the ADM. Therefore, architectural requirements are always subject to change. Furthermore, architecture involves many drivers and constraints that are beyond the control of the business – such as changing market conditions or new legislation – which can create changes in demand in unforeseen ways. TOGAF emphasizes that the requirements management process itself does not address, resolve or prioritize requirements as this is done in the relevant phase of ADM. The requirements management phase is simply the process of managing requirements throughout the ADM. Therefore, architectural requirements are always subject to change. Furthermore, architecture involves many drivers and constraints that are beyond the control of the business – such as changing market conditions or new legislation – These all create changes in demand in unforeseen ways. TOGAF emphasizes that the requirements management process itself does not address, resolve or prioritize requirements as this is done in the relevant phase of ADM. The requirements management phase is simply the process of managing requirements throughout the ADM. TOGAF emphasizes that the requirements management process itself does not address, resolve or prioritize requirements as this is done in the relevant phase of ADM. The requirements management phase is simply the process of managing requirements throughout the ADM. TOGAF emphasizes that the requirements management process itself does not address, resolve or prioritize requirements as this is done in the relevant phase of ADM. The requirements management phase is simply the process of managing requirements throughout the ADM.

(*Source: TOGAF ADM: 它是什么，它为什么如此重要？)

TOGAF

ArchiMate 3