Study guide
2.1 Preliminary Phase Objectives, Inputs, and Activities
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
2.1 Preliminary Phase Objectives, Inputs, and Activities
Key Takeaways Explain This Topic AI
The Preliminary Phase has two objectives: determine the Architecture Capability the organization wants, and establish it.
The phase defines the 'where, what, why, who, and how' of doing architecture in the enterprise rather than executing a specific project architecture.
Essential inputs come from the wider enterprise: strategic drivers, business plans, governance and legal frameworks, existing architecture assets, and other management frameworks.
Key outputs include the Organizational Model for EA, the Tailored Architecture Framework (with Architecture Principles), the Initial Architecture Repository, and the Architecture Governance Framework.
A Request for Architecture Work is an optional Preliminary output that triggers Phase A; the Architecture Vision and Statement of Architecture Work belong to Phase A.
Last updated: October 2026
The Preliminary Phase is the foundation stone of the TOGAF Architecture Development Method (ADM). Rather than jumping directly into modeling systems, designing application components, or solving immediate technology crises, an organization must first construct its architecture capability. This preparatory discipline ensures that subsequent iterations of the ADM operate predictably, consistently, and with formal executive authorization.
In the TOGAF Standard 10th Edition, Enterprise Architecture (EA) is not treated as an informal technical committee or an ad-hoc documentation exercise. It is a formal, permanent business and organizational capability that requires clear executive sponsorship, defined operating models, tailored processes, and recognized governance authorities.
Official Objectives of the Preliminary Phase
The TOGAF Standard, 10th Edition gives the Preliminary Phase two objectives:
Determine the Architecture Capability desired by the organization : review the organizational context for EA, identify and scope the parts of the enterprise affected, identify the frameworks, methods, and processes that intersect with the capability, and establish a capability maturity target.
Establish the Architecture Capability : define and establish the Organizational Model for Enterprise Architecture, the detailed process and resources for Architecture Governance, the tools that support the capability, and the Architecture Principles.
The Five Fundamental Questions
The Preliminary Phase is often summarized as defining "where, what, why, who, and how we do architecture" in the enterprise. To establish an effective Architecture Capability, the lead architect and executive leadership must address five fundamental questions during the Preliminary Phase:
Why do we need an Architecture Capability? This question articulates the business value proposition and strategic context for architecture. It defines the business drivers, regulatory pressures, cost optimization mandates, and digital transformation goals that warrant investing in an EA capability. Without an unambiguous answer to 'why', the architecture practice risks becoming an academic ivory tower detached from executive priorities and business outcomes.
What is the scope of the capability? This question determines the organizational and operational boundaries within which the architecture team has authority. It identifies which business units, geographic divisions, legal entities, or partner ecosystems fall within the architecture practice's mandate, establishing the initial architecture footprint.
Who is responsible for doing architecture work? This question addresses the organizational model for enterprise architecture. It establishes reporting lines, defines roles (Chief Architect, Enterprise Architects, Domain Architects, Solution Architects), outlines skill competencies and training requirements, identifies key stakeholders, and establishes the composition of the Architecture Board.
Where will the capability be housed? This question identifies the organizational positioning of the architecture function. Architects evaluate whether the team operates centrally under the Chief Information Officer (CIO), Chief Technology Officer (CTO), or Chief Strategy Officer; whether it operates as a federated network embedded across business units; or whether it is integrated directly into agile value streams and product portfolios.
How will architecture work be performed? This question defines the methodology, notation standards, and tooling. It involves tailoring the TOGAF ADM to fit corporate culture, developing an organization-specific Enterprise Metamodel, adopting modeling standards like ArchiMate, integrating with agile delivery frameworks (such as SAFe or Scrum), and populating the initial Architecture Repository.
Essential Inputs to the Preliminary Phase
Practitioners must recognize where the inputs to the Preliminary Phase originate. Because this phase creates the architecture capability itself, its inputs are drawn almost entirely from enterprise context outside the architecture function:
Enterprise Strategic Drivers : Corporate mission statements, strategic plans, executive business goals, market opportunities, and competitive pressures that define what the business seeks to achieve.
Organizational Context : Existing corporate structures, organizational charts, executive hierarchies, corporate culture, budgeting cycles, and capital allocation frameworks.
Corporate Governance and Legal Mandates : Corporate board policies, internal audit standards, statutory regulations (such as SOX, HIPAA, and GDPR), enterprise risk management frameworks, and procurement guidelines.
Baseline Architectural Assets : Pre-existing technical documentation, legacy system inventories, informal architectural patterns, and previous IT strategies inherited across business divisions.
External Frameworks and Industry Standards : Open standards, industry reference models (such as BIAN in banking or eTOM in telecommunications), and management frameworks including ITIL, COBIT, and ISO/IEC/IEEE 42010.
Core Activities of the Preliminary Phase
Establishing the EA capability requires executing several coordinated activities:
Preliminary Activity Purpose and Practitioner Focus
Scoping the Enterprise Organizations Determine which business entities, subsidiaries, and shared services are governed by the capability.
Confirming Governance & Support Align architecture decision-making with corporate finance, capital investment gates, and procurement.
Defining the EA Team & Organization Specify team structures, job descriptions, RACI matrices, competency benchmarks, and funding models.
Formulating Architecture Principles Establish enduring rules, constraints, and guidelines that govern all subsequent architectural decisions.
Tailoring the TOGAF Framework Customize ADM phase transitions, metamodel entities, deliverable templates, and process integration points.
Implementing Tools & Repository Deploy enterprise modeling tools and establish the logical structure of the Architecture Repository.
Key Deliverables and Outputs
The outputs of the Preliminary Phase form the permanent operational infrastructure upon which all subsequent ADM project cycles depend:
Organizational Model for Enterprise Architecture : Details the organizational structure, executive sponsorship, team sizing, geographic distribution, roles, responsibilities, RACI matrices, and budget allocation for the architecture function.
Tailored Architecture Framework : Includes the tailored architecture method, tailored architecture content (deliverables and artifacts), the Architecture Principles, and configured and deployed tools, together with integration points with agile, project management, and IT service lifecycles.
Architecture Principles : A formal catalog of qualitative enterprise-level principles. Each principle contains four standardized components: Name , Statement , Rationale , and Implications .
Initial Architecture Repository : The repository structure populated with framework content (for example, the tailored metamodel, reference materials, and adopted standards), ready to receive architecture work products.
Restatement of, or reference to, business principles, business goals, and business drivers : The business context that later phases must respect.
Request for Architecture Work (optional) : The Preliminary Phase may itself produce the request that starts the first ADM cycle.
Architecture Governance Framework : The processes, structures, and responsibilities through which architecture work will be governed.
The Architecture of the EA Capability : A description of the capability itself, treated as an architecture that can be developed and improved.
Practitioner Exam Traps and Distinctions
On the TOGAF Enterprise Architecture Practitioner examination, candidates frequently encounter questions designed to test boundaries between the Preliminary Phase and Phase A:
Trap 1: Deliverable Timing (Preliminary vs. Phase A) : The Architecture Vision and Statement of Architecture Work are produced in Phase A . The Preliminary Phase produces the Organizational Model for Enterprise Architecture , the Tailored Architecture Framework , the Initial Architecture Repository , and the Architecture Governance Framework . The Request for Architecture Work is the input that triggers Phase A; TOGAF lists it as an optional Preliminary output, and it can also come from the sponsoring organization or from Phase F or Phase H for a new cycle.
Trap 2: Architecture Principles Formulation : Baseline, enterprise-wide Architecture Principles are established in the Preliminary Phase . While Phase A may define specialized, project-specific principles or refine existing ones, the enduring enterprise principles must already be in place before specific project engagements begin.
Trap 3: Capability Scope vs. Project Scope : Preliminary Phase defines the scope of the entire EA capability across the enterprise. Phase A defines the scope of a specific architecture engagement or project in response to a business request.