Enterprise Architecture with SAP — Part 2: Patterns in Practice

Part 1 established the structural skeleton of Enterprise Architecture in SAP transformations: the four-domain cycle, the five-step transformation method, the platform meta-model, the time dimension, the report classes, and the governance layer. Part 2 activates that skeleton.

It does so in two movements. The first wires the architecture repository to reality: the three-layer transformation toolchain (architecture, process, and operations), the bidirectional link between the process and architecture layers, autodiscovery of the live landscape, and the persona map that determines who consumes which view. The second applies the five-step method to the four recurring decision types in SAP programs — rollout strategy, two-tier architecture, split architecture, and total cost of ownership — and closes with the integration and extensibility architecture that turns the repository from a passive record into an active governance system.

The thesis of this part is that patterns and plumbing are inseparable. A pattern applied against a stale repository produces a confident answer to the wrong question. A perfectly current repository with no pattern discipline produces data without decisions.

No single tool handles the full transformation lifecycle. The architecture repository knows what the landscape is and where it is going; it does not know how the business actually executes its processes, and it does not know what is deployed in production this morning. Those facts live in two other systems — a business process management platform and an application lifecycle management and operations platform — and an EA practice that treats the repository as an island will find it diverging from both within a quarter.

Part 2 therefore begins with integration before it reaches patterns. The four patterns are the primary mechanism by which EA influences real transformation decisions, but every one of them consumes landscape data as input. The quality of that input is set by the toolchain integration described first.

Three platform layers cover the transformation lifecycle, each owning a distinct domain. Vendors package and name them differently; the layering is what matters.

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32

    EAM["EA Management Platform<br>Architecture Layer"]
    BPM["Business Process Mgmt Platform<br>Process Layer"]
    ALM["Application Lifecycle Mgmt Platform<br>Execution & Operations Layer"]

    EAM -->|"bidirectional: capabilities,<br>apps, processes"| BPM
    BPM -->|"process insights<br>feed operations"| ALM
    ALM -->|"autodiscovery of<br>landscape back to"| EAM

    class EAM application
    class BPM business
    class ALM technology

The architecture layer, the process layer, and the execution layer answer different questions for different people. Conflating them produces gaps and overlaps that undermine transformation governance: process models that no application realizes, applications in the repository that operations retired a year ago, projects in delivery that no roadmap anticipated.

The integration between the process platform and the architecture platform must be bidirectional, not a one-way feed. Bidirectionality is what enables a closed loop between how the business works and what systems support it, and it covers three object types: business capabilities (the shared vocabulary between strategy and architecture), applications (which systems realize which processes, visible in both layers), and business processes (process definitions that give the architecture context about what each application actually does).

flowchart LR
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0

    subgraph Process["Process Layer"]
        BP["Business Processes"]
        BCap["Business Capabilities"]
    end

    subgraph Arch["Architecture Layer"]
        APP["Application Objects"]
        CAP["Capability Objects"]
        PROC["Process Objects"]
    end

    BCap -->|"capability sync"| CAP
    CAP -->|"capability sync"| BCap
    BP -->|"process linkage"| PROC
    PROC -->|"process linkage"| BP
    APP -->|"application context"| BP

    class BP business
    class BCap business
    class APP application
    class CAP application
    class PROC application

The capability model is the hinge. When both layers share one capability taxonomy, a process analyst and an enterprise architect are describing the same enterprise. When they do not, every cross-layer conversation begins with a reconciliation exercise.

Autodiscovery from the operations layer addresses the single biggest failure mode of EA repositories: staleness. If landscape data must be manually maintained, it degrades rapidly and architects stop trusting it.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0

    OPS["Operations Platform<br>System Landscape Data"]
    ADC["Autodiscovery<br>Connector"]
    REPO["Architecture<br>Repository"]
    REF["Reference Architecture<br>Catalogs"]
    OBJ["Architecture Objects<br>Auto-populated"]

    OPS -->|"landscape feed"| ADC
    ADC -->|"upserts landscape"| REPO
    REF -->|"loaded into"| REPO
    REPO --> OBJ

    class OPS source
    class ADC integration
    class REPO target
    class REF source
    class OBJ target

Autodiscovery populates system and application instances present in the SAP landscape, integration points between systems (feeding interface objects), and technical component versions (feeding lifecycle and obsolescence tracking). It does not replace business capability mapping, functional fit scoring, or roadmap definition — those still require architect judgment and program-level decisions.

The repository can also be pre-seeded with vendor reference architectures, so that recommended patterns are loaded before custom modeling begins.

Tool access is not uniform across roles, and the same person often occupies multiple roles simultaneously. The persona map determines which layer each role primarily consumes.

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32
    classDef motivation fill:#e6c5f0,stroke:#6a1b9a

    subgraph Strategic["Strategic — C-Level"]
        CIO["CIO / CDO"]
        BLead["Business Leadership"]
    end

    subgraph Architecture["Architecture Layer"]
        EA["Enterprise Architect"]
        SA["Solution Architect"]
    end

    subgraph DeptMgmt["Department Management"]
        ITMgr["IT Manager"]
        BizMgr["Business Manager"]
    end

    subgraph Execution["Execution Layer"]
        SC["Solution Consultant<br>(Integration focus)"]
        SO["Solution Operations"]
    end

    CIO -->|"portfolio decisions<br>via architecture layer"| EA
    BLead -->|"capability gaps<br>via process layer"| EA
    ITMgr -->|"architecture +<br>operations layers"| EA
    ITMgr -->|"architecture +<br>operations layers"| SA
    EA -->|"architecture guidance"| SA
    SA -->|"integration diagrams<br>in the repository"| SC
    SO -->|"operations focus"| ITMgr
    SO -->|"process insights"| BizMgr

    class CIO motivation
    class BLead business
    class EA application
    class SA application
    class ITMgr technology
    class BizMgr business
    class SC technology
    class SO technology

IT Managers sit at the intersection of the architecture and operations layers, bridging solutioning and architecture. Solution Consultants with an integration focus access the repository specifically for integration diagrams — not the full portfolio — which has governance implications for how those diagrams are maintained. Solution Operations is primarily an operations-layer consumer but gains process visibility through the process layer. C-level roles consume aggregated views (portfolio reports, roadmaps) rather than raw architecture objects.

The five-step EA transformation method is applied to four distinct architectural patterns. Each represents a recurring decision type in SAP-centric transformations.

flowchart LR
    classDef motivation fill:#e6c5f0,stroke:#6a1b9a
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef technology fill:#c5e8c5,stroke:#2e7d32

    RS["Rollout Strategy<br>Assessment"]
    TT["Two-Tier<br>Architecture"]
    SA["Split<br>Architecture"]
    TCO["Total Cost of<br>Ownership"]

    RS -->|"determines scope<br>for"| TT
    TT -->|"may evolve into"| SA
    TCO -->|"validates business case<br>across all"| RS
    TCO -->|"validates business case<br>across all"| TT
    TCO -->|"validates business case<br>across all"| SA

    class RS motivation
    class TT application
    class SA technology
    class TCO business

The rollout strategy pattern addresses one of the most politically and technically complex decisions in SAP programs: how many instances, in what sequence, with what template. The five-step method applied here produces a template assessment, instance strategy, and rollout sequence roadmap. In the repository, this surfaces as an application landscape filtered by geography, a matrix report mapping legal entities to application instances, and a roadmap showing rollout sequence with go-live milestones. The central tension is template standardization versus local requirements — resolved through explicit scoping of which legal entities, geographies, and business models are in play.

Two-tier is a permanent architecture decision, not a deployment sequence. It defines a governance model where a global core SAP instance coexists with subsidiary-level systems. The architectural tension — what belongs in the global core versus what is legitimately local — is both a technical and a political decision. The EA transformation approach resolves it through explicit capability mapping: capabilities in the global core are standardized; capabilities in the local tier are differentiated.

flowchart TD
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32
    classDef business fill:#fff3b0,stroke:#cc9a06

    subgraph Tier1["Tier 1 — Global Core"]
        GC["Global SAP S/4HANA<br>Core Processes"]
        GD["Shared Master Data"]
        GR["Group Reporting"]
    end

    subgraph Tier2["Tier 2 — Local / Subsidiary"]
        LS1["Local SAP Instance<br>Entity A"]
        LS2["Local SAP Instance<br>Entity B"]
        LOC["Local Customization<br>& Compliance"]
    end

    GC -->|"master data replication"| LS1
    GC -->|"master data replication"| LS2
    LS1 -->|"financial consolidation"| GR
    LS2 -->|"financial consolidation"| GR
    LOC --> LS1
    LOC --> LS2

    class GC application
    class GD application
    class GR business
    class LS1 technology
    class LS2 technology
    class LOC technology

The split pattern addresses divestiture, carve-out, or business unit separation — the inverse of consolidation. It is the most technically complex of the four patterns because it requires decomposing an existing integrated landscape rather than building one. The integration topology report becomes critical here, surfacing all integration dependencies that must be severed or renegotiated. The roadmap tracks transitional service agreement (TSA) expiry timelines and corresponding architecture milestones. Lifecycle fields mark components as Transferred or Retired in the divested entity.

TCO analysis is the financial validation layer that sits across all three structural patterns. The framework treats TCO as an EA deliverable, not a finance deliverable — because only the architect has the complete landscape picture needed to cost it accurately. The business case is not a single number; it is a comparison across transition scenarios, making the architectural option analysis the direct input to the financial model.

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32
    classDef motivation fill:#e6c5f0,stroke:#6a1b9a

    subgraph CapEx["Capital Expenditure"]
        LIC["License Acquisition"]
        IMPL["Implementation Costs"]
        INFRA["Infrastructure Build"]
    end

    subgraph OpEx["Operational Expenditure"]
        SUB["Subscription / SaaS Fees"]
        RUN["Run & Operate Costs"]
        UPG["Upgrade & Maintenance"]
    end

    subgraph TCO_OUT["TCO Outputs"]
        BC["Business Case"]
        OPT["Option Comparison"]
        ROAD["Investment Roadmap"]
    end

    CapEx --> BC
    OpEx --> BC
    BC --> OPT
    OPT --> ROAD

    class LIC application
    class IMPL application
    class INFRA technology
    class SUB business
    class RUN technology
    class UPG technology
    class BC business
    class OPT motivation
    class ROAD motivation

An architecture repository that is not connected to surrounding systems is an island. The integration architecture operates across four layers: inbound data sources, a connection layer, the repository meta-model, and outbound consumers.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    subgraph Inbound["Inbound — Data Sources"]
        OPS2["Operations Platform"]
        ISSUE["Issue Tracking"]
        ITSM["ITSM / CMDB"]
        DCAT["Data Catalog"]
        CUST["Custom Sources"]
    end

    subgraph ConnLayer["Integration Layer"]
        PRE["Prebuilt Connectors"]
        CAPI["Custom API<br>Integrations"]
        EXP["Export / Import"]
    end

    subgraph Repo["Architecture Repository"]
        META["Meta-Model<br>Architecture Objects"]
        AUTO["Automations"]
        KPI["KPI Engine"]
        MET["Metrics"]
    end

    subgraph Outbound["Outbound — Consumers"]
        BPM2["Process Platform"]
        DASH["Dashboards"]
        EXT["External Reports"]
    end

    OPS2 --> PRE
    ISSUE --> PRE
    ITSM --> PRE
    DCAT --> PRE
    CUST --> CAPI
    CUST --> EXP
    PRE --> META
    CAPI --> META
    EXP --> META
    META --> AUTO
    AUTO --> KPI
    AUTO --> MET
    META --> BPM2
    KPI --> DASH
    MET --> EXT

    class OPS2 source
    class ISSUE source
    class ITSM source
    class DCAT source
    class CUST source
    class PRE integration
    class CAPI integration
    class EXP integration
    class META target
    class AUTO target
    class KPI reporting
    class MET reporting
    class BPM2 reporting
    class DASH reporting
    class EXT reporting

Three advanced extensibility mechanisms elevate the repository from a passive record to an active governance system:

These three mechanisms are where the governance layer from Part 1 becomes operational: the policies defined by the architecture board are encoded as automations and KPIs, making compliance measurable rather than assumed.

mindmap
  root((EA with SAP<br>Patterns in Practice))
    Toolchain
      Architecture Layer
      Process Layer
      Operations Layer
      Bidirectional Capability Sync
    Autodiscovery
      Landscape Feed
      Interface Objects
      Reference Catalogs
    Personas
      Strategic
      Architecture
      Department Management
      Execution
    Four Patterns
      Rollout Strategy
      Two-Tier
      Split and Carve-Out
      TCO and Business Case
    Extensibility
      Connectors
      KPIs
      Automations
      Metrics

Part 2 adds four working conclusions to the five foundations of Part 1:

1. The toolchain is three layers, not one tool. Architecture, process, and operations each own a domain. The architecture layer earns trust only when it is fed by the other two.

2. The capability model is the shared vocabulary. Bidirectional sync of capabilities, applications, and processes between the process and architecture layers is what makes cross-layer conversation possible without reconciliation.

3. The four patterns are the method’s delivery vehicle. Rollout strategy, two-tier, split, and TCO are the recurring decisions through which EA influences the program. The same five steps apply to each; the inputs and deliverables differ.

4. Governance becomes real in KPIs, automations, and metrics. A policy that is not encoded in the repository is a policy that is checked occasionally and enforced rarely.

Part 3 picks up here. With the repository wired to reality and the patterns in use, the question becomes how EA is operated as a continuous function rather than a program deliverable: the governance maturity model, AI-augmented curation, the Live Enterprise Architecture target state, continuous clean architecture, the extension platform as the clean-core layer, emerging technology readiness, and the five-layer operating model that ties the series together.