2.1 Preliminary Phase Objectives, Inputs, and Activities

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:

1. 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.
2. 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

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.