TOGAF® Preliminary Phase and Phase A: A Practical Guide to SAP Integration in Post‑Merger Scenarios
Diagram illustrating TOGAF ADM phases guiding SAP M&A integration process.
1. Scenario and Target Readers
In this article, we assume the following post‑merger integration scenario:
Company A and Company B complete a merger and start as a new integrated company
Both companies already run parts of SAP
Example: Company A uses FI/CO and SD, Company B uses MM and PP
After the merger, the new company aims for
A single SAP instance, and/or
A global standard template–based integration landscape
An Enterprise Architect (EA) leads the integration initiative using TOGAF® ADM as the primary framework
Within TOGAF® ADM, the Preliminary Phase and Phase A: Architecture Vision are upstream phases that heavily influence the success or failure of the entire program. In a high‑risk and politically sensitive topic like post‑merger integration, thoughtful design of these two phases becomes especially critical.
2. Purpose of the Preliminary Phase
In the TOGAF® standard, the Preliminary Phase is defined as the phase that “prepares the organization for a successful architecture project and establishes the appropriate framework and principles.” In the context of a merger between Company A and Company B, you can reinterpret this as follows:
Define the rules and organizational structures that will govern the post‑integration Enterprise Architecture (EA)
Establish EA governance that supports the entire transformation program, including SAP integration
Fix the principles and decision frameworks before creating the Architecture Vision
In other words, the Preliminary Phase is the stage where you reach agreement on “under what rules, structures, and principles we will design and realize the target state of the integrated company.”
3. Key Tasks for EAs in the Preliminary Phase
3.1 Defining the Scope and Objectives of the Integrated EA
The first step is to clearly define the scope and objectives of the integrated EA.
Business domains
Examples: global sales, procurement, manufacturing, finance, HR
System scope
SAP (e.g., S/4HANA) plus surrounding systems (MES, WMS, PLM, local finance, etc.)
Infrastructure and data platforms
Typical integration objectives include:
Business standardization and rapid rollout enabled by SAP integration
Global visibility of financial and sales performance
IT cost reduction and infrastructure consolidation
These points become the key assumptions that must be consistent with the later Architecture Vision.
3.2 Establishing Architecture Principles
TOGAF® explicitly states that architecture principles should be defined in the Preliminary Phase. In a merger‑driven SAP integration, examples of such principles include:
“Single Source of Truth” principle
SAP is the single source of truth for financial, inventory, and order data
“SAP Standard First” principle
Custom developments are limited to areas that truly differentiate the business
“Global Template & Local Extension” principle
Global standard template plus minimal local extensions as the default structure
“Integration by Design” principle
Interfaces are API‑first and follow standardized integration patterns
The EA proposes and iterates these principles with business and IT stakeholders, and secures formal approval. These principles will later serve as the decision criteria for design choices throughout the program.
3.3 Designing EA Governance and Organizational Structure
TOGAF® recommends that the roles of the architecture function and the governance structure be defined in the Preliminary Phase. In the context of corporate and SAP integration, the following design points are particularly important:
Establishment of an Enterprise Architecture Board (EA Board)
Members might include the CIO, business executives, IT heads, and representatives from each legacy company
Clarification of responsibilities with the SAP Center of Excellence (SAP CoE)
Ownership of the global template design
Ownership of rollout, change management, and adoption
Allocation of domain architects
Business, application, data, and technology domains
Design of the Architecture Review process
Review workflow for SAP add‑ons, new interfaces, and new surrounding systems
The EA documents this as a governance model and rolls it out across the overall integration program.
3.4 Selecting Architecture Frameworks and Reference Models
Another key activity in the Preliminary Phase is deciding which architecture frameworks and reference models to adopt.
Frameworks
Use TOGAF® ADM as the base, while aligning it with SAP standard methodologies such as SAP Activate
Reference architectures
SAP reference architectures and industry best practices (e.g., for automotive suppliers)
Existing templates and past global rollout cases within the corporate group
Here, the EA decides “which models we will use as the foundation” when describing the target architecture after integration.
3.5 Preparing Tools and Repositories
The Preliminary Phase also includes preparation of architecture repositories and toolsets.
Selection of EA tools (e.g., ArchiMate‑compatible tools and diagram management tools)
Rules for storing SAP solution documentation
Business process diagrams, configuration documents, test assets, etc.
Mechanisms for collecting and organizing existing system and process information from both companies
This preparation enables centralized management of all artifacts created in Phase A and beyond, and improves reuse and traceability across the program lifecycle.
4. Purpose of Phase A: Architecture Vision
TOGAF® defines the purpose of Phase A as “setting the scope, constraints, and expectations for the project, creating the Architecture Vision, and gaining stakeholder approval.” For the SAP integration project in the Company A and Company B merger, the core themes of Phase A are:
Describe the post‑integration business and system landscape in a clear and tangible way
Clarify the role and scope of SAP within that landscape
Build solid agreement among key stakeholders, including top management
It is essential to position SAP not merely as a cost‑reduction tool, but as a platform that supports growth and transformation in the new integrated company.
5. Key Tasks for EAs in Phase A
5.1 Confirming Business Drivers and Integration Objectives
In Phase A, the EA clarifies business drivers and goals and uses them as the context for the Architecture Vision. Typical drivers in a merger scenario include:
Strengthening governance after management integration
Consolidated P&L and balance sheet, global inventory visibility
Generating synergies
Cost reduction through shared procurement and shared manufacturing sites
Speed in new business and global expansion
Faster rollout enabled by an integrated global template
The EA organizes these into business objectives and key KPIs, clearly linking them to the value of SAP integration.
5.2 Defining Scope and Constraints
Phase A must explicitly define the project scope and constraints, such as time, budget, and resources.
Scope examples
In‑scope companies and sites for integration (e.g., EU sites first, followed by North America)
System boundaries (where SAP ends and where surrounding systems start)
Constraint examples
Cutover deadlines (e.g., complete financial integration by the first consolidated closing)
Legal and regulatory constraints (e.g., local data residency and system retention rules)
The EA documents these in the Architecture Vision and in the Statement of Architecture Work, and obtains formal approval.
5.3 High‑Level As‑Is Understanding (Company A and B Business and SAP Landscape)
In Phase A, the goal is not detailed As‑Is analysis but a high‑level understanding of the overall picture.
SAP footprint of Company A
Modules in use, number of instances, level of customization
SAP footprint of Company B
Critical non‑SAP systems
MES, PLM, WMS, local finance systems, etc.
Major business differences
Material coding schemes, sales channels, plant operations, and so on
These elements form the “before picture” used when explaining the target Architecture Vision to stakeholders.
5.4 Defining the To‑Be Architecture Vision (Business and SAP)
The core deliverable of Phase A is the Architecture Vision. In a merger‑driven SAP integration, a typical SAP Vision will cover:
Overview of the integrated business operating model
Standard global processes such as Order‑to‑Cash, Procure‑to‑Pay, Plan‑to‑Produce
Basic policies for shared master data (customers, materials, organizational structures)
Target SAP landscape
Single global S/4HANA instance vs. regional instances
Template structure (core template plus local extensions)
Interface architecture with other systems (API, ESB, ETL, etc.)
Data and analytics strategy
Whether there is a central data lake and/or data warehouse
Standardized management dashboards and reporting
The EA summarizes these in simple, high‑level visuals such as process overviews and system landscape diagrams and presents them as “the digital foundation of the new integrated company.”
5.5 Stakeholder Analysis and Communication Planning
A critical task in Phase A is identifying stakeholders and planning how to engage them. In a merger context, the stakeholder landscape is particularly diverse:
New‑company executives (CEO, CFO, CIO, etc.)
Business and functional leaders from both legacy companies
Sales, manufacturing, procurement, finance, HR, and others
The EA analyzes each stakeholder’s interests and concerns and designs communication messages and channels accordingly.
Examples:
For executives: stories around synergy, governance, and return on investment
For site and operational leaders: stories around operational impact, training, and support
This structured engagement makes it much easier to secure broad agreement on the Architecture Vision.
5.6 Presenting the Initial Roadmap and Business Case
In Phase A, the EA does not provide a detailed migration plan but instead outlines:
A high‑level roadmap
A high‑level business case
Examples of a roadmap:
Phase 1: Financial integration
Group‑wide P&L/BS and a single chart of accounts
Phase 2: Standardization of sales and procurement processes
Phase 3: Integration of manufacturing processes and MES connectivity
Elements of the business case:
Benefits
Inventory reduction, shorter closing cycles, lower IT operating costs, etc.
Costs
SAP licenses, infrastructure, project staffing, and change management
Risks and mitigations
Operational resistance, cutover risk, data migration risk, and countermeasures
The EA consolidates these into the Architecture Vision and uses them to secure strong executive sponsorship.
6. How Outputs from the Preliminary Phase and Phase A Connect
From a TOGAF® perspective, the relationship between the Preliminary Phase and Phase A can be summarized as follows:
Preliminary Phase
Defines the rules, organizational structures, and principles of EA
Provides the governance foundation for the entire SAP integration program
Phase A
Under those rules and principles, creates and agrees the Architecture Vision (business and SAP) for the integrated company
In a large‑scale transformation such as corporate plus SAP integration, it is vital that the principles decided in the Preliminary Phase are clearly reflected in the Architecture Vision of Phase A. For example, if you have a “SAP Standard First” principle, the Architecture Vision should explicitly state that the target operating model is based on standard SAP processes with minimized custom development.
7. Practical Tips for EAs in SAP Integration Projects
To conclude, here are practical tips for Enterprise Architects leading SAP implementation or integration projects through the Preliminary Phase and Phase A:
Bridge the language gap between TOGAF® and SAP projects
Example: Architecture Vision ≈ “Target Operating Model + SAP Target Landscape”
Align with SAP Activate and other methodologies
Map deliverables from SAP Activate Discover/Prepare phases to TOGAF Preliminary/Phase A deliverables
Frame EA as the “blueprint of management,” not just an IT activity
Directly connect EA outcomes to executive‑level topics such as governance, synergy, and speed of transformation
Make data and master‑data integration challenges visible early
Include “how we will integrate data” in the story from the Vision phase onward
An EA is not merely a person who “draws diagrams,” but the designer and governor of the digital foundation of the new integrated company. Investing the right level of effort in the Preliminary Phase and Phase A to establish this position and framework will significantly increase the probability of success in all subsequent phases.
TOGAF® Standard – ADM Phase Overview Official overview of all ADM phases, including definitions and objectives for the Preliminary Phase and Phase A (Architecture Vision). http://www.togaf.com/admref/_welcome.html
TOGAF® Standard – Introduction High‑level introduction to TOGAF and the ADM, including the role of the architecture capability and how ADM phases fit into the overall framework. https://pubs.opengroup.org/togaf-standard/adm/chap02.html
TOGAF Preliminary Phase for SAP Implementation Practical article showing how to apply the TOGAF Preliminary Phase specifically in SAP implementation and transformation programs, including governance and principles. https://eaviaer.com/togaf-preliminary-phase-in-sap/
TOGAF® – The Definitive Guide (LeanIX) Clear overview of TOGAF, its value proposition, and its application in enterprise architecture programs, which you can cite when explaining why you chose TOGAF. https://www.leanix.net/en/wiki/ea/togaf
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.