Flowchart showing steps to establish architecture capability for SAP projects in TOGAF preliminary phase

— A Practical Guide from an Enterprise Architecture Perspective

In large-scale ERP implementations centered on SAP S/4HANA, the success of the project is significantly influenced by whether a solid architectural foundation is established before requirements definition and design begin.

The Preliminary Phase in the Architecture Development Method (ADM) of The Open Group is precisely the phase designed to build that foundation.

This article explains how to design and apply the Preliminary Phase as an Enterprise Architecture (EA) activity tailored specifically for SAP implementation projects.


1. What is the TOGAF® Preliminary Phase?

1.1 Positioning and Purpose

The Preliminary Phase in the ADM is a preparation phase that defines and establishes the Architecture Capability required by an organization before entering the main phases (Phase A–H).

In summary, the Preliminary Phase serves to:

  • Define the preparation and initiation activities required to establish and operate architecture capability
  • Determine and establish the desired architecture capability for the organization
  • Define an organization-specific architecture framework, including principles, business drivers, and objectives

The key point is that this phase is not about designing the architecture itself, but about establishing the capabilities, governance, organization, processes, principles, and tools needed to design and operate architecture.


1.2 Key Activities

The main activities of the Preliminary Phase include:

  • Defining the scope of the enterprise (group, region, business units)
  • Reviewing governance and supporting frameworks (e.g., PMO, IT governance)
  • Establishing the EA team and organizational model
  • Defining and agreeing on architecture principles
  • Tailoring TOGAF and other frameworks to organizational needs
  • Defining strategy and implementation plans for architecture tools and techniques

These activities define how EA will engage with and support projects.


2. The Meaning of the Preliminary Phase in SAP Projects

In SAP S/4HANA implementations, if EA is positioned merely as a “review function,” the following issues often arise:

  • Uncontrolled increase in custom developments due to unclear Fit-to-Standard principles
  • Weak governance of global templates leading to fragmented local designs
  • Lack of forward-looking architecture considering post-go-live operations and scalability

The Preliminary Phase should therefore be seen as the phase to design the EA foundation supporting SAP projects, preventing these issues proactively.


2.1 Redefined Objectives for SAP Projects

From an EA perspective, the Preliminary Phase in SAP projects has four key objectives:

  1. Establish EA capability to support SAP implementation
  2. Define governance and integration between SAP projects and EA
  3. Establish SAP-specific architecture principles
  4. Tailor EA frameworks, processes, and tools for SAP environments

3. Objective 1: Establish EA Capability for SAP

3.1 Define Required EA Capabilities

Define the capabilities needed to continuously design and manage enterprise architecture across SAP S/4HANA and surrounding cloud solutions:

  • Capability to design global template and instance strategies
  • Capability to align business models and supply chain strategies with SAP solutions
  • Capability to manage rollout plans and EA roadmaps

3.2 Define EA Organization and Roles

Typical roles include:

  • Enterprise Architect (overall optimization, instance strategy, roadmap)
  • Domain Architect (logistics, finance, manufacturing, procurement)
  • Solution Architect (SAP S/4HANA and SAP products)
  • Integration Architect (interfaces, APIs, event-driven integration)
  • Data Architect (master, transactional, analytical data models)

Clear alignment with project teams (PMO, business teams) is critical.


4. Objective 2: Connect SAP Projects with EA Governance

4.1 Define Touchpoints

Align EA processes with:

  • Project portfolio management
  • SAP project lifecycle (e.g., SAP Activate)
  • Change management and operational transition

This ensures EA is embedded in decision-making, not just post-fact reviews.


4.2 Establish SAP EA Governance Charter

Key elements include:

  • Architecture review processes (Design Authority, Architecture Board)
  • Approval flows for major decisions (template changes, add-ons, instance strategy)
  • Integration with PMO and release management

5. Objective 3: Define SAP Architecture Principles

5.1 Example Principles

  • Fit-to-Standard: Prioritize SAP standard functionality
  • Single Source of Truth: Define authoritative systems for data
  • Global Template First: Control local deviations
  • Cloud/Hybrid Strategy: Define deployment model strategy

5.2 Structure of Principles

Each principle should include:

  • Name
  • Statement
  • Rationale
  • Implications
  • Examples

These principles guide all subsequent architecture decisions.


6. Objective 4: Tailor EA Frameworks, Processes, and Tools

6.1 Map ADM to SAP Activate

  • Preliminary: Capability & governance setup
  • Phase A: Vision (Discover/Prepare)
  • Phase B–D: Architecture design (Explore/Realize)
  • Phase E–F: Migration planning
  • Phase G–H: Deployment & operation

6.2 Tool Integration Strategy

Typical tools include:

  • EA tools (LeanIX, ARIS, etc.)
  • SAP Solution Manager / SAP Cloud ALM
  • SAP Signavio

Define the single source of truth per data type across tools.


7. Outputs and Outcomes

7.1 Key Outputs

  • EA organization and roles
  • SAP EA governance charter
  • Architecture principles catalog
  • ADM–SAP lifecycle mapping
  • EA tool strategy

7.2 Expected Outcomes

  • Established EA capability
  • Clear integration between SAP lifecycle and EA governance
  • Agreed architecture principles
  • Unified framework combining TOGAF and SAP methodologies

8. Required Skills for EA Teams

8.1 EA Framework Knowledge

8.2 Governance & Organization Design

8.3 Process Tailoring

8.4 SAP Architecture Knowledge

8.5 Facilitation & Consensus Building


Conclusion

The Preliminary Phase is often underestimated, but in SAP projects, it determines:

  • Design flexibility
  • Ease of future change

Entering a project with clearly defined EA capability, governance, and principles creates a significant advantage—especially in long-term operations.

In the next article, we will explore practical examples of SAP architecture principles and ADM–SAP Activate mappings.

Please refer to this article for topics related to Enterprise Architecture (EA).
Enterprise Architecture – Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy


Reference Links

– Preliminary Phase – TOGAF 9.1 (Objectives / Steps / Inputs / Outputs)  
https://coe.qualiware.com/resources/togaf/9-1/part2-adm/preliminary-phase/

– Preliminary Phase: Framework and Principles – TOGAF.com
  http://www.togaf.com/admref/_chap05.html

– TOGAF® Standard — ADM Introduction – The Open Group
https://pubs.opengroup.org/togaf-standard/adm/chap02.html

– The TOGAF Architecture Development Method – Pocket Guide
https://pubs.opengroup.org/pocket-guides/togaf-pocket-guide/main/chap06.html

– Comprehensive Guide to the Preliminary Phase of TOGAF ADM – Visual Paradigm https://togaf.visual-paradigm.com/2025/01/20/comprehensive-guide-to-the-preliminary-phase-of-togaf-adm/

– Detailed Step-by-Step Tutorial for the Preliminary Phase of TOGAF ADM – Visual Paradigm https://togaf.visual-paradigm.com/2025/01/20/detailed-step-by-step-tutorial-for-the-preliminary-phase-of-togaf-adm/


Disclaimer

Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.


Back to Top

Leave a Reply

Discover more from Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

Subscribe now to keep reading and get access to the full archive.

Continue reading