TOGAF 9.1 interactive study manual — ADM phases, four domains, building blocks, and memorisation flash cards

🏛️
TOGAF 9.1 — Study Manual
The Open Group Architecture Framework · 2011 Edition · Complete study reference with flash cards, ADM wheel, domain maps, and key concept definitions
10 ADM Phases 4 Architecture Domains 7 Standard Parts 34 Flash Cards
The Architecture Development Method (ADM) is the core of TOGAF — an iterative, repeatable method for developing Enterprise Architecture. Click any phase to see its objectives and key outputs.
Select a phase
Click any phase on the left to see its purpose, key steps, and primary outputs.
TOGAF organises enterprise architecture into four domains — sometimes called BDAT. Each has its own ADM phase (B, C, C, D) and produces specific architecture deliverables.
🏢
Business Architecture (Phase B)
The WHY and HOW of the enterprise
Business strategy, goals, and key business drivers
Organisational structures and functions
Business capabilities and value streams
Business processes and roles
Key deliverable: Business Architecture Definition Document
💾
Data Architecture (Phase C)
The information assets of the enterprise
Types and sources of data required by the enterprise
Logical and physical data models
Data management, quality, and lifecycle policies
Data governance and master data management
Key deliverable: Data Architecture Definition Document
📱
Application Architecture (Phase C)
The applications that process data
Application portfolio — what systems exist and are needed
Application interactions and dependencies
Application-to-function mappings
Legacy systems and candidate replacements
Key deliverable: Application Architecture Definition Document
⚙️
Technology Architecture (Phase D)
The infrastructure that runs everything
Software and hardware infrastructure components
Network and communications infrastructure
Technology standards and platforms
Cloud, virtualisation, and security infrastructure
Key deliverable: Technology Architecture Definition Document
MEMORY AID — BDAT
B
Business
Phase B
D
Data
Phase C
A
Application
Phase C
T
Technology
Phase D
Data and Application are both in Phase C — covered as Information Systems Architecture
TOGAF 9.1 is structured as a single document divided into 7 parts. Each part covers a distinct dimension of enterprise architecture. Understanding this structure helps you navigate the standard.
I
Introduction
High-level introduction to key EA concepts. Defines Enterprise Architecture, explains what TOGAF is, and introduces the core concepts that underpin the entire framework including the ADM and Architecture Repository.
II
Architecture Development Method
The ADM itself — the iterative process for developing Enterprise Architecture. Covers all 10 phases from Preliminary through Phase H plus Requirements Management at the centre. This is the heart of the standard.
III
ADM Guidelines & Techniques
Specific techniques for applying the ADM — including how to use TOGAF with other frameworks, iteration approaches, architecture principles, gap analysis, migration planning, and interoperability techniques.
IV
Architecture Content Framework
Defines the structured metamodel of architecture artefacts — deliverables, artefacts, and building blocks. Covers the Content Metamodel with formal definitions of all entities and their relationships. The "what gets produced" reference.
V
Enterprise Continuum & Tools
Describes the Enterprise Continuum — a virtual repository of all architecture assets. Covers the Architecture Continuum, Solutions Continuum, and the Architecture Repository. Also discusses tools for storing and managing architecture artefacts.
VI
TOGAF Reference Models
Two reference models provided: the Technical Reference Model (TRM) — a generic model for IT services and a taxonomy of platform services, and the Integrated Information Infrastructure Reference Model (III-RM) — for boundaryless information flow.
VII
Architecture Capability Framework
Describes how to establish and operate an Architecture Capability — the people, processes, skills, roles, and responsibilities needed to build and run an enterprise architecture function. Covers Architecture Governance structures and boards.
MEMORY AID — "I AM ECR A"
I — Introduction A — ADM M — Methods (Guidelines) E — Enterprise Content C — Continuum R — Reference Models A — Architecture Capability
Building Blocks are the reusable components of enterprise architecture. TOGAF defines two types — ABBs describe what is needed; SBBs describe how it is implemented.
Architecture Building Block (ABB)
What is needed — the specification
Captures architecture requirements — functional and non-functional
Defines what the component must do — not how it does it
Technology-agnostic — independent of any product or vendor
Drives the selection of Solutions Building Blocks
Example: "An identity management service that provides SSO"
Developed in Phases A to D of the ADM
Solutions Building Block (SBB)
How it is implemented — the product
Represents a specific product, service, or component that implements an ABB
Fully defined — ready to purchase, build, or reuse
Technology-specific — bound to a vendor, product, or standard
Selected from the Solutions Continuum or procured
Example: "Microsoft Entra ID implementing the SSO service ABB"
Developed in Phases E and F of the ADM
WHAT MAKES A GOOD BUILDING BLOCK — 7 qualities
1. Fulfils a function
Has a clear purpose within the architecture
2. Defined boundary
Clearly scoped — what is inside vs. outside
3. Published interface
Well-defined access contract for other BBs
4. Reusable
Can be used across multiple architectures
5. Interoperable
Works with other building blocks via standards
6. Composable
Can be combined with others to form higher-order BBs
7. Replaceable
Can be substituted without disrupting the whole
THE 3 WORK PRODUCT TYPES — deliverables, artefacts, and building blocks
Deliverable
Work product contractually specified and formally reviewed. End product — e.g. Architecture Definition Document.
Artefact
Architectural work product that describes architecture from a specific viewpoint — e.g. a diagram, catalogue, or matrix.
Building Block
Reusable component that can be combined with other BBs to deliver architectures and solutions. ABB or SBB.
The Enterprise Continuum is a virtual repository of all architecture assets — from generic foundation architectures to organisation-specific solutions. It has two halves: the Architecture Continuum and the Solutions Continuum.
ENTERPRISE CONTINUUM — from generic to specific
ARCHITECTURE CONTINUUM
Foundation Common Systems Industry Organisation-Specific →
Most genericMost specific
Drives
↕
Influences
SOLUTIONS CONTINUUM
Foundation Common Systems Industry Organisation-Specific →
Most reusableMost custom
Foundation
TOGAF TRM · generic IT capabilities
Common Systems
Shared systems across industries
Industry
Sector-specific reference models
Organisation
Enterprise-specific architecture
ARCHITECTURE REPOSITORY — 6 classes of architectural information
Architecture Metamodel
Organisation-specific metamodel — the rules for the content
Architecture Capability
Parameters, processes, roles, and responsibilities of the EA function
Architecture Landscape
Baseline and target architectures at strategic, segment, and capability levels
Standards Information Base
External standards — industry, legal, and organisational technology standards
Reference Library
Reference architectures, models, and patterns from the Enterprise Continuum
Governance Log
Requests for architecture work, decisions, compliance assessments, and waivers
Architecture Governance is the practice and orientation by which enterprise architectures are managed and controlled. It ensures that architecture is compliant and provides decision-making authority for architecture-related matters.
GOVERNANCE HIERARCHY
Corporate Governance — overall enterprise direction and accountability
↓
Technology Governance — IT strategies, policies, and standards
↓
IT Governance — IT resources and performance
↓
Architecture Governance — architectural decisions and compliance
ARCHITECTURE BOARD — responsibilities
Provide architectural oversight
Ensuring all architecture is consistent with the enterprise architecture
Identify reuse opportunities
Finding where architecture components can be shared across projects
Manage dispensations
Granting temporary waivers from architecture compliance
Approve architecture changes
Reviewing and approving architecture change requests
Monitor compliance
Conducting compliance reviews of implementation projects
Manage standards evolution
Updating and retiring architecture standards and patterns
4 LEVELS OF COMPLIANCE
Fully Conformant
All mandatory architecture requirements are met with no deviations
Conformant
All mandatory requirements met — some recommended items may not be addressed
Partially Conformant
Some requirements met — significant gaps remain. A dispensation is needed
Non-Conformant
Significant departure from architecture. Escalation and remediation required
34 flash cards covering all key TOGAF 9.1 exam concepts. Click the card to reveal the answer. Use the filter buttons to focus on specific areas.
Card 1 of 34
QUESTION
Loading...
Click to reveal answer
ANSWER
Essential TOGAF 9.1 definitions — understand these precisely and you will be able to answer both conceptual and applied exam questions.