Clean Core in SAP S/4HANA: Welche Erweiterung gehört wohin?

In gewachsenen SAP-Systemen ist Custom Code selten das Ergebnis einer einzigen Architekturentscheidung. Er entsteht schrittweise: ein zusätzliches Feld, eine Validierung, ein User Exit, eine Schnittstelle, ein Report und später noch eine Fiori-App. Jede einzelne Anforderung war zum Zeitpunkt ihrer Umsetzung nachvollziehbar. In Summe entsteht trotzdem eine Landschaft, in der Upgrades, Tests und Änderungen immer aufwendiger werden.

Clean Core soll genau dieses Problem adressieren. Der Begriff wird in Projekten allerdings häufig zu stark vereinfacht. Dann klingt es entweder nach „kein Custom Code mehr“ oder nach „alles muss auf die SAP BTP“.

Beides halte ich für falsch.

Clean Core bedeutet nicht, auf fachliche Differenzierung zu verzichten. Es bedeutet, Erweiterungen bewusst zu schneiden, über stabile Verträge an den SAP-Standard zu koppeln und ihren Lebenszyklus zu steuern. Je nach Anforderung kann die richtige Lösung direkt in SAP S/4HANA, auf der SAP BTP oder – in begründeten Fällen – weiterhin in klassischem ABAP liegen.

Die entscheidende Frage lautet deshalb nicht: „Welche Technologie wollen wir verwenden?“ Sie lautet: Wie eng gehört diese Anforderung zum Kernprozess, welche Konsistenz braucht sie und wer verantwortet sie langfristig?

Clean Core ist mehr als eine Regel für Custom Code

SAP beschreibt Clean Core über mehrere Dimensionen: Geschäftsprozesse, Erweiterungen, Daten, Integrationen und Betrieb. Ein technisch sauberer Erweiterungspunkt reicht deshalb nicht aus, wenn der zugrunde liegende Prozess unnötig komplex, die Datenqualität schlecht oder die Schnittstelle nicht beherrschbar ist.

Dieser Beitrag konzentriert sich auf die Erweiterungsarchitektur. Die anderen Dimensionen bleiben dabei trotzdem relevant. Eine Side-by-Side-Anwendung kann den S/4HANA-Kern technisch entkoppeln und gleichzeitig neue Betriebs-, Daten- und Integrationsprobleme erzeugen. Umgekehrt kann eine schlanke On-Stack-Erweiterung sehr gut zu Clean Core passen, wenn sie ABAP Cloud und freigegebene APIs nutzt.

Für mich sind drei Ziele besonders wichtig:

• SAP-Standard und eigenen Code klar voneinander trennen,
• Abhängigkeiten über freigegebene und dokumentierte Verträge steuern,
• jede Erweiterung fachlich begründen, testen, überwachen und bei Bedarf wieder ablösen können.

Clean Core ist damit kein einmaliger Aufräumtermin vor einer Migration. Es ist ein Arbeitsmodell für neue Anforderungen und für den bestehenden Custom-Code-Bestand.

Die Entscheidungsreihenfolge

Ich würde eine Erweiterungsanforderung in dieser Reihenfolge prüfen:

1. Kann der SAP-Standard den Prozess bereits abbilden?
2. Reichen Konfiguration, eine vorhandene Fiori-App oder eine standardisierte Prozessvariante aus?
3. Lässt sich die Abweichung mit Key User Extensibility umsetzen?
4. Benötigt die Anforderung eine eng gekoppelte On-Stack-Erweiterung mit ABAP Cloud?
5. Ist eine entkoppelte Side-by-Side-Anwendung auf der SAP BTP fachlich und betrieblich sinnvoller?
6. Bleibt in SAP S/4HANA Cloud Private Edition oder On-Premise nur eine klassische Erweiterung, die bewusst als Ausnahme geführt werden muss?

Diese Reihenfolge ist keine starre Vorschrift. Sie verhindert aber, dass ein Projekt zu früh mit der bevorzugten Technologie beginnt. Wer bereits eine CAP-Anwendung plant, bevor Prozessnähe, Datenkonsistenz und vorhandene Erweiterungspunkte geprüft wurden, hat die Architekturentscheidung im Grunde vorweggenommen.

1. Standard und Konfiguration zuerst prüfen

Nicht jede Abweichung vom heutigen Prozess ist automatisch eine notwendige Erweiterung. Gerade bei einer S/4HANA-Transformation sollte zuerst geklärt werden, ob der bisherige Ablauf noch benötigt wird oder nur deshalb fortgeführt werden soll, weil er im Altsystem existiert.

Der Fit-to-Standard-Gedanke ist dabei kein Selbstzweck. Ein Standardprozess ist sinnvoll, wenn er die fachliche Aufgabe ausreichend gut erfüllt und dauerhaft weniger Sonderaufwand erzeugt. Er ist nicht automatisch sinnvoll, wenn dadurch ein echter Wettbewerbsvorteil, eine gesetzliche Anforderung oder ein kritischer operativer Ablauf verloren geht.

Vor dem ersten technischen Design sollten daher mindestens diese Fragen beantwortet sein:

• Welches fachliche Problem löst die Abweichung?
• Wer nutzt sie tatsächlich?
• Welche Auswirkung hätte der Standardprozess?
• Gibt es bereits Customizing, eine Standard-App, einen Workflow oder eine freigegebene Erweiterungsmöglichkeit?
• Ist die Anforderung strategisch relevant oder nur historisch gewachsen?

Eine ehrliche Standardprüfung spart mehr Komplexität als jede nachträgliche technische Bereinigung.

2. Key User Extensibility für kleine, fachnahe Anpassungen

Key User Extensibility eignet sich für überschaubare Erweiterungen innerhalb der dafür freigegebenen Geschäftskontexte. Typische Beispiele sind zusätzliche Felder, Anpassungen an Oberflächen oder Formularen, einfache Logik und kundeneigene Auswertungen.

Der Vorteil liegt nicht nur in der schnelleren Umsetzung. Die Erweiterung bleibt in einem von SAP vorgesehenen Rahmen und wird über die zugehörigen Werkzeuge verwaltet. Für eine kleine fachliche Ergänzung ist das häufig wirtschaftlicher als ein eigenes Entwicklungsobjekt mit separatem Transport-, Test- und Wartungsaufwand.

Die Grenze ist erreicht, wenn aus einer kleinen Anpassung schrittweise ein eigenes Anwendungsmodell wird. Viele voneinander abhängige Regeln, komplexe Statusübergänge oder eine größere transaktionale Anwendung sollten nicht in eine Sammlung schwer nachvollziehbarer Key-User-Erweiterungen gedrückt werden.

Beispiel: In einem freigegebenen Geschäftskontext wird ein zusätzliches Merkmal benötigt, das in einer Fiori-App angezeigt, gepflegt und in einem Formular ausgegeben werden soll. Wenn das Feld und die notwendige Logik durch die vorgesehenen Erweiterungs-Apps unterstützt werden, ist Key User Extensibility die naheliegende erste Wahl.

3. On-Stack Developer Extensibility für enge Prozesskopplung

Developer Extensibility mit ABAP Cloud ist sinnvoll, wenn eine Erweiterung eng zum S/4HANA-Prozess gehört und mehr als eine kleine Anpassung benötigt. Sie läuft im ABAP-Stack und kann – abhängig von Edition, Release und freigegebenem Umfang – mit CDS, RAP, Business Objects, BAdIs und weiteren released APIs umgesetzt werden.

Typische Merkmale sind:

• die Erweiterung arbeitet unmittelbar mit S/4HANA-Geschäftsobjekten,
• fachliche Prüfungen oder Aktionen müssen im selben System ausgeführt werden,
• transaktionale Konsistenz und geringe Latenz sind wichtig,
• das S/4HANA-Berechtigungs- und Betriebsmodell soll genutzt werden,
• eine RAP-Anwendung oder ein lokaler Service ergänzt den Kernprozess.

ABAP Cloud erzwingt eine klarere Trennung zwischen SAP-Code und kundeneigenem Code. Entscheidend sind dabei released APIs und Extension Points. Ihr Release Contract beschreibt, wofür ein Objekt verwendet werden darf. Eine technisch sichtbare Klasse oder CDS View ist deshalb noch keine stabile Schnittstelle.

Beispiel: Ein Unternehmen benötigt eine zusätzliche fachliche Freigabe für ein Geschäftsobjekt. Die Prüfung hängt direkt von dessen Status und aktuellen Positionsdaten ab und muss konsistent mit der S/4HANA-Transaktion ausgeführt werden. Wenn passende released APIs und Erweiterungspunkte vorhanden sind, ist eine On-Stack-Umsetzung mit ABAP Cloud häufig sauberer als ein synchroner Umweg über die BTP.

Der wichtigste Prüfpunkt lautet allerdings: Ist die benötigte SAP-Funktionalität tatsächlich freigegeben? Fehlt ein passender Vertrag, löst auch eine moderne RAP-Architektur das Kopplungsproblem nicht. Dann müssen fachliche Alternative, Side-by-Side-Schnitt oder – je nach Edition – eine dokumentierte klassische Ausnahme bewertet werden.

4. Side-by-Side auf der SAP BTP für bewusst entkoppelte Anwendungen

Side-by-Side Extensibility ist stark, wenn die Erweiterung einen eigenen Lebenszyklus braucht oder fachlich nicht Teil einer einzelnen S/4HANA-Transaktion ist. Sie kommuniziert über Remote APIs, Events oder Integrationsdienste mit dem Kernsystem und kann beispielsweise mit CAP, Java, Node.js, SAP Build oder ABAP Environment umgesetzt werden.

Typische Gründe für Side-by-Side sind:

• eine Anwendung verbindet mehrere SAP- und Nicht-SAP-Systeme,
• externe Benutzer sollen ohne direkten S/4HANA-Zugang arbeiten,
• der Prozess kann zeitlich oder transaktional vom Kernsystem entkoppelt werden,
• Skalierung und Releasezyklus sollen unabhängig von S/4HANA sein,
• eine eigene Benutzeroberfläche oder Cloud-Funktionalität steht im Mittelpunkt,
• Events sind fachlich sinnvoller als enge synchrone Aufrufe.

Beispiel: Ein Lieferantenportal sammelt Rückmeldungen und Dokumente, führt einen eigenen Bearbeitungsstatus und überträgt bestätigte Ergebnisse an mehrere ERP-Systeme. Die Benutzer, der Lebenszyklus und ein großer Teil des Datenmodells liegen außerhalb eines einzelnen S/4HANA-Kernprozesses. Eine Side-by-Side-Anwendung ist hier meist besser geschnitten als ein umfangreicher Eigenbau direkt im ERP.

Side-by-Side ist allerdings nicht automatisch „clean“. Das Projekt übernimmt zusätzliche Verantwortung für Authentifizierung, Berechtigungen, Destinations, Datenhaltung, Monitoring, Fehlerbehandlung, Deployment und Betrieb. Werden große Datenmengen repliziert oder viele synchrone Einzelaufrufe aufgebaut, verschiebt sich die Kopplung lediglich vom Quellcode in die Integration.

Besonders kritisch ist die Konsistenzfrage. Eine verteilte Anwendung kann nicht so behandelt werden, als gäbe es eine gemeinsame lokale SAP-Transaktion. Timeouts, Wiederholungen, doppelte Events, Teilfehler und Konflikte müssen fachlich eingeplant werden.

5. Klassisches ABAP als begründete Ausnahme

In SAP S/4HANA Cloud Private Edition und On-Premise verschwinden gewachsene klassische Erweiterungen nicht über Nacht. Es gibt außerdem Szenarien, für die im konkreten Release noch keine ausreichende released API vorhanden ist.

Die falsche Reaktion wäre, diese Realität zu verschweigen. Ebenso falsch wäre es, daraus eine pauschale Freigabe für neue direkte Zugriffe auf interne SAP-Objekte abzuleiten.

Wenn eine klassische Erweiterung notwendig bleibt, sollte sie als bewusste Architekturentscheidung dokumentiert werden:

• Warum reicht keine freigegebene Alternative?
• Welche internen SAP-Objekte oder klassischen Erweiterungspunkte werden verwendet?
• Welches Upgrade- und Test-Risiko entsteht?
• Wer ist fachlich und technisch verantwortlich?
• Wie werden Änderungen am SAP-Objekt überwacht?
• Gibt es einen späteren Transformationspfad?

SAP unterscheidet für die Bewertung von Erweiterungen inzwischen Clean-Core-Level. Vereinfacht steht Level A für ABAP Cloud mit released APIs und Extension Points. Level B umfasst von SAP als Best Practice eingeordnete klassische APIs. Level C beschreibt die kontrollierte Nutzung interner Objekte als „Conditional Clean Core“, während Level D nicht empfohlene und nicht upgrade-stabile Kopplungen kennzeichnet.

Diese Einstufung ist als Risikomodell hilfreich. Sie ersetzt aber nicht die fachliche Architekturentscheidung und auch nicht die Verantwortung für Tests und Betrieb.

Vergleich der Erweiterungsoptionen

Kriterium	Key User Extensibility	Developer Extensibility On-Stack	Side-by-Side auf SAP BTP	Klassische Erweiterung
Typischer Umfang	klein und fachnah	mittel bis komplex	eigenständig oder systemübergreifend	komplexe oder historisch eng gekoppelte Ausnahme
Nähe zum S/4HANA-Prozess	sehr hoch	hoch	mittel bis gering	sehr hoch
Transaktionale Kopplung	innerhalb freigegebener Funktionen	lokal und eng	über Remote API oder Event	lokal und eng
Technologie	In-App-Werkzeuge	ABAP Cloud, CDS, RAP	CAP, Java, Node.js, SAP Build, ABAP Environment u. a.	Standard ABAP und klassische Erweiterungstechniken
Schnittstellen	freigegebene Geschäftskontexte	released lokale APIs und Extension Points	released Remote APIs und Events	gegebenenfalls interne oder klassische SAP-Objekte
Lebenszyklus	mit S/4HANA	mit S/4HANA und Softwarekomponente	eigenständiger Build und Betrieb	eng an S/4HANA gekoppelt
Hauptrisiko	Überladung einfacher Werkzeuge	fehlende released API	verteilte Daten- und Betriebskomplexität	Upgrade-Risiko und technische Schuld

Die Tabelle ist keine automatische Auswahlregel. Eine kleine Side-by-Side-App kann sinnvoll sein, wenn externe Benutzer beteiligt sind. Eine umfangreiche On-Stack-App kann sauber bleiben, wenn sie fachlich eng gekoppelt ist und vollständig auf freigegebenen Verträgen basiert.

Acht Fragen vor der Architekturentscheidung

1. Welche Edition und welches Release sind gesetzt?

Public Edition, Private Edition und On-Premise bieten nicht dieselben Erweiterungsoptionen. Auch der Umfang freigegebener APIs und Geschäftskontexte entwickelt sich weiter. Eine Architektur darf deshalb nicht nur gegen eine allgemeine Produktdarstellung geprüft werden.

2. Ist die Anforderung wirklich differenzierend?

Custom Code sollte einen nachvollziehbaren fachlichen Wert haben. „Das war im alten System auch so“ reicht nicht. Ein Standardprozess kann die bessere Lösung sein, selbst wenn er organisatorische Veränderung verlangt.

3. Wo liegt das führende Geschäftsobjekt?

Wenn Daten und Status vollständig in S/4HANA geführt werden, spricht das häufig für eine On-Stack-Lösung. Besitzt die Erweiterung ein eigenes Geschäftsobjekt mit eigenem Lebenszyklus, kann Side-by-Side passender sein.

4. Welche Konsistenz benötigt der Prozess?

Muss eine Änderung atomar mit einer S/4HANA-Buchung erfolgen, ist eine lokale Kopplung oft sinnvoll. Kann der Prozess mit Events, Wiederholungen und zeitversetzter Verarbeitung umgehen, wird Entkopplung realistischer.

5. Welche released APIs und Extension Points existieren?

Die fachlich gewünschte Architektur muss technisch durch freigegebene Verträge getragen werden. Dabei ist zwischen lokalen APIs, Erweiterungsverträgen und Remote APIs zu unterscheiden.

6. Wer nutzt die Erweiterung?

Interne S/4HANA-Anwender, externe Partner, mobile Benutzer oder mehrere Gesellschaften haben unterschiedliche Anforderungen an Identität, Berechtigung, UX und Systemzugriff.

7. Wer betreibt und wartet die Lösung?

Eine BTP-Anwendung braucht Monitoring, Security, Deployment und Support. Eine On-Stack-Erweiterung braucht Transport-, Test- und Upgradeprozesse. Die richtige Architektur muss zum tatsächlichen Betriebsmodell passen.

8. Wie kann die Erweiterung später verändert oder entfernt werden?

Ownership, Nutzung und Abhängigkeiten sollten von Anfang an dokumentiert werden. Eine Erweiterung ohne fachlichen Owner und überprüfbaren Zweck wird mit hoher Wahrscheinlichkeit zu dauerhaftem Ballast.

Vier typische Fehlentscheidungen

Alles auf die BTP verschieben

Eine räumliche Trennung macht eine Erweiterung nicht automatisch lose gekoppelt. Wenn die Anwendung bei jedem Arbeitsschritt synchron auf interne ERP-Daten angewiesen ist, große Datenbestände repliziert und den S/4HANA-Prozess nur nachbaut, entsteht neue Komplexität außerhalb des Kerns.

Modernes ABAP mit Clean Core gleichsetzen

RAP, CDS und moderne Syntax sind wichtige Bausteine. Clean Core entsteht aber erst durch die Nutzung freigegebener Verträge und eine beherrschte Architektur. Eine RAP-Anwendung mit indirektem Zugriff auf interne SAP-Tabellen bleibt problematisch.

Key User Extensibility überladen

Viele kleine Regeln können zusammen ein schwer wartbares System ergeben. Wenn Logik, Status und Abhängigkeiten wachsen, sollte geprüft werden, ob ein klar modelliertes Geschäftsobjekt die bessere Lösung ist.

Klassisches ABAP aus Gewohnheit wählen

Vertrautheit und vorhandene Entwicklerkenntnisse sind legitime Projektfaktoren. Sie rechtfertigen aber nicht automatisch neue enge Kopplungen an interne SAP-Objekte. Für neue Entwicklungen sollte ABAP Cloud mit released APIs ernsthaft geprüft werden.

Was tun mit bestehendem Custom Code?

Bei einer gewachsenen Landschaft würde ich nicht versuchen, jeden vorhandenen Z-Code sofort technisch zu modernisieren. Der erste Schritt ist eine Bestandsaufnahme mit Nutzungs- und Prozessbezug.

Eine pragmatische Reihenfolge ist:

1. Erweiterungen, Modifikationen, Schnittstellen und Eigenentwicklungen inventarisieren.
2. Mit Usage Data und technischen Analysen prüfen, was tatsächlich verwendet wird.
3. Für relevante Objekte einen fachlichen Owner bestimmen.
4. Kopplung, APIs, Prozesskritikalität und Clean-Core-Risiko klassifizieren.
5. Je Objekt entscheiden: stilllegen, beibehalten, kapseln, anpassen oder neu bauen.
6. Regressionstests und Änderungsmonitoring etablieren.

Werkzeuge wie ABAP Test Cockpit, Custom Code Migration App, SQL Monitor und weitere Analysen helfen bei der technischen Bewertung. Sie beantworten aber nicht allein, ob ein Programm fachlich noch benötigt wird.

Ungenutzten Code nur deshalb zu migrieren, weil er vorhanden ist, erzeugt keinen Wert. Produktive Erweiterungen nur aufgrund eines Tool-Findings zu entfernen, ohne den Prozess zu verstehen, ist genauso riskant.

Governance macht aus einer Leitlinie eine belastbare Praxis

Clean Core funktioniert dauerhaft nur, wenn Architekturentscheidungen nachvollziehbar bleiben. Für jede relevante Erweiterung sollten mindestens dokumentiert werden:

• fachlicher und technischer Owner,
• begründeter Erweiterungsbedarf,
• gewählte Option und verworfene Alternativen,
• verwendete APIs, Events und Extension Points inklusive Release State,
• betroffene Prozesse, Daten und Berechtigungen,
• Test-, Transport-, Deployment- und Rollbackstrategie,
• Betriebs- und Nutzungsmonitoring,
• Reviewdatum sowie möglicher Ablösepfad.

Das klingt zunächst nach zusätzlichem Aufwand. In der Praxis ist dieser Aufwand deutlich kleiner als die spätere Suche nach unbekannten Abhängigkeiten vor einem Upgrade oder Releasewechsel.

Meine pragmatische Empfehlung

Ich würde Clean Core nicht als Technologieprogramm beginnen, sondern mit einer einfachen Architekturregel:

Standard, wenn der Standard fachlich trägt. Key User Extensibility für kleine freigegebene Anpassungen. ABAP Cloud On-Stack für eng gekoppelte S/4HANA-Erweiterungen. Side-by-Side für bewusst entkoppelte Anwendungen mit eigenem Lebenszyklus. Klassisches ABAP nur als dokumentierte Ausnahme, wenn der konkrete Systemkontext es erfordert.

Die Reihenfolge allein reicht allerdings nicht. Entscheidend sind die Grenzen zwischen den Komponenten: Wer besitzt die Daten? Wo liegt die fachliche Logik? Welche Konsistenz ist notwendig? Welche API bildet den Vertrag? Wer betreibt die Lösung?

Eine gute Clean-Core-Architektur hat nicht zwingend den wenigsten Custom Code. Sie hat nachvollziehbare Verantwortlichkeiten, stabile Schnittstellen und eine realistische Strategie für Änderungen. Genau dadurch bleibt das System anpassbar, ohne bei jeder Erweiterung mehr technische Schuld aufzubauen.