---

Introduction: SAP Go‑Live Is Not the Finish Line

Reaching SAP go‑live is not the finish line. It is a new starting point in the lifecycle of your enterprise architecture (EA). The business environment and technology landscape keep evolving, so the “ideal future state” you defined during the project rapidly drifts away from reality if left unattended.

In TOGAF®, the Architecture Development Method (ADM) Phase H – “Architecture Change Management” – is the core phase that keeps EA evolving in this age of constant change. This article explains how to apply the mindset of Phase H to SAP implementation and post‑go‑live operations from an EA perspective.

---

The Essence of TOGAF® ADM Phase H: Managing the “Breathing” of Architecture

TOGAF® defines Phase H as the phase that “manages changes to the architecture over time.” This is not just about operational support tickets or processing change requests. It is about intentionally designing and managing the “breathing” of your architecture as a living system.

You can summarize the key concepts of Phase H into three themes.togaf.

1. Continuous monitoring
   Continuously monitor changes in technology, business, and governance (policies and regulations), and constantly assess their impact on EA. This includes tracking industry regulations, platform roadmaps, and strategic shifts that may affect your SAP landscape.
2. Structured change management
   Capture changes not as ad‑hoc, local fixes but as structured Architecture Change Requests (ACRs) and make decisions, design, and execution under governance. This prevents uncoordinated changes from eroding your target architecture.
3. Lifecycle reboot
   For high‑impact changes, raise a formal Request for Architecture Work and launch a new ADM cycle for re‑designing the architecture. This ensures that large, strategic shifts are handled by revisiting EA, not by incremental patching.

From an EA point of view, the critical design decision is not only “how to react to changes” but also “which changes can be treated as minor updates and which must be escalated into a full EA redesign.” In other words, you deliberately design thresholds and decision‑making processes.

---

Why Architecture Change Management Matters for SAP

When you apply the thinking of Phase H to SAP programs, the objectives can be grouped into three themes.

1. Keeping the original vision and KPIs alive after go‑live

In most SAP programs, the initial envisioning phase defines an aspirational target:

• Globally standardized business processes
• Real‑time visibility into management information
• Optimization of inventory, cash flow, and lead time

However, after go‑live, the following symptoms appear in many organizations:

• Local “exception handling” accumulates, and the standard process becomes a formality
• Ad‑hoc customizations and local tools (such as Excel) make a comeback
• The KPIs defined at the beginning are not monitored, and improvement efforts fade away

The purpose of Architecture Change Management is to regularly review and recalibrate the vision and KPIs after go‑live so that the SAP solution keeps generating business value. Put differently, it is about turning the original project charter into a “constitution” that continues to guide operations.

2. Responding to technological and business change with agility and control

The SAP ecosystem is as dynamic as the business itself. Typical sources of change include:

• New S/4HANA releases and functional enhancements
• Evolving extension patterns with SAP BTP
• Changes in industry regulations, tax requirements, and accounting standards
• Portfolio changes and M&A activities

If you address each of these purely as isolated projects, your landscape will become a patchwork of one‑off solutions within a few years. By applying Phase H, you can move toward the following state:

• Structure changes and quickly assess which layers (business, application, data, technology) are impacted
• Organize change requests at the EA level and check alignment with global templates and architectural principles before deciding how to respondtogaf+1
• Map changes into a mid‑term architecture roadmap instead of a backlog of unrelated initiatives, and make investment decisions accordingly

3. Determining the “next transformation cycle”

At some point, you inevitably face bigger questions:

• “Does our current SAP template truly fit the future business model?”
• “From this point on, would we be better off re‑designing the global template rather than continuing incremental fixes?”

Phase H is responsible for deciding when and under what conditions to launch the next major transformation. Typical triggers include:

• Accumulation of change requests above a certain size or complexity
• Strategic shifts such as moving from B2B to D2C, or re‑designing the global supply chain
• Platform inflection points such as moving from on‑premises to cloud, or from ECC to S/4HANA as a strategic migration

When such triggers converge, you issue a Request for Architecture Work and formally start a new EA cycle – a new program or transformation wave.

---

Concrete Outputs and Outcomes in SAP Programs

Let us now look at what exactly emerges from an Architecture Change Management process in an SAP‑enabled enterprise, and how it translates into tangible results.

Key outputs

1. Updated SAP enterprise architecture documentation

Typical artifacts include:

• “To‑be” models of core business processes (for example, Order‑to‑Cash, Procure‑to‑Pay)
• System landscape diagrams describing S/4HANA and integrations with surrounding cloud and legacy systems
• Data domain and master data ownership definitions (MDM/RDM scope and responsibilities)
• High‑level security and authorization model principles

You keep these artifacts up to date so that there is always a single official representation of the current EA.

2. Evolved global templates, principles, and standards

Based on learnings and change requests in Phase H, you iteratively refine the template itself:

• Rules for standard processes and allowable local variants
• Extension policies (recommended BTP extension patterns and constraints on custom add‑ons)
• Interface standards (API‑first, event‑driven integration, and so on)
• Data and reporting standards (common KPI definitions and canonical data models)
  

3. Architecture Change Requests (ACRs) and backlog

You manage change requests as EA‑structured items rather than simple development tickets:

• Classify each request by business domain and affected architecture layers
• Assess priority, business value, risk, and dependencies
• Map them into product backlogs and project portfolio items

ACRs become a structured input into both agile delivery and portfolio management.

4. Requests for Architecture Work (new EA cycles)

For the next major transformation or roll‑out wave, you prepare formal Requests for Architecture Work:togaf.

• Clarify scope, objectives, expected business outcomes, and impacted organizations and systems
• Provide “program‑level” artifacts that can be handed over into the next ADM cycle (Phase A onward)
  

5. Value realization and monitoring mechanisms

You design and operate the mechanisms to monitor value realization:

• Dashboards that continuously track the KPIs defined during SAP implementation
• A list of potential improvement themes linking KPIs to process indicators
• Standard agendas and templates for regular governance sessions (for example, a Value Realization Board)

Main outcomes

If you operate Phase H effectively around SAP, you can expect outcomes such as:

• Sustained and amplified business value
  KPIs such as inventory, cash, and lead time keep improving not only immediately after go‑live but over the mid‑ to long term. SAP is positioned as a platform for competitive advantage rather than a cost center.
• Preserved architectural integrity
  While you incorporate local and business‑unit‑specific requirements, you still maintain alignment with the global template and common data model, preventing uncontrolled customization and “spaghetti” integrations.
• A change‑resilient SAP landscape
  You can integrate new businesses, acquired companies, and partner ecosystems in a planned way, and for major shifts you can consciously choose full re‑design cycles over local optimizations.

---

Skills and Knowledge Required for Architecture Change Management

To lead Phase H in an SAP‑enabled enterprise, EA practitioners need a broad skill and knowledge set.

1. EA frameworks and practical TOGAF® experience

• Understanding of the full TOGAF® ADM and the input/output relationships across phases
• Ability to view business, application, data, and technology architecture as integrated layers
• Experience in designing governance such as architecture boards, principles, and compliance reviews
  

2. Understanding SAP solutions and landscape structures

• Knowledge of S/4HANA modules and typical end‑to‑end business processes
• Familiarity with integration patterns involving surrounding cloud products (for example, SAP SuccessFactors, Ariba, CX, BTP)
• Understanding of landscape patterns such as Dev/QA/Prod segregation, regional splits, and hybrid cloud setups

From an EA standpoint, it is essential to map which SAP system supports which business capabilities.

3. Organizational change management (OCM) and stakeholder management

• Ability to understand and align expectations across executives, business units, IT, and end users
• Designing rollout and adoption strategies that fit the organizational culture (big‑bang, phased, or pilot‑based)
• Redesigning roles, skills, and organizational structures alongside process and system changes

In Phase H, you must design change to be not only “technically correct” but also “organizationally adopted and utilized.”

4. Risk, compliance, and technology trend assessment

• Ability to interpret how regulatory, legal, and accounting changes impact business processes and SAP modules
• Evaluating SAP’s own roadmap (new releases, end‑of‑maintenance, cloud strategy) against your enterprise architecture
• Incorporating cross‑cutting themes such as cybersecurity, data privacy, and sustainability into EA

---

Conclusion: EA’s Responsibility for “Life After SAP Go‑Live”

SAP implementation is not just an IT project. It is a large‑scale enterprise architecture transformation. TOGAF® ADM Phase H clearly articulates the role EA must play “after the transformation.”

In practice, this means:

• Keeping the implementation vision and KPIs alive beyond go‑live
• Seeing technological and business changes through an EA lens and responding in a structured manner
• Judging the timing and scope of the next transformation cycle

If your organization feels that “SAP is live, but the overall direction and evolution path are unclear,” it is worth asking how Phase H is designed in your context. From there, we can explore together whether to start with Phase H at the global template level, at the regional rollout level, or at the single‑entity level, and determine which scope is most realistic as your first step.

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

---

Reference Links

• Phase H: Architecture Change Management – The Open Group
  https://www.opengroup.org/architecture/togaf
• A Comprehensive Guide for TOGAF ADM Phase H: Architecture Change Management
  https://togaf.visual-paradigm.com/
• Optimizing Enterprise Architecture with TOGAF Framework and SAP
  https://www.sapbwconsulting.com/blog/togaf-framework

---

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