The Preliminary Phase (often called “Phase 0”) is the foundational step in the TOGAF Architecture Development Method (ADM). Before any actual architecture design begins, an organization must prepare itself to successfully undertake and sustain architecture work. This phase is dedicated to defining where, what, why, who, and how architecture will be performed within the enterprise. It establishes the organizational readiness, governance structures, tools, and guiding principles that will support all future architecture development cycles.
For beginners, think of the Preliminary Phase as laying the foundation and framing of a house. You wouldn’t start building walls or installing plumbing without first surveying the land, securing permits, agreeing on a blueprint style, and assembling the right crew. The Preliminary Phase does exactly that for Enterprise Architecture (EA).
The primary goal of this phase is to create an Architecture Capability within the organization. This capability encompasses the people, processes, tools, and governance needed to consistently deliver value through architecture. Specifically, the phase aims to:
Determine the desired Architecture Capability: Review the organizational context, identify which parts of the enterprise will be affected, recognize existing frameworks/processes that intersect with EA, set a target maturity level, and formally establish the capability.
Establish the Architecture Capability: Define the organizational model, detail governance processes and resources, select and implement supporting tools, and formally define Architecture Principles.
The Preliminary Phase follows a structured approach divided into seven key aspects. Below is a breakdown of each concept, followed by a practical example tailored for beginners.
Concept: Enterprise Architecture must have a clear boundary. An “enterprise” can be a single corporation, a government department, a supply chain, or a federation of semi-autonomous units. Defining this scope determines which stakeholders will benefit and who must be involved. A sponsor must be appointed early to secure resources and executive backing.
Beginner Example: Imagine a national retail chain with physical stores, an e-commerce division, and a separate logistics company that handles deliveries. If the EA initiative is scoped to “improve customer experience across all channels,” the enterprise boundary includes retail IT, e-commerce platforms, warehouse systems, and delivery partners. The CEO or COO would act as the sponsor to ensure all three units cooperate.
Concept: Architects must understand the environment in which they will operate. This includes commercial models, budget constraints, organizational culture, existing change processes, the current architecture landscape, and internal skill levels. This context dictates how formal or agile the EA practice should be.
Beginner Example: A startup in the fintech sector operates in a fast-paced, risk-tolerant culture with limited budget but high demand for rapid iteration. In contrast, a legacy bank operates under strict regulatory oversight, has a large IT budget, and requires heavy documentation. The fintech EA practice will be lightweight and tool-automated, while the bank’s will be highly structured, compliance-driven, and heavily governed.
Concept: Business imperatives drive EA requirements. Stakeholders must articulate what success looks like in terms of business needs, cultural aspirations, strategic intent, and forecasted financial requirements. This helps identify key decision-makers and sets measurable expectations.
Beginner Example: A healthcare provider wants to implement a unified patient records system. The requirements might include: “Reduce patient wait times by 20% within 18 months,” “Ensure 100% compliance with data privacy regulations,” and “Train 500 staff members on the new workflow without disrupting daily operations.” These become the non-negotiable success metrics for the architecture team.
Concept: Architecture Principles are enduring, high-level rules and guidelines that inform how the organization fulfills its mission. They are seldom changed and serve as a decision-making framework throughout all ADM phases. Principles typically include a name, statement, rationale, and implications.
Beginner Example:
Principle Name: Data is a Strategic Asset
Statement: All enterprise data shall be managed centrally, with standardized formats and strict access controls.
Rationale: Centralized data eliminates silos, improves reporting accuracy, and ensures regulatory compliance.
Implications: Departments must migrate legacy spreadsheets to the central data warehouse. IT will enforce role-based access. Initial migration will require budget and training, but long-term maintenance costs will drop by 30%.
Concept: TOGAF is intentionally generic and flexible. Organizations must decide how to tailor it to their industry, geography, and internal needs. This includes customizing terminology, selecting modeling notations, choosing architecture tools, and deciding which TOGAF deliverables are mandatory versus optional.
Beginner Example: A manufacturing company adopts TOGAF but decides to skip highly detailed data modeling templates because their IT landscape is relatively simple. Instead, they heavily customize the framework to emphasize supply chain and IoT architecture deliverables, using a specific enterprise architecture tool that integrates with their existing ERP system.
Concept: EA does not operate in a vacuum. It must align and integrate with other corporate frameworks such as Business Capability Management, Portfolio/Project Management, Operations Management, and Solution Development Methods. Overlaps are common, and architects must map dependencies to avoid conflicts and duplication.
Beginner Example: An organization uses PRINCE2 for project management, ITIL for service operations, and Agile for software development. The EA team maps TOGAF phases to these frameworks: TOGAF Phase E (Opportunities & Solutions) feeds into PRINCE2 project initiation, TOGAF Phase G (Implementation Governance) aligns with ITIL change management, and Agile sprint planning is coordinated with TOGAF’s iterative architecture refinement cycles.
Concept: Capability Maturity Models (CMMs) help assess the organization’s current ability to execute architecture practices. By evaluating factors like governance, tool usage, stakeholder engagement, and principle adherence, executives can identify gaps and set a realistic roadmap for improvement.
Beginner Example: A maturity assessment reveals the organization is at Level 2 (Repeatable but informal). Architects document processes inconsistently, and governance is reactive. The target is Level 4 (Managed and Quantitatively Controlled) within three years. The improvement roadmap includes: implementing a centralized architecture repository, establishing a formal Architecture Board, and mandating compliance reviews before project funding approval.
Upon completion of the Preliminary Phase, the organization should have produced or formalized the following artifacts:
Organizational Model for Enterprise Architecture: Defines roles, responsibilities, and boundaries for architecture practitioners.
Architecture Principles Document: Approved set of enduring rules guiding all architecture decisions.
Tailored Architecture Framework: A customized version of TOGAF aligned with organizational culture, tools, and deliverable requirements.
Governance Structure & Processes: Charter for the Architecture Board, compliance review procedures, and repository management guidelines.
Tooling & Repository Setup: Selected architecture tools configured to support version control, model storage, and stakeholder collaboration.
Maturity Assessment & Roadmap: Baseline evaluation with targeted improvement steps.
Secure Executive Sponsorship Early: Without high-level backing, architecture initiatives often stall due to lack of budget, authority, or cross-departmental cooperation.
Start Small, Scale Gradually: Do not attempt to govern the entire enterprise on day one. Define a manageable scope, prove value through a pilot architecture cycle, and expand based on lessons learned.
Keep Principles Actionable: Vague principles lead to inconsistent interpretation. Ensure each principle has clear implications that answer: “How does this affect my daily work?”
Integrate, Don’t Compete: Position EA as an enabler, not a bottleneck. Map TOGAF phases to existing project and operational frameworks to show how architecture accelerates delivery rather than slows it down.
Document the “Why”: Maintain a clear record of why specific framework customizations, tools, or governance rules were chosen. This becomes invaluable during audits, onboarding, and maturity assessments.
The Preliminary Phase is the critical setup stage that determines whether Enterprise Architecture will succeed or fail within an organization. By clearly defining the enterprise scope, understanding organizational context, establishing firm principles, aligning with existing management frameworks, and honestly assessing maturity, architects create a sustainable foundation for all subsequent ADM phases. For beginners, mastering this phase means learning to balance structure with flexibility, ensuring that architecture becomes a strategic business capability rather than an isolated technical exercise.
