TL;DR
The Preliminary Phase is where we set up the enterprise architecture capability before running the ADM cycle. We define the operating model, governance, principles, tools, and maturity target so architecture work can be executed consistently and at the right scale.
Where Preliminary sits in ADM
The Preliminary Phase is before Phase A.
We’re not designing target architecture yet — just building the conditions needed to do architecture work well.
If you want the step-by-step breakdown, see Steps. For the formal handoff into Phase A, see Request for Architecture Work.
Main purpose
Practically, this phase does three things:
- establish architecture capability
- tailor how TOGAF will be applied in this enterprise
- define architecture principles used as guardrails
Two objectives (practical breakdown)
flowchart TD A1["Review org context"] --> A2["Identify impacted elements"] A2 --> A3["Identify intersecting frameworks"] A3 --> A4["Set maturity target"] A4 ==> B1["Define EA org model"] B1 --> B2["Define governance model"] B2 --> B3["Define processes and controls"] B3 --> B4["Select tools and repositories"] B4 --> B5["Adopt architecture principles"]
1) Determine the desired architecture capability
Decide what maturity level and operating model we need, based on context.
Typical activities:
- review organizational context (goals, structure, constraints, current practices)
- identify which enterprise elements are affected by architecture capability
- identify intersecting frameworks and methods already in use
- set a realistic capability maturity target
2) Establish the architecture capability
Now implement what was decided.
Typical activities:
- define EA organization model (roles, responsibilities, teams)
- define architecture governance model (boards, approvals, decision rights)
- define core architecture processes and controls
- select and implement supporting tools and repositories
- define and adopt architecture principles
What usually gets set up here
| Area | What we define in Preliminary |
|---|---|
| Organization | EA roles, skills, team structure, accountability |
| Governance | architecture board patterns, approval flow, escalation paths |
| Methods | tailored ADM usage, integration with existing delivery/process frameworks |
| Principles | enterprise-wide architecture rules and decision guardrails |
| Tools | repository approach, modeling/documentation tooling, traceability support |
| Maturity | target capability level and staged improvement plan |
Tailor TOGAF to your environment
TOGAF was never meant to be applied as a rigid script.
In this phase, we decide:
- what parts of TOGAF are needed now
- what must align with existing enterprise methods
- what governance level is proportionate to current change demand
Maturity target: start practical, then evolve
Do not overbuild capability before there is architecture demand.
A better approach:
- build enough capability for current architecture work
- run ADM cycles and learn
- enhance capability where bottlenecks appear
Keeps EA useful and avoids the classic “process-heavy, value-light” trap.
Practical checklist
Before moving to Phase A, confirm:
- EA scope and mandate are clear
- governance bodies and decision rights are defined
- architecture principles are approved
- minimal toolchain/repository is in place
- maturity target is explicit
- interfaces with other frameworks/processes are agreed
Common mistakes
- trying to industrialize EA before real demand exists
- defining roles without governance authority
- setting principles but not enforcing them through decision processes
- introducing tools before process and ownership are clear
Exam note
- Preliminary is preparatory and precedes Phase A.
- It focuses on architecture capability, governance, principles, and tailoring.
- It includes setting capability maturity target and establishing required structures/processes/tools.
- Build only the capability maturity you currently need; evolve incrementally.