TOGAF (The Open Group Architecture Framework) is a widely used Enterprise Architecture (EA) framework. Version 9.2 keeps the core structure of TOGAF 9.1 but adds clearer guidance, a reorganized publication with an emphasis on the TOGAF Series Guides, and improvements to Business Architecture, the Content Meta-model, Security Architecture guidance, and industry reference models. This post summarizes the main concepts from TOGAF 9.1 and 9.2: the Architecture Development Method (ADM), content and repository, and architecture capability. The phase structure and ADM cycle described here are consistent across 9.1 and 9.2; the “in Pictures” guides (Orbus Software / The Open Group) for both versions are used as reference.

---

What is TOGAF?

TOGAF is a method and set of supporting resources for developing and governing Enterprise Architecture. It helps organizations:

• Understand current and target architectures (business, data, application, technology).
• Plan and govern change so that solutions stay aligned with business goals and standards.
• Reuse building blocks and manage an Architecture Repository.

TOGAF is not a fixed process. The ADM is more like a cookbook of recommendations, ideas, and checklists than a single mandatory way of working; it is always used with some adaptation. In a large enterprise, many projects may be using different phases of the ADM at the same time.

---

Architecture in TOGAF: domains, baseline, target, and transition

In TOGAF, architecture is a formal description of a system (or the enterprise), or a plan to guide its evolution. Architectures are described for four domains and in two states—baseline (as-is) and target (to-be)—with transition architectures for the path between them.

The four architecture domains

Domain	Scope	Key concerns	Typical artifacts
Business Architecture	How the enterprise operates to meet business goals	Capabilities, value streams, processes, organization, products, drivers	Capability map, process catalog, organization map, value stream diagrams
Data Architecture	Logical and physical data assets	Data entities, data ownership, storage, integration, master data	Data entity catalog, ER diagrams, data flow diagrams, data lifecycle
Application Architecture	Applications and their interactions	Application components, services, interfaces, integration	Application portfolio, application communication diagram, service catalog
Technology Architecture	Hardware, software, and communications platforms	Servers, networks, middleware, infrastructure services	Platform diagram, technology catalog, deployment diagram

Dependency order: Business Architecture is the driver; Data and Application Architectures enable the business (Phase C treats them together as Information Systems Architecture); Technology Architecture realizes the application and data components (Phase D). Gaps and roadmap components are traced across all four domains so that technology and application choices stay aligned with business outcomes.

Baseline, target, and transition architectures

• Baseline architecture: The current state—a documented description of the enterprise (or the in-scope area) as it is today. It is developed in Phases B, C, and D and used for gap analysis against the target. It is often incomplete or only partially documented; the ADM helps identify what to capture.
• Target architecture: The desired future state that supports the Architecture Vision and business requirements. It is also developed in B, C, and D. The gap between baseline and target drives the Architecture Roadmap and Implementation and Migration Plan.
• Transition architecture: One or more intermediate states between baseline and target. Large transformations are rarely done in one step; transition architectures describe viable intermediate states (e.g. after a set of work packages) so that benefits can be realized incrementally and risks managed. They are identified in Phase E and refined in Phase F.

Each domain (Business, Data, Application, Technology) can have its own baseline, target, and transition descriptions; the Architecture Definition Document holds these and the Architecture Roadmap ties them to work packages and timelines.

Views and viewpoints

• View: A representation of the architecture from the perspective of one or more stakeholder concerns (e.g. a process flow diagram for a process owner, a deployment diagram for an infrastructure team). Views are built from artifacts (catalogs, matrices, diagrams).
• Viewpoint: The convention or template for constructing a type of view—what to show, which notation, and for which concern. Viewpoints ensure consistency (e.g. “all process flow views use BPMN and show actors and data objects”).
• Stakeholder: Anyone with a concern relevant to the architecture (sponsors, users, project managers, operations). Stakeholder management identifies who they are, what they care about, and which views they need.

Architects select viewpoints that address stakeholder concerns, then create views that conform to those viewpoints. Views and viewpoints are part of the Content Framework and the Architecture Repository so that architecture descriptions remain understandable and reusable.

---

The ADM cycle: three chunks

The Architecture Development Method (ADM) is about understanding existing architectures and working out the best way to change and improve them. It can be thought of in three chunks:

Chunk	Phases	Focus
1. Set up an EA team and make sure it can do its work	Preliminary	Define the enterprise, principles, framework, governance, and architecture capability.
2. Get a good picture of the architecture: now and in the future	A, B, C, D	Architecture Vision; then Business, Information Systems (Data + Application), and Technology Architectures (baseline and target).
3. Find ways to make the changes, then make it happen	E, F, G, H	Opportunities & Solutions; Migration Planning; Implementation Governance; Architecture Change Management.

At the centre of the ADM diagram, Requirements Management runs through all phases: it manages stakeholder concerns and requirements and ensures that work products from every phase are coordinated.

---

Phase summary

Phase	Name	Purpose (short)
Preliminary	Prepare for ADM	Define enterprise, principles, governance, organizational model, tailored framework, architecture repository and capability.
A	Architecture Vision	Develop high-level vision and value; secure approval of Statement of Architecture Work; draft Architecture Definition Document.
B	Business Architecture	Describe how the enterprise needs to operate (capabilities, process, products) to meet business goals and drivers.
C	Information Systems Architecture	Data and Application Architectures: how they enable the Business Architecture and the vision.
D	Technology Architecture	IT platforms (hardware, communications) that enable the logical and physical application and data components.
E	Opportunities & Solutions	Consolidate gaps into an Architecture Roadmap; identify work packages and transition architectures; first version of Implementation and Migration Plan.
F	Migration Planning	Finalize roadmap and Implementation and Migration Plan with dependencies, costs, benefits; complete architecture development cycle; capture lessons learned.
G	Implementation Governance	Ensure implementation projects conform to the target architecture; perform compliance reviews; sign Architecture Contracts; deploy solutions.
H	Architecture Change Management	Manage changes to the architecture in a cohesive way; maintain the architecture lifecycle; ensure EA capability and governance stay fit for purpose.
—	Requirements Management	Sustain the requirements process for all ADM phases; manage and trace architecture requirements; feed requirements into each phase.

---

Preliminary Phase

Objective: Establish the foundation for the ADM so that architecture work can be initiated and governed.

Definitions established include:

• What the enterprise is and key drivers and elements in the organizational context.
• Requirements for architecture work and architecture principles (business, data, application, technology).
• The framework to be used (e.g. TOGAF tailored) and its relationship to other management frameworks.
• Architecture capability and Organizational Model for Enterprise Architecture (roles, governance, support).
• Architecture Repository (and its structure), Architecture Metamodel, and Standards Information Base.
• Evaluation of enterprise architecture maturity.

Key outputs: Architecture Governance Framework; Organizational Model for EA; Principles; Request for Architecture Work; Tailored Architecture Framework; Architecture Repository and related structures; Governance Log.

Steps (summary): Scope the enterprise; identify organizations and stakeholders; define principles; confirm governance and support; implement architecture tools; establish the architecture team; tailor frameworks.

---

Phase A: Architecture Vision

Objective: Develop a high-level vision of the capabilities and business value of the proposed architecture, and gain approval for a Statement of Architecture Work that defines the program of work.

Key inputs: Request for Architecture Work; business principles, goals, drivers; Organizational Model for EA; Tailored Architecture Framework; populated Architecture Repository.

Key outputs:

• Architecture Vision (problem description, key requirements, summary views, objectives).
• Approved Statement of Architecture Work (scope, plan, schedule, overview of vision).
• Capability Assessment; Communication Plan.
• Draft Architecture Definition Document (version 0.1 of baseline and target for business, data, application, technology).

Steps (summary): Define scope; identify stakeholders, concerns, and business requirements; develop architecture vision; define value propositions and KPIs; evaluate business capabilities and transformation risks; assess readiness; develop and secure approval for Statement of Architecture Work.

---

Phases B, C, D: Business, Information Systems, and Technology Architecture

These phases share a common structure (from TOGAF 9.1/9.2 in Pictures):

• Select reference models, viewpoints, and tools; identify required catalogs, matrices, diagrams, and types of requirements.
• Develop baseline and target architecture descriptions for the domain.
• Perform gap analysis between baseline and target.
• Define candidate roadmap components and resolve impacts across the architecture landscape.
• Create/update the Architecture Definition Document and Architecture Requirements Specification.

Domain focus:

• Phase B – Business Architecture: Capabilities, processes, products, organization; independent of technology. Describes how the enterprise must operate to achieve business goals and respond to strategic drivers.
• Phase C – Information Systems Architecture: Split into Data Architecture and Application Architecture. Describes how IS will enable the Business Architecture and the Architecture Vision. Data and application are often iterated together.
• Phase D – Technology Architecture: Hardware, software, communications platforms that realize the application and data components and support the vision.

Inputs and outputs are refined and updated across B, C, D; each phase produces domain-specific architecture components and candidate roadmap components.

---

Phase E: Opportunities & Solutions

Objective: Generate the initial Architecture Roadmap and identify Transition Architectures and delivery options (e.g. incremental).

Key inputs: The key inputs are from the Architecture Definition Phases (B, C, D)—gap analysis and candidate roadmap components—which are then consolidated and matched to investment opportunities and solution products; plus Architecture Vision, planning methodologies, and governance artefacts.

Key outputs:

• Architecture Roadmap (work package portfolio, transition architectures, implementation recommendations).
• Implementation and Migration Plan (version 0.1).

Steps (summary): Review gap analysis; identify major work packages/projects; identify constraints on implementation sequence; brainstorm technical, co-existence, and interoperability requirements; perform architecture assessment and gap analysis; consolidate into roadmap and initial migration plan.

---

Phase F: Migration Planning

Objective: Create and finalize the Implementation and Migration Plan in cooperation with portfolio and project managers. Finalize the Architecture Roadmap; ensure the plan is coordinated with the enterprise change management approach and the overall change portfolio; ensure the value and cost of work packages and Transition Architectures are understood by stakeholders. The level of detail in Phase F depends on the scope and goals of the overall architecture effort.

Key outputs:

• Finalized Architecture Definition Document (including transition architectures where applicable).
• Finalized Architecture Roadmap and Architecture Requirements Specification.
• Implementation and Migration Plan (Version 1.0) (strategy, project/portfolio breakdown).
• Reusable Architecture Building Blocks; possible Request for Architecture Work for a new ADM cycle; change requests for architecture capability from lessons learned.

Steps (summary): Confirm architecture roadmap and update Architecture Definition Document; prioritize migration projects (cost/benefit, risk); assign business value to work packages; estimate resources and timings; generate Implementation and Migration Plan; confirm management framework interactions; complete architecture development cycle and document lessons learned.

---

Phase G: Implementation Governance

Objective: Bring together all the information needed to manage the various implementation projects. In parallel, development executes and the actual build happens. Ensure conformance with the target architecture by implementation projects; perform Architecture Governance for the solution and any implementation-driven architecture change requests. Phase G establishes the connection between architecture and implementation through the Architecture Contract. A key aspect is ensuring compliance not only by the implementation projects but also by other ongoing projects.

Key inputs: Architecture Contract and Implementation Governance Model; Architecture Definition Document; Architecture Roadmap; Implementation and Migration Plan.

Key outputs:

• Architecture Contract(s) (signed).
• Architecture-compliant solutions deployed (implemented system, updated repository, compliance recommendations or dispensations, SLAs).
• Post-implementation updates to Architecture Vision and Architecture Definition Document; possible new Request for Architecture Work.

Steps (summary): Confirm scope and priorities with development management; identify deployment resources and skills; guide solution deployment; perform compliance reviews; implement business and IT operations; perform post-implementation review and close implementation.

---

Phase H: Architecture Change Management

Objective: Ensure the architecture achieves its original target business value by managing changes in a cohesive, architected way. Maintain and follow the architecture lifecycle; work within the Architecture Governance Framework; ensure the Enterprise Architecture Capability meets current requirements. Phase H is closely related to architecture governance and to management of the Architecture Contract between the EA function and business users. The change process determines how changes are managed and which ADM phases are impacted—e.g. changes that affect only migration may not require revisiting architecture development phases (B, C, D).

Key inputs: Architecture Contract; Change Requests (business, technology, lessons learned); Compliance Assessments; Repository and governance artefacts.

Key outputs:

• Architecture change process outcomes: classification of changes (e.g. simplification, incremental, re-architecting).
• Updates to Architecture Contract, Statement of Architecture Work, principles, and framework as needed.
• For major change: New Request for Architecture Work to start another ADM cycle.

Steps (summary): Establish value realization process; deploy monitoring tools; manage risks; provide analysis for architecture change management; develop change requirements to meet performance targets; activate the process to implement change; manage governance process.

---

Requirements Management

Requirements Management is central to the ADM: it runs across all phases and does not dispose of, address, or prioritize requirements—that is done in the relevant phase. It is the process for managing requirements throughout the ADM. It:

• Sustains the requirements management process for all ADM phases.
• Manages architecture requirements identified during any phase or cycle.
• Keeps requirements available for each phase (e.g. in an Architecture Requirements Specification and Requirements Repository).

Architecture requirements are invariably subject to change; dealing with changes is crucial—the “grey area” between what stakeholders aspire to and what can be delivered as a solution. When requirements are created or changed, a Requirements Impact Assessment (or Impact Statement) identifies which ADM phases need to be revisited; the statement is iterated to include full implications (costs, timescales, business metrics). The Architecture Requirements Specification and Repository are updated accordingly.

---

Architecture Repository and Enterprise Continuum

The Architecture Repository holds the outputs of architecture work and is the single source of truth for baseline, target, and transition architecture descriptions. It typically includes:

• Architecture Metamodel – The governed structure for architecture content (aligned with the Content Meta-model). Defines the building block types and relationships used across the four domains so that artifacts are consistent and traceable.
• Architecture Landscape – The current state of the enterprise (or in-scope area), organized by domain (Business, Data, Application, Technology). Holds baseline architecture content and is updated as transition and target states are implemented.
• Standards Information Base (SIB) – Standards, reference models (e.g. TRM, III-RM), and approved technologies that constrain and guide architecture decisions.
• Reference Library – Reusable architecture and solution building blocks, patterns, and best practices from past work or the continuum.
• Governance Log – Records of architecture governance decisions, dispensations, and compliance assessments.

The Enterprise Continuum is a way of classifying and reusing architecture and solution assets:

• Architecture Continuum: From Foundation Architectures (generic) through Common Systems and Industry to Organization-Specific architectures.
• Solutions Continuum: From Foundation Solutions through Common Systems and Industry to Organization-Specific solutions.

Architects search the continuum for candidate components and adapt them to the organization’s needs.

---

Content Framework: deliverables, artifacts, building blocks

TOGAF’s Content Framework describes the work products of architecture development:

• Deliverables – contractually specified outputs (e.g. Architecture Definition Document, Architecture Roadmap).
• Artifacts – concrete descriptions (catalogs, matrices, diagrams) that describe the architecture.
• Building blocks – reusable components (e.g. logical/physical application, data, technology components; business services).

Catalogs list things (e.g. data entities, application components). Matrices show relationships (e.g. process–application). Diagrams show views (e.g. process flow, deployment). Views are created for stakeholders using viewpoints (conventions for a type of view). Viewpoints and views are part of the content framework and repository.

Content Meta-model: building block types and relationships

The Content Meta-model (TOGAF 9.2) defines the types of building blocks and how they relate across the four architecture domains. It provides a consistent structure for the Architecture Repository and for tracing from business to technology.

Layer / domain	Core concepts (examples)	Relationships (examples)
Business	Actor, Role, Business Function, Business Capability, Process, Value Stream, Product, Driver, Goal, Objective	Actor has Role; Role performs Process; Process realizes Function; Function supports Capability; Capability enables Value Stream.
Data	Data Entity, Logical Data Component, Physical Data Component, Data Subject Area	Process creates/reads/updates/deletes Data Entity; Application Component manages Data Entity; Data Entity belongs to Subject Area.
Application	Logical Application Component, Physical Application Component, Application Service, Interface	Application Component implements Service; Component communicates via Interface; Process is supported by Application Component.
Technology	Platform Service, Logical Technology Component, Physical Technology Component, Node (e.g. server)	Application Component is deployed on Technology Component; Technology Component is hosted on Node; Platform Service is provided by Technology Component.
Cross-domain	Work Package, Gap, Requirement, Course of Action, Contract	Gap (baseline vs target) is addressed by Work Package; Work Package implements Course of Action; Requirement is satisfied by building block or Contract.

• Logical building blocks are technology-agnostic (e.g. “Customer Management Service”); physical building blocks are implementation-specific (e.g. “CRM application instance,” “Oracle DB server”). The ADM encourages defining logical first, then mapping to physical.
• Gap is a key meta-model entity: it represents a difference between baseline and target (e.g. “missing capability,” “application to be retired”). Gaps feed the Architecture Roadmap and Implementation and Migration Plan.
• The meta-model is tailored in the Preliminary Phase so that the organization’s repository and artifacts use a consistent vocabulary and traceability from business drivers to technology components.

---

Architecture Capability: governance, skills, compliance

Architecture Capability is the ability of the organization to perform EA. It includes:

• Governance – Architecture Board, governance bodies, authority structures, alignment with portfolio and project management; Architecture Contracts between the EA function and the business.
• Roles and responsibilities – e.g. Chief Architect, Domain Architects, Program Management Office; roles can be generic or project-specific.
• Skills – TOGAF references a Skills Framework; training and development so that the right people can populate the repository and govern projects.
• Compliance – Projects and solutions are assessed for conformance to the architecture. Levels might include: Non-Conformant, Compliant, Fully Conformant; dispensations and recommendations are recorded. Compliance is part of architecture governance.

---

Reference models (TRM, III-RM)

TOGAF provides reference models that can be tailored:

• Technical Reference Model (TRM) – A taxonomy of generic platform services (e.g. OS, network, data management, security, software engineering). It helps standardize and communicate the application platform.
• Integrated Information Infrastructure Reference Model (III-RM) – Focuses on business and infrastructure applications and their need for interoperability (e.g. brokering, management, information provider/consumer applications). It supports a service-oriented view of the infrastructure.

These sit in the Architecture Repository and Enterprise Continuum as foundation-level references.

---

Techniques and guidelines

TOGAF 9.2 includes many techniques (e.g. Business Scenarios, Capability-Based Planning, Gap Analysis, Risk Management, Stakeholder Management, Architecture Partitioning) and guidelines (e.g. iteration and different enterprise levels, security architecture and the ADM, using TOGAF for SOA). These are documented in the TOGAF Library and Series Guides and support tailoring of the ADM.

---

TOGAF 9.2: what changed (from “Need to Knows”)

• Leaner publication with emphasis on the TOGAF Series Guides for practical guidance.
• Business Architecture – Statement of Architecture Work and new artifacts; guides on Business Capabilities and Value Streams.
• Content Meta-model – Updated descriptions, new and renamed concepts, revised tables.
• Security Architecture – Guidance on risk and integrating TOGAF with the SABSA security framework.
• Industry reference models – More reference material in the TOGAF Library to support implementation.

---

Summary

Concept	Summary
Architecture	Four domains (Business, Data, Application, Technology); baseline, target, transition; views/viewpoints; Content Meta-model for building block types and relationships.
ADM	Cyclic method in three chunks: set up EA (Preliminary); describe current and target (A–D); plan and implement change (E–H). Requirements Management is central.
Phases	Preliminary → A (Vision) → B (Business) → C (Data & Application) → D (Technology) → E (Opportunities & Solutions) → F (Migration Planning) → G (Implementation Governance) → H (Change Management).
Repository & Continuum	Repository holds metamodel, landscape, standards, building blocks. Enterprise Continuum organizes architectures and solutions from foundation to organization-specific.
Content	Deliverables, artifacts (catalogs, matrices, diagrams), building blocks; Content Meta-model defines types and relationships across domains.
Capability	Governance, roles, skills, compliance; Architecture Contracts; conformance of projects to target architecture.

TOGAF 9.1 and 9.2 share the same ADM cycle and phase structure; 9.2 adds enhanced guidance, Series Guides, and refinements to Business Architecture, Content Meta-model, and Security. The full standard, Series Guides, and “in Pictures” materials—TOGAF 9.1 in Pictures and TOGAF 9.2 in Pictures (Orbus Software / The Open Group)—provide the detailed inputs, outputs, and steps for each phase and the structure of the repository and content.