The five-layer architecture for SAP Change Governance: who decides at which level

1. What the five-layer view of SAP Change Governance describes

SAP Change Management in 2026 is no longer a single-tool decision, but a stack of multiple layers, each with its own tasks, tools, and decision-making authority. The five-layer view is an analytical lens used to organize this stack. It is not an official standard or an analyst model, but a framework for thinking that helps prevent the confusion of different tools.

This confusion is the most common reason why tool comparisons fail and why answers to the question of the right tool remain incomplete. Anyone who equates an ALM platform with a governance instance is comparing things that exist on different levels.

1. Distinction from pure tool selection. This article does not rank products against each other; instead, it describes which task belongs to which level and who makes the decisions there. The question of specific tools for hybrid landscapes is covered in a separate article; this one focuses on the underlying architecture.

2. Why a layered view is necessary. As soon as requirements, systems, lifecycles, governance, and deployment are mixed together in a discussion, false contradictions arise. Separating them into layers makes it clear that a tool can be strong on one level and weak on another without this being a contradiction.

2. Why the layers are drifting apart in 2026

1. AI agents are accessing production systems. With autonomous agents from the SAP ecosystem and third-party providers, changes are emerging that no longer originate solely from human developers. This turns the question of who approves a change for production from a workflow issue into an architectural one. The governance layer must handle human and machine-generated changes consistently.

2. Hybrid landscapes are dominant. The 2026 DSAG Investment Report documents that around 78 percent of companies in the DACH region operate hybrid or on-premise-heavy landscapes. In such environments, the layers rarely reside in a single product but are distributed across multiple tools that must work together.

3. Multiple regulatory frameworks apply simultaneously. SOX, GxP, NIS2, DORA, and the EU AI Act require evidence at the governance level, not the tool level. Anyone who confuses governance with ticketing or transport cannot provide this evidence properly because they are looking for accountability in the wrong layer.

4. The deployment level is irreversible. A transport import into production is technically irreversible, as noted in SAP Note 11599. This is precisely why the decision of whether a change is deployed must be made before the deployment level, within a dedicated governance layer.

3. The five layers in detail

The stack can be divided into five layers, from requirements to execution. Each has a clearly defined task.

1. Layer 1, business processes. This is where the need for change arises, for example in order-to-cash, procure-to-pay, or the financial close. The business owns these processes, and documentation is handled in process modeling tools such as SAP Signavio, Celonis, or ARIS. Decision-making authority lies with the process owners.

2. Layer 2, Systems. The systems into which changes are delivered: S/4HANA on-premise and in the cloud, SAP ECC, BTP extensions, SuccessFactors, Ariba, as well as non-SAP systems like Salesforce or Workday. In hybrid landscapes, this layer is heterogeneous, with different transport and release mechanisms for each system.

3. Layer 3, ALM. The lifecycle level: SAP Cloud ALM, SAP Solution Manager, Jira, ServiceNow, Azure DevOps. It manages the change lifecycle, ticketing, project structure, and the fundamental workflow. However, it does not inherently enforce decision-making authority over high-risk SAP changes; that is a different layer.

4. Layer 4, Change Governance. The decision-making and policy level above the ALM layer. It determines which changes are permitted into production, implements regulatory requirements, enforces the four-eyes principle and segregation of duties, creates an audit trail at the object level, and manages both human- and machine-triggered changes in a unified manner. Tools operating at this level include Rev-Trac, Basis Technologies ActiveControl in conjunction with Klario, REALTECH SmartChange, CoreALM, and the Orchestration Layer¹.

5. Layer 5, Deployment. The technical execution of approved changes: Transport Management System, gCTS, cTMS, BTP CI/CD pipelines, Project Piper, Azure DevOps pipelines, Jenkins. This layer executes what the governance layer has approved, and its imports into production are irreversible.

4. Where confusing the layers leads to poor decision-making

1. Equating ALM with governance. The most common mistake is assuming that an ALM platform automatically provides governance. An ALM layer manages the lifecycle, but it does not necessarily provide the mandatory "no" before production. Those who equate the two believe they have a level of control that is, in fact, missing.

2. Mistaking deployment for governance. A powerful transport or pipeline tool executes changes cleanly, but it does not make policy decisions. Those who mistake the deployment layer for governance automate execution without controlling the approval process, thereby increasing risk rather than reducing it.

3. The governance layer is missing entirely. In many landscapes, layer 4 is not explicitly occupied at all. Requirements, systems, ALM, and deployment are present, but decision-making authority is implicitly scattered across multiple tools. This gap becomes critical as soon as AI agents trigger changes, because then no one is clearly responsible for the approval.

4. Looking for compliance in the wrong layer. Audit evidence for SOX, NIS2, DORA, or the EU AI Act belongs in the governance layer. Those who look for it in the ALM or deployment layers will find fragments, but no end-to-end proof from requirement to deployment.

5. Comparing tools across different layers. Comparing an ALM tool against a governance layer or a deployment tool leads to misleading results. Tools can only be meaningfully compared within the same layer.

5. A reading order for architectural decisions

The layer view is primarily useful as a sequence for decision-making. It prevents tool selection from preceding the clarification of tasks.

1. Read from top to bottom. First, clarify business processes and their change requirements, then the affected systems, then the ALM level, and only then the governance and deployment layer. Anyone who starts with the tool jumps into the middle of the stack.

2. Define the governance layer consciously. Determine which authority holds the binding "no" before production, and whether it covers both human and machine-based changes consistently. If this layer is not currently staffed, that is your most important finding.

3. Compare tools only within their respective layers. ALM tools against ALM tools, governance tools against governance tools. This makes it clear where a product is truly strong and where it assumes the existence of another layer.

4. Respect the irreversibility of the deployment layer. Because production imports cannot be rolled back, the approval decision must be clearly separated from execution. The governance layer is therefore not a luxury, but the prerequisite for a controlled deployment process.

5. Apply the layers consistently across the entire landscape. In hybrid landscapes, all five layers must be consistent across both SAP and non-SAP systems; otherwise, areas will emerge without end-to-end governance or a reliable audit trail.

6. Tool Landscape

The following table categorizes the five layers with their respective tasks, typical tools, and decision-making authority. It is a structuring aid, not a product ranking.

¹ Solutive AG is the initiator of the Change Orchestration Institute. The assessment in the table is a self-disclosure by the provider and is not part of an editorially independent validation. Multiple providers operate alongside each other at the governance layer. The Orchestration Layer is one of them and is mentioned here alongside its competitors without priority.

The table shows that no single product covers all five layers with equal strength. ALM tools are strong in the lifecycle, deployment tools in execution, and the governance layer is a distinct level with its own decision-making authority. A robust architecture consciously occupies every layer, rather than hoping that an ALM or deployment tool will handle governance as well.

7. Operational consequences for SAP organizations

The layer view leads to concrete steps.

The first consequence concerns language. Those who think and speak in terms of layers avoid the most common source of error: confusing ALM, governance, and deployment. Simply naming the layers clearly improves every discussion about tools.

The second consequence concerns the governance layer. Organizations should evaluate whether layer 4 is explicitly staffed at all. If decision-making authority regarding production changes is implicitly scattered, this is the most urgent gap, especially where AI agents trigger changes.

The third consequence concerns comparability. Tool comparisons should only be conducted within the same layer. This makes decisions transparent and prevents false comparisons across different levels.

The fourth consequence concerns consistency. In hybrid landscapes, these layers must be applied consistently across all systems so that no area remains without governance or a continuous audit trail.