Preliminary Phase

Prepare the organization: define 'where, what, why, who, and how we do architecture'.

About this phase

The Preliminary Phase prepares an organization to undertake successful Enterprise Architecture work. It happens before the ADM cycle proper begins, and answers the questions: where, what, why, who, and how do we do architecture in this enterprise?

The main aims are to define the enterprise, identify key drivers and elements in the organizational context, define the requirements for architecture work, establish Architecture Principles, define the framework to be used (including tailoring TOGAF), and evaluate the Enterprise Architecture maturity of the organization.

A key concept here is the establishment of the Architecture Capability — the people, processes, roles, and responsibilities that will carry out architecture work — together with the Architecture Governance framework that will oversee it.

Objectives

Determine the Architecture Capability desired by the organization: review the organizational context, identify the elements of the enterprise organizations affected, and identify the established frameworks, methods, and processes that intersect with the Architecture Capability.
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, and select and implement tools that support the capability.
Define the Architecture Principles.

Steps in this phase

0/6 · 0%

1.Scope the enterprise organizations impactedIdentify the core enterprise units most affected, soft enterprise units that will see change, extended enterprise units outside the scoped enterprise, communities involved, and governance frameworks involved.
2.Confirm governance and support frameworksUnderstand how architectural material will be brought under existing governance, and whether the existing governance and support frameworks need to change.
3.Define and establish the EA team and organizationDetermine existing enterprise and business capability maturity, identify gaps, allocate key roles and responsibilities for the Architecture Capability, and build the business case where appropriate.
4.Identify and establish Architecture PrinciplesDefine the set of Architecture Principles — general rules and guidelines that inform and support the way the organization fulfils its mission — and secure their endorsement.
5.Tailor the TOGAF framework and, if any, other selected architecture frameworksTailor terminology, process, and architecture content: adapt the ADM and deliverables to the enterprise, and integrate with other frameworks and methods in use (e.g., project, operations, and portfolio management).
6.Develop a strategy and implementation plan for tools and techniquesSelect and implement the tools, repositories, and techniques that will support the Architecture Capability, matched to the maturity and ambition of the practice.

Key inputs

The TOGAF Library and other architecture frameworks
Board strategies, business plans, business strategy, IT strategy, business principles, business goals, and business drivers
Major frameworks operating in the business (e.g., portfolio and project management)
Governance and legal frameworks, including the existing Architecture Governance framework
Any existing organizational model for Enterprise Architecture
Any existing architecture framework, principles, and repository
Partnership and contract agreements

Key outputs

Organizational Model for Enterprise Architecture — scope of impacted organizations, maturity assessment, roles and responsibilities, budget requirements, governance and support strategy
Tailored Architecture Framework — tailored ADM, tailored architecture content, Architecture Principles, configured tools
Initial Architecture Repository — populated with framework content
Restatement of, or reference to, business principles, goals, and drivers
Request for Architecture Work (optional output that triggers Phase A)
Architecture Governance framework

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

example inputDeliverableAn excerpt of the corporate strategy that motivates establishing an Enterprise Architecture capability.

Meridian Retail Group — Strategic Plan Extract (FY26–FY28)

Issued by: Meridian Retail Group Board of Directors Classification: Internal Board Directive: 26-04 (adopted at the January 2026 Board meeting)

1. Strategic Direction

Meridian Retail Group operates 240 stores and an online channel across three countries. Over the last three years, digital revenue has grown from 8% to 26% of total sales, but our systems landscape has not kept pace.

The Board has approved the "One Meridian" strategy with three pillars:

Unified Customer Experience — customers should be recognized and served consistently across stores, web, and mobile.
Operational Efficiency — reduce cost-to-serve by 15% through process standardization and shared services.
Data-Driven Decisions — establish a single trusted view of customers, products, and inventory.

2. Market context

Pressure	What we observe	Strategic response
Customer expectations	Competitors offer click-and-collect and cross-channel returns as standard	Unified Customer Experience pillar
Margin squeeze	Cost-to-serve per order up 11% in two years	Operational Efficiency pillar
Regulation	Growing GDPR enforcement on consent and profiling	Data-Driven Decisions, with governed data
Technology debt	In-store POS (v9) reaches end of life in 2027	Coordinated platform renewal

3. Strategic targets (FY28)

Repeat-purchase rate raised from 31% to 40%
Cost-to-serve reduced by 15% against the FY25 baseline
One trusted customer record per customer, shared by every channel
Digital share of revenue sustained above 30% without new channel-specific silos

4. Board Directive 26-04

The Board notes that previous transformation initiatives have failed to coordinate change across business units, resulting in duplicated systems (4 customer databases, 3 order management systems) and inconsistent processes.

The CIO is directed to establish an Enterprise Architecture capability to:

Provide a coordinated roadmap for the One Meridian strategy
Govern technology investment decisions across all business units
Report quarterly to the newly formed Architecture Board

The capability must be operational, with principles and governance in place, before the first One Meridian investment tranche is requested from the Investment Committee (target: Q2 FY26).

Budget authorized: $1.2M for capability establishment in FY26. Sponsor: Chief Information Officer, supported by the Chief Operating Officer.

5. Business principles endorsed by the Board

Customer first: decisions are tested against their effect on the customer journey.
One Meridian, not many: shared capabilities are preferred to business-unit-specific ones.
Spend once: investment that duplicates an existing group capability needs explicit justification.

Study notes

Used in: Step 1: Scope the enterprise organizations impacted · Step 3: Define and establish the EA team and organization · Step 4: Identify and establish Architecture Principles

Board strategies, business goals, and drivers are named inputs to the Preliminary Phase. They explain why the enterprise wants an architecture capability at all.
Directive 26-04 sets the sponsor, budget, and reporting line. Those are the raw material for the Organizational Model for Enterprise Architecture and its business case (step 3).
The board-level business principles in section 5 are business principles, not Architecture Principles. The architecture team derives its own principles from them in step 4, so the two sets should trace to each other.
The market-context table is where the business drivers come from. They are restated in the Driver/Goal/Objective catalog and confirmed again in Phase A step 3.

Example outputs

example outputCatalogA sample set of Architecture Principles in the standard four-part TOGAF template: Name, Statement, Rationale, Implications.

Meridian Retail Group — Architecture Principles v1.0

Approved by: Architecture Board, 14 March 2026 Owner: Lead Architect · Review cycle: annually, or when Phase H raises a change

Principles catalog (summary)

#	Name	Domain	Derived from (business principle / driver)
1	Business Continuity	Business	Customer first
2	Data is an Asset, Shared, and Accessible	Data	One Meridian, not many
3	Buy Before Build	Application	Spend once
4	Interoperability	Technology	Spend once, integration cost driver
5	Compliance with Law and Regulation	Business	Regulatory pressure (GDPR, PCI-DSS)

Principle 1: Business Continuity

Statement: Enterprise operations are maintained in spite of system interruptions.

Rationale: Store trading and online checkout are revenue-critical. As systems become more integrated under One Meridian, dependence on shared services increases and interruptions have wider impact.

Implications:

Shared services must be designed for resilience and graceful degradation
Recoverability and redundancy requirements must be defined at design time
Applications must be assessed for criticality and assigned availability tiers

Principle 2: Data is an Asset, Shared, and Accessible

Statement: Data is a corporate asset with defined ownership; it is shared across functions and accessible to authorized users through common services.

Rationale: The single largest obstacle to the One Meridian strategy is fragmented customer, product, and inventory data held in silos.

Implications:

Each key data entity is assigned a business data owner (trustee)
Applications consume master data from designated authoritative sources
Data sharing must comply with Data Governance Council privacy policies

Principle 3: Buy Before Build

Statement: Packaged and SaaS solutions are preferred over custom development unless a capability is a source of competitive differentiation.

Rationale: Meridian's differentiation is retail experience, not software engineering. Custom systems have driven maintenance cost and key-person risk.

Implications:

Requirements should be adapted to standard product capability where possible
A build decision requires an approved exception with business justification
Vendor and integration standards must be defined and maintained

Principle 4: Interoperability

Statement: Software and hardware conform to defined standards that promote interoperability of data, applications, and technology.

Rationale: Integration cost across the current fragmented landscape is the largest single component of IT change spend.

Implications:

An integration standard (APIs, events) is defined and governed
Deviations are managed through a documented exceptions process
Standards are reviewed periodically by the Architecture Board

Principle 5: Compliance with Law and Regulation

Statement: Architecture decisions comply with applicable law, regulation, and contractual obligations in every country where Meridian trades.

Rationale: Unifying customer data across channels increases GDPR exposure, and payment flows fall under PCI-DSS. A breach would undo the trust that One Meridian depends on.

Implications:

Consent and lawful basis are designed into customer data flows, not added later
PCI-DSS scope is kept as small as possible and documented for each solution
The CISO and Data Protection Officer review designs that process personal data

Using these principles

Every deliverable submitted to the Architecture Board states which principles it supports and any it departs from.
A departure is handled as a time-bound dispensation (see the Architecture Governance Framework). A departure that should be permanent is raised as a Change Request against the principle itself.
When principles conflict (for example Buy Before Build against Interoperability for a closed SaaS product), the Board records how it weighed them in the Governance Repository.

Study notes

Produced in: Step 4: Identify and establish Architecture Principles

Each principle has the four parts TOGAF recommends: Name, Statement, Rationale, and Implications. Exam questions often ask which part says what the principle means for the organization in practice. That part is Implications.
The summary table is a Principles catalog, which is an artifact. The approved set of principles is also part of the Tailored Architecture Framework output.
The 'Derived from' column shows that Architecture Principles come from business principles and drivers. They are created in the Preliminary Phase, and Phase A only confirms and elaborates them for the cycle.
Principles are used later in the cycle. Principle 4 becomes a conformance requirement in the Phase G Architecture Contract, and a departure from Principle 2 led to dispensation D-2027-04.
Good principles are few, understandable, robust, complete, consistent, and stable. A set of 5 is easier to apply than a set of 30.

Study tips & key concepts

Remember the five questions the Preliminary Phase answers: where, what, why, who, and how — 'when' is decided by the Request for Architecture Work that starts a cycle.
Architecture Principles are created here (not in Phase A). Phase A only confirms and elaborates them. A good principle has a Name, Statement, Rationale, and Implications.
The Preliminary Phase can be revisited: Phase H or a Request for Architecture Work may require the framework or principles to be adjusted before a new cycle.
The Request for Architecture Work is produced by the sponsoring organization here (or in Phase H for change-driven cycles) and is the trigger input to Phase A.
Tailoring happens at two levels: terminology tailoring (so the enterprise understands the framework) and process/content tailoring (so the framework fits the enterprise).