The Preliminary Phase sets up the EA capability BEFORE the ADM cycle begins. It runs once. It produces Architecture Principles — the enduring rules that govern ALL future architecture decisions. Phase A is where the first actual architecture cycle starts.
The Preliminary Phase is the preparation and initiation step that establishes the Architecture Capability within an organization — the ability to DO enterprise architecture. It answers the question: "How do we set up TOGAF for our organization?"
- ▸🔧 Establishes the EA organizational structure (team, roles, responsibilities)
- ▸📐 Produces Architecture Principles — the most important output
- ▸✂️ Tailors the TOGAF ADM to the specific organizational context
- ▸🏛️ Sets up Architecture Governance (Architecture Board, escalation paths)
- ▸🛠️ Implements Architecture Tools (Repository, modeling tools, templates)
- ▸📋 Defines scope — which business units, systems, geographies are in scope
- ▸🔁 Runs ONCE to set up the EA capability; Phase A–H then runs repeatedly
Explore each of the 6 Preliminary Phase steps with CDIPD real-world examples:
The Preliminary Phase sets up the EA Capability (the ability to DO architecture). Phase A begins the first actual ADM Cycle (the doing). You only run the Preliminary Phase once to set up the capability — then you run Phase A → H repeatedly for each architecture initiative.
Architecture Principles are the most critical output of the Preliminary Phase. They are enduring rules and guidelines that remain stable across multiple ADM cycles and inform every architecture decision.
- ▸📝 Structure: each principle has Name → Statement → Rationale → Implications
- ▸⏳ "Enduring" — principles change rarely; they survive multiple ADM cycles
- ▸🔑 Applied throughout the ADM — every phase tests decisions against the principles
- ▸5 principle categories: Business, Data, Application, Technology + Meta-principles
- ▸Example: "Interoperability" — Statement: "All DUK systems must expose open APIs." Rationale: "Prevents vendor lock-in." Implications: "All procurement must require documented APIs."
- ▸📌 Produced in Preliminary; referenced in Phase A (Architecture Vision) and beyond
TOGAF explicitly states that the ADM must be tailored to suit the needs of the organization. Using TOGAF "as-is" without tailoring is NOT the correct approach — tailoring IS compliance.
- ▸✂️ Skip phases not applicable to the org (e.g., combine C and D for small teams)
- ▸🌐 Combine TOGAF with other frameworks (ITIL, COBIT, SAFe, PRINCE2)
- ▸📚 Adapt TOGAF terminology to match organizational vocabulary
- ▸🗺️ Define which deliverables are mandatory vs. optional in this organization
- ▸⚠️ Exam trap: "tailoring TOGAF" is CORRECT behaviour, NOT non-compliance
- ▸📌 Tailoring decisions are documented as part of the Architecture Framework definition
One of the most frequently tested distinctions in OGEA-101: what belongs in Preliminary vs Phase A?
- ▸🔧 Preliminary: sets up EA CAPABILITY — the ability to do architecture
- ▸🌟 Phase A: starts the first ADM CYCLE — develops Architecture Vision for a specific initiative
- ▸📐 Architecture Principles → Preliminary (permanent rules, created once)
- ▸🎯 Statement of Architecture Work → Phase A (for a specific project cycle)
- ▸🏛️ Architecture Board establishment → Preliminary
- ▸🗺️ Stakeholder Map for a specific project → Phase A
- ▸✂️ Tailoring the ADM → Preliminary; APPLYING the tailored ADM → Phase A onwards