Study guide
14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
Key Takeaways Explain This Topic AI
Fundamental Content and the TOGAF Series Guides together form the TOGAF Standard, and the TOGAF Library is a structured library of resources that support it.
Series Guides cover general how-to, establishing an EA team, agile methods, Business Architecture, data, security, and reference models and method, with the TRM and III-RM marked historical.
TOGAF says a building block is what you use, while a pattern tells you how you use it, when, why, and what trade-offs you have to make.
Architecture Building Blocks capture architecture requirements in Phases A to D and guide the selection of Solution Building Blocks in Phase E.
The Integrating Risk and Security Series Guide addresses security and risk in every ADM phase, from Preliminary principles to Phase H change triggers.
Last updated: October 2026
14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
"Supporting the ADM Work" is the eighth Level 2 topic area. Its learning outcome asks you to choose applicable supporting means to execute the ADM . That means using the TOGAF Library to support practitioner work, applying the Business Scenarios technique, and understanding the purpose of compliance assessments. You should also know how migration planning techniques review and consolidate gap analysis results, how a repository can be structured using the TOGAF repository, how architecture levels organize the Architecture Landscape and set the expected level of detail, and the role of Architecture Building Blocks and when they are used. Most of these are taught elsewhere in this guide. This section ties them together and adds the TOGAF Library, architecture patterns, and security guidance.
The TOGAF Standard and the TOGAF Library
The TOGAF Standard, 10th Edition consists of two parts:
TOGAF Fundamental Content : six documents (Introduction and Core Concepts; Architecture Development Method; ADM Techniques; Applying the ADM; Architecture Content; Enterprise Architecture Capability and Governance).
TOGAF Series Guides : guidance on applying the standard in particular situations.
Together these form the TOGAF Standard. The TOGAF Library is a structured library of resources that support the standard.
Series Guides by Purpose
The 10th Edition groups its Series Guides roughly as follows:
Group Examples
General how-to A Practitioners' Approach to Developing EA Following the TOGAF ADM; Using the TOGAF Standard in the Digital Enterprise; Digital Technology Adoption
- Establishing an EA team The TOGAF Leader's Guide to Establishing and Evolving an EA Capability
- Agile methods Enabling Enterprise Agility; Applying the TOGAF ADM Using Agile Sprints
Business Architecture Business Capabilities; Business Capability Planning; Business Models; Business Scenarios; Information Mapping; Organization Mapping; Value Streams
- Data and information Business Intelligence and Analytics; Customer Master Data Management; Metadata Management
- Security Integrating Risk and Security within a TOGAF Enterprise Architecture
Reference models and method Architecture Maturity Models; Architecture Project Management; Architecture Skills Framework; Digital Business Reference Model; Government Reference Model; Microservices Architecture; and historical guides such as the TRM and III-RM
The Practitioner Body of Knowledge draws on a subset of these guides, including the Practitioners' Approach, the Leader's Guide, Enabling Enterprise Agility, the Business Architecture guides, Integrating Risk and Security, the Digital Enterprise guide, and Digital Technology Adoption. In Part 2, the Reference button opens this Body of Knowledge.
Choosing the Right Supporting Means
- Situation in a scenario Supporting means
- A stakeholder proposes a product instead of describing the problem Business Scenarios technique
Executives need to see what the business does, independent of the org chart Business Capabilities guide: capability map
The team must show how value reaches a customer and which capabilities enable it Value Streams guide: value stream map and value stream/capability cross-mapping
- Information concepts need to be clarified before data modeling Information Mapping guide
- Responsibilities across business units and partners are unclear Organization Mapping guide
- Agile teams want to apply the ADM in sprints Enabling Enterprise Agility; Applying the ADM Using Agile Sprints
Security concerns appear late, or risk ownership is unclear Integrating Risk and Security guide plus the Risk Management technique
- Gaps from several domains must be turned into projects Migration planning techniques (Section 8.3 and 9.2)
- The team must check that a project conforms Architecture Compliance review (Section 10.3)
- Reusable designs exist for a recurring problem Architecture patterns (below) and the Reference Library
- Architecture Patterns
Architecture Patterns are an ADM Technique in the 10th Edition. A pattern is generally described as an idea that has been useful in one practical context and will probably be useful in others. TOGAF relates patterns to building blocks this way: a building block is what you use; a pattern can tell you how you use it, when, why, and what trade-offs you have to make in doing so.
A pattern is commonly documented with:
- Name
- Problem : the issue the pattern addresses
- Context : the preconditions under which it applies
- Forces : the relevant constraints and how they interact
- Solution : how to resolve the forces
- Resulting context : the state after the pattern is applied, including trade-offs
- Examples , Rationale , Related patterns , and Known uses
TOGAF distinguishes architecture patterns , which express fundamental structural organization, from design patterns , which refine subsystems or components. Patterns are typically kept in the Reference Library of the Architecture Repository and used in Phases B to D and in Phase E when solutions are assembled.
Architecture Building Blocks and Architecture Levels
The Level 2 outcomes stress the role of Architecture Building Blocks and when they are used . ABBs capture architecture requirements: what functionality, interfaces, and qualities are needed, independent of products. They are defined and refined in Phases A to D, and in Phase E they guide the selection of Solution Building Blocks (Section 8.2). They are stored in the repository for reuse and classified by the Enterprise Continuum.
The level at which an architecture is developed determines its expected detail:
Strategic : an enterprise-wide summary for executive direction.
Segment : operating models and roadmaps at program or portfolio level.
Capability : detail on a unit of capability and its capability increments, enough to group and govern work packages.
Recognizing the level stops you from choosing an answer that is too detailed for a strategy engagement or too vague for a capability engagement.
Security Across the ADM
The Integrating Risk and Security guide treats security as a concern in every phase rather than a separate stage:
ADM phase Security and risk focus
Preliminary Security and risk principles, risk appetite, and how security governance fits the Architecture Capability
A Security stakeholders and concerns; how much security-specific architecture design is needed; business transformation risks
- B Business security requirements, including roles, responsibilities, and the business assets to protect
- C Information classification and protection; application security services
- D Technology security services and infrastructure controls
- E and F Security risks in transition states and their mitigation in the plan
- G Security criteria in compliance reviews and contracts
- H Changes in threats, regulations, and technology that trigger architecture change
- Requirements Management Security requirements tracked like any other, with impact assessment when they change
- Using These Means in Part 2
When a scenario describes a problem, ask which supporting means the standard offers for it before choosing an answer. The strongest answers usually apply the right technique, guide, or repository asset at the right level of detail, instead of inventing a new process or skipping straight to a product.