TOGAF 10 ADM: Complete Lifecycle from 4A Design to Governance

Enterprise architecture is often reduced to the four architecture domains — business, data, application, and technology (4A) — with heavy focus on current-state assessment, modeling, target design, and gap analysis. However, once the target architecture is defined, critical questions remain: how to translate it into concrete projects, ensure compliance during implementation, handle deviations driven by schedule pressure, and continuously adapt the architecture as business and technology environments evolve. Without answers, even well-crafted architectures risk staying on paper.

TOGAF's Architecture Development Method (ADM) addresses these gaps by covering the full lifecycle: preparation, design, implementation planning, implementation governance, and ongoing change management. Based on TOGAF 10, the author structures ADM into five areas: understanding ADM, architecture design, implementation planning, governance and evolution, and integrated application with a Huawei case study.

I. Understanding ADM: The Overall Framework

ADM is TOGAF's core method for guiding enterprise architecture development and lifecycle management. It is not merely a design procedure but a comprehensive method system spanning the entire architecture effort.

At a high level, ADM consists of a Preliminary Phase, Phases A through H, and Requirements Management that runs throughout.

Each phase has distinct responsibilities:

Preliminary Phase: Establish enterprise architecture capability, organization, principles, and governance foundation.

Phase A (Architecture Vision): Define the goals, scope, and direction of the architecture work.

Phase B (Business Architecture): Describe the enterprise's business capabilities and operating model.

Phase C (Information Systems Architectures): Cover Data Architecture and Application Architecture.

Phase D (Technology Architecture): Define the technology foundation supporting information systems.

Phase E (Opportunities and Solutions): Identify implementation opportunities, organize solutions and work packages.

Phase F (Migration Planning): Prioritize projects, allocate resources, and define the implementation path.

Phase G (Implementation Governance): Oversee project delivery to ensure conformance with architecture requirements.

Phase H (Architecture Change Management): Continuously identify and manage architecture changes.

Requirements Management: A continuous process (not a separate phase) that manages architecture requirements across all phases.

Two key clarifications:

The Preliminary Phase is not part of the formal A–H sequence; it ensures the organization has the necessary foundations (organization, principles, governance, capability) to undertake architecture work.

Requirements Management is not a final phase but a pervasive mechanism. As architecture design and implementation deepen, requirements continuously emerge, adjust, or change and must be managed uniformly.

ADM is not a rigid linear waterfall; enterprises can tailor and iterate based on scope, goals, and conditions. Understanding ADM means grasping the complete work process: from why architecture is initiated, to what architecture is designed, to how it is built, governed, and continuously adjusted.

II. Architecture Design: From Vision to 4A Target Architecture

Architecture design is the core of ADM. Starting from Phase A, the team clarifies goals, scope, stakeholders, and expected outcomes to form the Architecture Vision. Then Phases B, C, and D develop Business, Data, Application, and Technology Architectures — collectively known as 4A.

Note: 4A is a summarization of four architecture domains, not a formal TOGAF phase split. TOGAF formally defines Phase B as Business Architecture, Phase C as Information Systems Architectures (containing Data and Application), and Phase D as Technology Architecture.

1. Business Architecture: What the Enterprise Does and What Capabilities It Needs

Business Architecture focuses on how the enterprise creates value, what business capabilities it possesses, and how business activities are organized and executed. It bridges corporate strategy and IT investment.

It addresses four main areas:

Business Capabilities: What capabilities the enterprise needs to achieve business goals (e.g., customer management, product R&D, supply chain, marketing, finance). Capabilities are relatively stable and serve as a baseline for current-state analysis, gap identification, and digitalization planning.

Value Streams: From the customer's or stakeholder's value demand, describe how the enterprise creates and delivers value through a series of value stages. Value streams provide an end-to-end view of value creation.

Business Processes: The activities, tasks, and decisions undertaken to achieve specific business objectives. They answer how business operates, who performs what, and under what rules. Capabilities state what is needed; processes state how it is realized — related but distinct.

Organization and Business Information: Organizational structure describes units, roles, and responsibilities; business information describes information objects and relationships in business activities. These complement the capability and process views. Business architecture is not equivalent to org charts nor reducible to process diagrams.

In Phase B, architects establish baseline business architecture, design target business architecture, perform gap analysis, and produce corresponding architecture deliverables.

2. Data Architecture: What Information the Business Needs and How Data Is Organized

Data Architecture falls under Phase C (Information Systems Architectures). It concerns what data the enterprise must manage, relationships among data, how data is organized and flows, and data management requirements.

Main elements:

Data entities and concepts: Identify core business objects such as customer, product, contract, order, supplier, employee.

Logical data model: Describe entities, attributes, and inter-entity relationships.

Data distribution and flow: Analyze which business activities produce data, which systems consume it, and how it moves between applications.

Data management and governance requirements: Data quality, standards, security, ownership, lifecycle.

Data architecture must go beyond modeling to consider enterprise-wide data management and usage. In Phase C, architects baseline the current data architecture, design the target, and use gap analysis to identify issues to resolve.

3. Application Architecture: Which Systems Support Business Operations

Also part of Phase C, Application Architecture focuses on what application systems are needed, what services they provide, how they support business capabilities, and how they collaborate.

Main elements:

Application systems and components: Identify existing and target systems, analyze responsibilities, functional boundaries, and relationships.

Application functions and services: Determine what business functions and services each system provides and map them to business activities.

Application interaction and integration: Analyze data exchange, service calls, and business collaboration between systems.

Application portfolio and optimization: Assess duplication, dependencies, and construction plans to inform consolidation, replacement, and platform initiatives.

Application architecture should not simply mirror existing system menus; it must be driven by business needs and application responsibilities. Phase C delivers baseline and target application architectures with gap analysis identifying systems to add, adjust, consolidate, or retire.

4. Technology Architecture: The Technical Foundation for Applications and Data

Technology Architecture corresponds to Phase D. It addresses the technical infrastructure supporting data and application architectures: compute, storage, network, platforms, base software, and technical standards.

Main elements:

Compute and infrastructure: Servers, compute resources, storage devices, network equipment, cloud infrastructure.

Platforms and base software: Operating systems, databases, middleware, container platforms, cloud platforms, integration platforms.

Technical standards and constraints: Unified technical standards, reference architectures, selection requirements.

Technical deployment and runtime environments: Analyze deployment environments, resource organization, and operational coordination for applications.

Phase D establishes baseline and target technology architectures and uses gap analysis to determine upgrade, replacement, and construction needs.

5. How the 4A Domains Form a Cohesive Whole

The four domains are not independent; together they describe the complete chain from business value creation to information system support to technical runtime. Four questions capture the linkage:

Business Architecture: What does the enterprise do, and what capabilities are required?

Data Architecture: What information does the business need, and how is data organized and managed?

Application Architecture: Which application systems provide business functions and information services?

Technology Architecture: What technical environment do applications and data rely on?

For example, to improve customer service capability: Business Architecture defines the capabilities and processes involved; Data Architecture defines core entities like customer, product, order; Application Architecture specifies how CRM, order management, and service systems collaborate; Technology Architecture provides the compute, storage, network, and platform support. This forms a complete architecture chain from business goals to technical implementation.

Importantly, the relationship is not a simple one-way hierarchy. Design outcomes in data, application, and technology domains can feed back and influence business solutions. Architecture work requires repeated verification and iteration across domains. After 4A design, the enterprise produces baseline architectures, target architectures, gap analyses, and architecture definition deliverables to feed implementation planning.

III. Implementation Planning: Turning Architecture Design into Real Construction Tasks

Once 4A design is complete, the enterprise has a target architecture and a set of gaps to close. These gaps do not resolve themselves; they must be translated into construction tasks with clear ownership, resources, sequencing, and inter-project coordination. This is the purpose of Phases E and F.

Phase E: Identify Implementation Opportunities, Organize Solutions

Phase E consolidates gap analysis results from all four domains, identifies implementation opportunities, analyzes solutions, organizes work packages, and considers transition architectures.

Key questions:

Which architecture gaps should be addressed first?

Which construction tasks can be combined?

Which capabilities can be delivered via shared platforms?

What dependencies exist between work packages?

How to define target states for each phase?

Example: Multiple business domains request data sharing. Building separate sharing platforms would create new duplication. The enterprise must analyze common needs and shared capabilities from a holistic architecture perspective to form a more rational solution.

Phase F: Formulate an Executable Migration Plan

Phase F further evaluates work packages for business value, cost, risk, resource needs, and implementation priority.

Key questions:

Which projects should be implemented first?

Which projects can run in parallel?

What are the predecessor-successor dependencies?

How to arrange transition architectures?

What resources are required?

How to set project milestones?

The output is an Implementation and Migration Plan that defines the concrete path from current to target architecture.

Critical point: Phases E and F are not merely about listing gaps as projects; they must link architecture objectives, construction tasks, investment planning, and project execution. Architecture design answers "what to build"; implementation planning answers "how to realize it." Without this link, architecture struggles to enter the enterprise's investment decision and project construction processes.

IV. Governance and Evolution: The Core Safeguards for Architecture Landing

In practice, many efforts concentrate on 4A design and produce implementation plans, but architecture governance often weakens during actual project construction and subsequent operations. Common symptoms: architecture mandates unified technical standards, yet projects choose their own; architecture plans system consolidation, yet departments build independently; architecture reviews raise issues, yet no tracking occurs post-launch. Over time, target architecture diverges from actual construction, and architecture deliverables lose their guiding role.

Therefore, implementation and governance are not optional add-ons after 4A design; they are the critical core safeguards that move enterprise architecture from design to reality. TOGAF addresses this through Phase G (Implementation Governance) and Phase H (Architecture Change Management).

1. Phase G: Implementation Governance — Ensuring Projects Build to Architecture Requirements

The core task of Phase G is to ensure implementation projects conform to the approved enterprise architecture. This requires the architecture team to engage deeply in the project construction process, not just check documents after project completion.

Main activities:

Define implementation scope and priorities: Jointly confirm project scope, priorities, and architecture requirements with project management teams; clarify what the project must deliver.

Secure implementation resources and skills: Verify the project has needed personnel, technical capabilities, development methods, and tools to ensure the architecture solution is practically deliverable.

Guide solution deployment: Cascade enterprise architecture requirements into project design and development, guiding solution design to maintain alignment with target architecture.

Establish architecture contracts: Formalize architecture requirements, implementation responsibilities, delivery objectives, and compliance constraints via architecture contracts between governance and implementation parties.

Conduct architecture compliance reviews: Check implementation outcomes against architecture standards, principles, and project agreements. When deviations are found, analyze impact and apply remediation, exception permits, or change handling.

Perform post-implementation reviews: After delivery, verify whether actual outcomes meet expected targets, whether business and IT services operate normally, and record review results.

Emphasis: If enterprise architecture cannot enter the project construction process, it cannot effectively constrain actual building activities. The purpose of architecture governance is not to add approval layers but to ensure architecture requirements are implemented during project design, development, deployment, and delivery.

2. Phase H: Architecture Change Management — Keeping Architecture Aligned with Enterprise Evolution

Project go-live does not end architecture work. Enterprise strategy, business models, organizational structures, and technology environments change, potentially rendering the current architecture inadequate for new business needs. Phase H focuses on identifying, analyzing, deciding, and implementing architecture changes.

Main activities:

Establish value realization processes to track business value delivered by architecture investments.

Deploy monitoring tools to continuously observe business environment, technology environment, and architecture runtime performance.

Manage architecture risks by identifying factors that could affect sustained architecture operation.

Perform architecture change analysis to judge whether current architecture still meets business and performance requirements.

Formulate change requests specifying what architecture content needs adjustment and the expected goals.

Manage architecture governance processes to review change requests and exceptions.

Initiate change implementation processes to incorporate approved changes into architecture maintenance and implementation work.

Phase H distinguishes between maintenance changes (within existing architecture scope, handled via established governance) and major architecture changes (involving significant direction shifts, potentially triggering a new ADM cycle).

Phase G and Phase H address two different problems: G ensures project implementation conforms to architecture; H ensures enterprise architecture adapts as the environment changes. Together they safeguard sustained architecture effectiveness from design through implementation to operation.

If 4A design decides what the enterprise architecture should look like, implementation planning decides how to build it, implementation governance decides whether the build matches the architecture, and change management decides whether the architecture can continuously adapt to enterprise development. This is why enterprise architecture cannot prioritize design while neglecting implementation and governance.

V. Huawei Practice: How Enterprise Architecture Moves from Planning to Governance

The preceding sections outlined TOGAF ADM. How does this work in a real enterprise? Huawei's enterprise architecture practice offers a valuable case.

1. From Fragmented 4A Design to Unified Enterprise Architecture

At the 2023 Open Group Architect Conference, Huawei shared its enterprise architecture evolution practice. Enterprise architecture typically comprises business, information, application, and technology architectures. In early practice, these four domains were somewhat siloed: business architecture separate from information architecture, application and technology architectures insufficiently coordinated. This led to different disciplines doing architecture work without converging around a single business goal to form an integrated solution.

To address this, Huawei drove combination and collaboration of architecture capabilities, managing related capabilities through tools. This supports organizing capabilities, processes, data, and applications around business scenarios, enabling reuse of existing capabilities across scenarios with differentiated extensions per scenario.

2. Establishing Architecture Governance Mechanisms: Preventing Projects from Building in Isolation

After architecture design and implementation planning, the next challenge is ensuring projects actually follow the overall enterprise architecture. Huawei's practice introduced an enterprise architecture governance mechanism:

At the company level, an Enterprise Architecture Committee (EAC) reviews cross-domain business transformation needs and solutions, providing professional opinions to transformation decision teams.

Under EAC, four Senior Architect Groups (SAGs) correspond to:

Business Architecture SAG (BA-SAG)

Information Architecture SAG (IA-SAG)

Application Architecture SAG (AA-SAG)

Technology Architecture SAG (TA-SAG)

These expert groups participate in domain-level architecture principles, standards, and solution reviews.

At the business domain level, Requirements and Architecture Management Teams (RAMTs) drive architecture management and transformation demand alignment within the domain.

This mechanism exhibits several notable characteristics:

Company level owns overall architecture principles and cross-domain coordination, preventing siloed construction.

Professional SAGs provide domain-level expert reviews, ensuring architectural professionalism.

Domain-level RAMTs connect company-level requirements with actual business needs.

This aligns with ADM's governance emphasis: architecture needs clear accountability, professional review mechanisms, and formal decision processes — not just individual architect advocacy.

VI. Key Considerations for Applying ADM

Understanding ADM phases does not mean an enterprise can directly adopt the process wholesale. TOGAF provides a generic method; enterprises must tailor it to their organization, business, governance, and project management mechanisms. Four aspects deserve special attention in practice:

Requirements Management runs throughout: It is not a ninth phase but a continuous mechanism across all phases, responsible for requirement identification, recording, baseline management, change monitoring, and impact assessment, ensuring requirements flow continuously between architecture phases.

Architecture deliverables must connect sequentially: Architecture Vision, Architecture Definition Documents, Architecture Roadmap, Implementation and Migration Plan, Architecture Contracts, etc., are not isolated. Outputs from one phase become inputs to the next and are continuously refined.

Architecture design must enter project implementation: Architecture outputs must translate into project scope, construction tasks, and implementation requirements, enforced through architecture governance mechanisms. Architects must collaborate with business units, project management, and technical teams to embed architecture into the enterprise construction process.

Establish an enterprise architecture operating mechanism: Define architecture organization, role responsibilities, workflows, standards, and asset management. Through coordination of organization, process, assets, and project operations, integrate ADM into daily management and project construction.

Ultimately, enterprise architecture ceases to be a one-off design project and becomes a sustained management capability that continuously supports corporate strategy, business development, digital construction, and organizational transformation.

The outcomes of enterprise architecture should not stop at a design proposal but must be realized in the enterprise's project construction, business operations, and continuous transformation.

References

The Open Group, The TOGAF Standard, 10th Edition , Architecture Development Method and related phase content.

Huawei Enterprise Architecture Practice: ADM Transformation Planning and IT Architecture Governance. Practitioner's retrospective on supply chain and procurement domain architecture planning and governance practice.

Huawei's Modern Application Journey: Building Composable Enterprise Architecture Capabilities.