Evaluating the TOGAF Architecture Development Method

Objective

After completing this lesson, you will be able to explain the purpose, iterative nature, and structure of the TOGAF Architecture Development Method.

Tailoring the TOGAF Architecture Development Method

The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) is a core element of the TOGAF framework. TOGAF® is an open and widely adopted enterprise architecture framework that provides a structured approach to designing, planning, implementing, and governing enterprise information technology architectures. TOGAF is typically modeled across four architecture domains:

  • Business
  • Application
  • Data
  • Technology

The ADM is the step-by-step methodology that guides architects through the development of enterprise architectures. It is iterative, meaning it loops through its phases multiple times to refine and improve outcomes. Iteration occurs:

  • Across the entire ADM cycle
  • Between different ADM phases
  • Within individual ADM phases

Each iteration requires decisions on:

  • The scope and breadth of architecture coverage
  • The level of detail to be defined
  • The intended time frame, including intermediate milestones
  • Which architectural assets to use (for example, past iterations, industry models)

These decisions are to be aligned with enterprise priorities, available resources, and competencies.

ADM Phases Overview

  • Architecture Vision: This phase sets the foundation by outlining the project context and solution vision. Activities include defining the statement of work, initiating the architecture development cycle, and assessing organizational readiness.
  • Business Architecture: Describes how the business operates and aligns IT with business goals. Outputs include business processes, capabilities, and organizational structure models.
  • Information Systems Architectures:
    • Application Architecture focuses on the inventory and design of application systems and services.
    • Data Architecture defines data models, governance policies, and the flow of data within the organization.
  • Technology Architecture: This phase specifies the infrastructure, systems, and platforms needed to support business and IT systems. It includes networks, operating systems, and other foundational components.
  • Opportunities and Solutions: Develop a road map to guide the organization from its current state to the target architecture. Identify initiatives, projects, and their dependencies.
TOGAF Architecture Development Method phases diagram: Central Requirements Management, surrounded by eight phases, A-H, including Architecture Vision, Business Architecture, Technology Architecture, and so on.

The Architecture Development Method (ADM):

  • Is the primary component, the core, of The Open Group Architecture Methodology Framework (TOGAF).
  • Describes how to develop a specific enterprise architecture in the context of business requirements (a project.)
  • It is a process template for developing an architecture, organized in different phases.
  • Each phase has inputs and outputs in the form of architectural work products, including deliverables and work products within deliverables. The content structure of the architectural work products is defined by the Architecture Content Framework.
  • Some architectural work products (deliverables) are developed in several phases.
  • The ADM develops architectures on different levels, so-called architecture domains.

Phase A: Architecture Vision

  • Establishes the project and initiates the iteration of the ADM.
  • Sets the scope, constraints, and expectations of the architecture development (the project).
  • Develop a Statement of Architecture Work, describing a high-level aspirational vision of the capabilities and business value to be delivered due to the developed enterprise architecture.
  • Begin with the first draft of the Architecture Definition Document (a high-level outline of the architecture).

Key Architecture Work Products of Phase A, based on the following Artifacts

  • Statement of Architecture Work, Stakeholder Map
  • Business Goals, Business Drivers, and Objectives (usually defined elsewhere, but reviewed and restated as guidance)
  • Solution Context
  • Enterprise Capability Assessment (baseline and target capability level)
  • Architecture Vision (Solution Concept)

Phase B: Business Architecture

  • Describes how your enterprise must operate to achieve the business goals and respond to the strategic drivers
  • Represents the Business Capabilities in the context of an EA engagement
  • Represents how the organization delivers value
  • Includes information about organizational structure with a relationship to strategies, products, initiatives, and stakeholders

Key Architectural Work Products of Target Business Architecture, based on the following Artifacts:

  • Business Goals, Drivers, and Objectives for the enterprise and each organization unit (Organization Map)
  • Business Roles Catalog
  • Business Value Flows Diagram
  • Business Capability Map
  • Business Data Catalog
  • Business Footprint Diagram
  • Business Architecture road map (input for Architecture road map)

Phase C: Application and Data Architecture

  • Describes and documents your organization’s application environment
  • Describes the types of information and data being processed in your organization’s application environment
  • Develop Target Application and Data Architecture that enables the Target Business Architecture in a way that addresses stakeholder concerns and goals being expressed in the Statement of Architecture Work

Key architectural work products are Target Application Architecture and Target Data Architecture with these artifacts:

  • Solution Architecture Diagrams, which can encompass any of the following diagram types: Product Map, Solution Component Diagram, Solution Value Flow Diagram, or Solution Process Flow Diagram
  • Application Architecture Overview Diagram
  • Software Distribution Diagram
  • Solution Data Architecture Diagrams, which subsume any of the following diagram types: Conceptual Data or Solution Data Flow Diagram

Phase D: Technology Architecture

  • Describes and documents the deployment of your organization’s IT systems including hardware, software, and communications in specific Data Center locations
  • Develop Target Technology Architecture that enables the Target Business Architecture, Data, and Application Architecture building blocks to be delivered via technology components (for example, Operating Systems, virtualized environments, Hardware, Networks)

A key architectural work product is Target Technology Architecture with these artifacts:

  • Environments and Locations Diagram: grouping technology components into deployment environments (Data Centers)
  • Network and Communications Diagram: (for example, definition of communication lines/VPNs, and so on)
  • Container/virtualization environments
  • Hardware specifications

Phase E: Opportunities and Solutions

  • Identifies projects, programs, and portfolios that effectively deliver the target architecture identified in previous phases.
  • Build a best-fit road map that is based on stakeholder requirements, the enterprise’s business transformation readiness, and identified opportunities, solutions, and implementation constraints. The key is to focus on the final target while realizing incremental business value.

Key architectural work products are the finalized Business, Application/Data, and Technology Architectures, including Transition Architectures in the Architecture Definition Document, with these artifacts:

  • Architecture Roadmap (including Transition Architectures)
  • Migration Planning: Drafts for implementation/migration plan and Work Breakdown Structure
  • Benefits Diagram (linked to Business Drivers, Goals, and Objectives, for example, updated Business Footprint Diagram)

Note

Phases F, G, and H cover the implementation. SAP does not include these phases with SAP Enterprise Architecture Framework yet. Currently, SAP is referring to these topics as governance and change management during implementation as part of the SAP Activate Implementation Framework.