Mastering the TOGAF 10 Preliminary Phase: Building the Foundation for Enterprise Architecture

Welcome to this comprehensive tutorial on the Preliminary Phase of the TOGAF 10 (The Open Group Architecture Framework) standard. Often overlooked by organizations rushing to build solutions, this phase is arguably the most critical for long-term success. It is not about designing a specific building; it is about laying the concrete foundation upon which all future architectural work will be constructed.

In this guide, we will break down the visual components of the Preliminary Phase, exploring how to tailor the framework, establish governance, and ensure your organization is ready for enterprise architecture (EA) work.

What is the Preliminary Phase?

The Preliminary Phase prepares the organization to perform architecture work. Think of this as the “Setup” or “Configuration” phase. Before you can start the actual Architecture Development Method (ADM) cycles, you must define the rules of the game.

This phase is particularly vital when an organization is creating an architecture practice for the first time. It answers the question: “How do we do architecture here?” rather than “What is the solution?”

The Core Pillars: A Step-by-Step Walkthrough

Based on the TOGAF 10 framework, there are six key activities that build the Architecture Practice Foundation. Let’s walk through them systematically.

1. Define the Scope of the Architecture Function

Not every project needs a full architectural review. In this step, you must define the boundaries. Are you focusing on IT infrastructure only, or are you including business processes and data?

Key Question: Which parts of the enterprise will this architecture function cover?

2. Establish Architecture Principles

Principles are the guiding rules and beliefs that inform the architecture. They act as a compass for decision-making.

Example: “All software must be cloud-native” or “Data is a shared asset, not a departmental silo.” These principles ensure consistency across all projects.

3. Identify Stakeholders

Architecture is a social activity as much as a technical one. You must identify who has an interest in the outcome. This includes business leaders, IT staff, compliance officers, and end-users. Understanding their concerns is the first step in creating a solution they will actually use.

4. Define Governance Structures

How will you enforce your principles? This involves setting up the governance model.

Typical Structure: Establishing a Central Architecture Board that approves target architectures. This ensures that no project deviates too far from the strategic plan without proper review.

5. Select Tools and Repositories

You cannot manage complex architecture with sticky notes. This step involves selecting the technology stack to support your practice.

Contextual Note: As mentioned in the supplementary resources, organizations often select specific tooling to manage this workflow. For example, utilizing the Visual Paradigm TOGAF ADM Tool allows teams to model processes, manage artifacts, and maintain a central repository for architecture decisions efficiently.

6. Assess Capability and Maturity

Before starting, you must know where you stand. Are you a beginner in architecture, or do you have a mature practice? Assessing your current maturity helps you set realistic goals and understand the resources needed to improve.

Tailoring and Connecting: The “Adapt” and “Connect” Boxes

The diagram highlights two critical conceptual boxes: Adapt TOGAF 10 and Connect to Existing Processes.

Adapt TOGAF 10

TOGAF is a framework, not a rigid prescription. You must tailor the content, process, roles, and artifacts to fit your organization’s specific context, culture, and goals. A rigid adherence to the standard without customization often leads to failure.

Connect to Existing Processes

Enterprise Architecture does not exist in a vacuum. It must align with and leverage existing enterprise processes. If your organization uses Agile for software development, your architecture reviews must fit into the Agile sprint cycle, not hinder it.

Typical Decisions and Outputs

During this phase, organizations make significant governance decisions that will shape their future operations. These typically include:

• Major Transformation Projects: Deciding that all major transformation projects require an architecture review before proceeding.
• Domain Architectures: Determining if business units can maintain their own domain architectures, provided they stay within enterprise standards.
• Security & Privacy: Mandating that security and privacy requirements must be addressed during the architecture development process.
• Central Repository: Ensuring that all architecture decisions are recorded in a central repository for transparency and auditability.

The Final Output

It is crucial to understand what this phase does not produce. The output is not a detailed solution architecture. Instead, the output is the foundation needed to perform architecture work consistently.

Once this foundation is laid, the organization is ready to move into the Architecture Development Method (ADM) phases to actually design solutions. Without the Preliminary Phase, you risk building beautiful solutions on a shaky foundation.