TOGAF Preliminary Phase: Setting Up Your Architecture Capability

Before any architecture development work begins, there is essential preparation to do. The TOGAF Preliminary Phase is that preparation. It is where an organization sets up everything needed to run a successful, repeatable architecture practice.

Most TOGAF guides rush past the Preliminary Phase and dive straight into Phase A. That is a mistake. Organizations that skip or underinvest in the Preliminary Phase struggle to maintain consistent architecture standards across projects. They end up with architecture boards that have no authority, principles that nobody follows, and governance processes that exist only on paper.

This post covers everything you need to know about the Preliminary Phase: what it does, what it produces, and why getting it right makes every subsequent ADM cycle more effective.

---

Where the Preliminary Phase Sits

The ADM is often depicted as a wheel with phases arranged in a circle. The Preliminary Phase sits outside that wheel, placed before the cycle begins. This positioning is intentional.

The Preliminary Phase is not part of any single architecture project. It is the foundation that enables all projects. You only go through it once — or revisit it when a significant organizational change requires restructuring the architecture practice itself.

Once the Preliminary Phase is complete, the organization is ready to begin Phase A of the ADM for its first architecture development project.

---

The Objectives of the Preliminary Phase

TOGAF defines clear objectives for this phase. The organization needs to accomplish six things before the ADM cycle can begin properly.

1. Determine the architecture capability that the organization wants to establish
2. Establish the architecture governance framework
3. Define and agree on the architecture principles
4. Select and implement architecture tools and techniques
5. Define the organizational context for the architecture work
6. Customize TOGAF to fit the organization's specific needs

Each of these deserves attention because skipping any one of them creates problems that compound through every subsequent project.

---

Defining Your Architecture Capability

The first and most fundamental question the Preliminary Phase addresses is: what architecture capability does this organization want to build?

Architecture capability refers to the people, processes, tools, and governance structures that enable an organization to develop and maintain enterprise architectures. It is not enough to have a few architects. A real architecture capability involves:

• People: Defined architecture roles with clear responsibilities and required skill sets
• Processes: Agreed ways of working, from how projects request architecture support to how deliverables are reviewed and approved
• Tools: Modeling tools, repositories, and collaboration platforms that the architecture team uses consistently
• Governance: The structure of boards, committees, and review processes that make architecture decisions binding

Different organizations need different levels of architecture capability, depending on their size, complexity, and strategic ambitions. A small organization might have one or two architects operating informally with a lightweight governance model. A global financial institution might have a layered governance structure with corporate, divisional, and project-level architecture boards.

The Preliminary Phase forces this decision to be made explicitly rather than letting capability evolve accidentally.

---

Establishing the Governance Framework

One of the most important outputs of the Preliminary Phase is a functioning architecture governance framework. This defines how architecture decisions will be made, enforced, and reviewed.

The governance framework produced in the Preliminary Phase typically covers:

• Architecture board structure: Who sits on the architecture board, how often it meets, and what decisions it has authority to make
• Architecture review process: At what points in a project are architecture compliance reviews required, and what the review process looks like
• Exception handling: How teams request waivers or exceptions from agreed architecture standards, and how those requests are evaluated
• Escalation paths: What happens when there is a dispute or when an architecture decision has wider organizational impact
• Reporting and monitoring: How the architecture board tracks compliance across active projects

Without this governance framework in place, architects produce documents but cannot enforce them. We covered how architecture governance works in detail in our post on Architecture Principles and Governance Basics.

---

Defining Architecture Principles

The Preliminary Phase is where the organization's architecture principles are defined and formally agreed upon. These principles will guide every architecture decision made in subsequent ADM cycles.

As we covered in Architecture Principles and Governance Basics, a well-formed principle has four parts: a name, a statement, a rationale, and explicit implications.

During the Preliminary Phase, the architecture team:

• Drafts a set of candidate principles based on the organization's business strategy and existing policies
• Circulates the principles to key business and technology stakeholders for review
• Resolves conflicts between principles (for example, when "maximize reuse" conflicts with "adopt best-of-breed technology")
• Obtains formal sign-off from the appropriate governance body
• Stores the approved principles in the Architecture Repository

This sign-off step is critical. Principles that are drafted by architects but never formally approved by business leadership carry no organizational weight. When a project team pushes back on an architecture decision, the architect needs to be able to point to a document signed by a C-level executive.

---

Selecting and Tailoring TOGAF

TOGAF explicitly acknowledges that it is meant to be adapted, not applied rigidly. One of the outputs of the Preliminary Phase is a decision about how TOGAF will be used in this specific organization.

This tailoring covers several dimensions:

• Scope: Which parts of TOGAF will be used? Some organizations use only the ADM and skip the Content Framework entirely. Others use all six parts.
• Terminology: Organizations often have their own terms for concepts that TOGAF calls something different. Mapping TOGAF terminology to organizational terminology prevents confusion.
• Integration: How will TOGAF integrate with other frameworks already in use, such as ITIL for service management, COBIT for IT governance, or SAFe for agile delivery?
• Tooling: Which architecture modeling tools will be used? Options range from specialized tools like Sparx Systems Enterprise Architect or BizzDesign to general-purpose tools like Microsoft Visio or even structured document templates.

---

The Key Inputs to the Preliminary Phase

The Preliminary Phase does not start from nothing. It draws on several important inputs.

• The TOGAF standard itself: The framework documentation is the primary reference
• Organizational strategy and business drivers: The architecture capability must serve these
• Current organizational context: Existing governance structures, IT operating models, and relevant policies
• Existing architecture documentation: If prior architecture work exists, it must be understood before deciding how to proceed
• Stakeholder concerns and requirements: Input from key business and IT leaders on what they need from the architecture practice

---

The Key Outputs of the Preliminary Phase

When the Preliminary Phase is complete, the organization has a set of formal documents and decisions ready to support all subsequent ADM work.

• Tailored Architecture Framework: The customized version of TOGAF the organization will follow
• Architecture Principles: Formally approved and documented in the Architecture Repository
• Architecture Governance Framework: Defined boards, processes, and decision rights
• Initial Architecture Repository structure: Set up and ready to receive architecture outputs
• Organizational model for EA: Clear roles, responsibilities, and reporting lines for the architecture team

---

A Real-World Example: A Government Department

Consider a national government department establishing an enterprise architecture practice for the first time. During the Preliminary Phase, they would:

1. Assess their current architecture maturity and find they are at Level 1 (initial capability, mostly informal)
2. Define a target of reaching Level 3 (defined capability) within two years
3. Establish an Architecture Review Board co-chaired by the CIO and a senior business director
4. Draft and approve ten foundational architecture principles aligned to their digital government strategy
5. Decide to use TOGAF Phases A through D for their initial projects, deferring E-H until delivery processes mature
6. Select a modeling tool and set up a shared Architecture Repository using their existing document management platform
7. Define integration points with their existing ITIL-based change management process

This work takes time, usually several weeks for a mid-sized organization. But once it is done, every subsequent architecture project has a ready-made governance structure, a set of agreed principles, and standardized tools to work within.

---

Summary

The Preliminary Phase is the foundation of every successful TOGAF implementation. It establishes:

• The architecture capability the organization wants to build
• The governance framework that gives architecture decisions authority
• The principles that guide every future architecture choice
• The tailored version of TOGAF that fits the organization's context

Investing properly in the Preliminary Phase is what separates organizations that use TOGAF effectively from those that produce architecture documents that no one reads.

In the next post, we move into the first proper phase of the ADM: Phase A — Architecture Vision, where architects define the scope and vision for a specific architecture development project before deep design work begins.

This post is part of the TOGAF 9.2 Masterclass series on Topictrick. If you are working through from the beginning, the recommended reading order is listed in the first post.