Clean Core in SAP S/4HANA: die vier Level und wer sie freigibt
Der Kern bleibt standardnah, der Unterschied entsteht daneben. Wer die vier Level kennt, weiß bei jeder Anforderung vorher, was sie beim nächsten Upgrade kostet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Erst wird gebaut, dann wird die Stufe bestimmt, und das Upgrade schickt die Rechnung
Der Ablauf ist überall derselbe. Der Fachbereich braucht etwas, das der Standard so nicht kann. Es gibt einen Termin, es gibt jemanden, der weiß, wie man das im System hinbekommt, und es gibt einen Weg, der heute funktioniert. Ob dieser Weg auf ein SAP-internes Objekt zugreift, ob er eine Tabelle direkt beschreibt oder ob er den Standard an einer Stelle verändert, wird nicht gefragt, weil es die Lösung nicht schneller macht. Die Frage stellt sich erst beim nächsten Upgrade, und dann stellt sie das System.
Der zweite Grund, warum das teuer wird, ist die fehlende Buchführung. Nach ein paar Jahren gibt es einige hundert eigene Objekte, und niemand kann sagen, welche davon problemlos durch ein Upgrade gehen und welche jedes Mal angefasst werden müssen. Damit lässt sich der Aufwand eines Upgrades nicht schätzen, und was sich nicht schätzen lässt, wird verschoben. Genau daraus entstehen die Systeme, die drei Releases hinterherhinken und deren Nachziehen dann ein eigenes Vorhaben ist.
Der dritte Punkt ist, dass sich die Regeln geändert haben. Viele Texte im Netz beschreiben noch das ältere Drei-Ebenen-Modell, das SAP inzwischen weiterentwickelt hat. Wer heute mit den drei Ebenen argumentiert, argumentiert mit einem überholten Stand, und das fällt spätestens dann auf, wenn jemand mit dem aktuellen Modell dagegenhält. Seit dem 12. August 2025 gilt das Clean-Core-Level-Konzept mit vier Stufen von A bis D, und diese Stufen sind die Sprache, in der man heute über Erweiterungen redet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer umsetzt
Regeln zu Erweiterungen scheitern selten am Inhalt und fast immer daran, dass niemand benannt ist, der im konkreten Fall auch Nein sagen darf. Diese sechs Zeilen decken die Fälle ab, die in einem SAP-Haus tatsächlich auftreten.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Eine neue Erweiterung wird angefordert | Die Architektur zusammen mit dem Prozessverantwortlichen des betroffenen Bereichs, weil die Stufe eine fachliche und eine technische Seite hat | Die Entwicklung, mit der Angabe des angestrebten Levels in der Anforderung und nicht erst im Abnahmeprotokoll | Die Stufe wird nach dem Bau bestimmt. Zu diesem Zeitpunkt geht es nicht mehr um eine Entscheidung, sondern um eine Rechtfertigung, und die fällt immer zugunsten des fertigen Codes aus. |
| Ein benötigtes SAP-Objekt ist nicht freigegeben | Die Architektur, und zwar ausdrücklich, weil ab hier Level C beginnt und damit die Zusage der Stabilität endet | Die Entwicklung, mit einer Notiz am Objekt, welches nicht freigegebene Element benutzt wird und warum es keinen freigegebenen Weg gab | Es wird genommen, was da ist, weil es funktioniert. Beim nächsten Upgrade ändert sich ein internes Objekt, ohne dass jemand das ankündigen müsste, denn genau dafür gibt es die Unterscheidung. |
| Side-by-Side auf SAP BTP oder On-Stack mit ABAP Cloud | Die Architektur, entlang der Frage nach Datennähe, Betriebsverantwortung und Lebensdauer der Anwendung | Das Team, das die Anwendung baut, in Abstimmung mit dem Betrieb, weil beide Wege unterschiedliche Betriebsaufgaben nach sich ziehen | Die Entscheidung fällt danach, welche Leute gerade Zeit haben. Danach steht eine Anwendung an der falschen Stelle, und der Umzug ist kein Umzug, sondern ein Neubau. |
| Bestandsobjekte, die heute auf Level C oder D liegen | Wer für das Produkt im Betrieb geradesteht, gemeinsam mit dem Fachbereich, weil die Ablösung fachliche Entscheidungen erfordert | Das Team, in einer Reihenfolge nach Wirkung und nicht nach Aufwand, angefangen bei den Objekten, die bei jedem Upgrade auffallen | Es entsteht eine Liste ohne Termine. Eine Liste ohne Termine ist Dokumentation des Problems und keine Bearbeitung davon. |
| Modifikationen und implizite Erweiterungen | Ausschließlich die technische Leitung, als benannte Ausnahme mit Ablaufdatum, nicht das Team unter Termindruck | Die Entwicklung, mit einer Begründung im selben Änderungsvorgang, in dem der Eingriff entsteht | Die Ausnahme wird mündlich erteilt. Ein halbes Jahr später erinnert sich niemand daran, und beim Upgrade steht das Team vor einer Änderung, für die es keinen Anlass mehr findet. |
| Eigene Objekte, die andere Teams benutzen sollen | Das Team, dem das Objekt gehört, gemeinsam mit der Architektur, weil eine Freigabe eine Zusage über die Zeit ist | Das besitzende Team, mit einer bewusst schmal gehaltenen Schnittstelle statt eines offenen Zugriffs auf alles im Paket | Andere Teams greifen einfach auf interne Objekte zu, weil sie im selben System liegen. Damit habt ihr das Problem, das Clean Core gegenüber SAP löst, im eigenen Haus nachgebaut. |
Eine neue Erweiterung wird angefordert
- Wer entscheidet
- Die Architektur zusammen mit dem Prozessverantwortlichen des betroffenen Bereichs, weil die Stufe eine fachliche und eine technische Seite hat
- Wer setzt um
- Die Entwicklung, mit der Angabe des angestrebten Levels in der Anforderung und nicht erst im Abnahmeprotokoll
- Stolperfalle
- Die Stufe wird nach dem Bau bestimmt. Zu diesem Zeitpunkt geht es nicht mehr um eine Entscheidung, sondern um eine Rechtfertigung, und die fällt immer zugunsten des fertigen Codes aus.
Ein benötigtes SAP-Objekt ist nicht freigegeben
- Wer entscheidet
- Die Architektur, und zwar ausdrücklich, weil ab hier Level C beginnt und damit die Zusage der Stabilität endet
- Wer setzt um
- Die Entwicklung, mit einer Notiz am Objekt, welches nicht freigegebene Element benutzt wird und warum es keinen freigegebenen Weg gab
- Stolperfalle
- Es wird genommen, was da ist, weil es funktioniert. Beim nächsten Upgrade ändert sich ein internes Objekt, ohne dass jemand das ankündigen müsste, denn genau dafür gibt es die Unterscheidung.
Side-by-Side auf SAP BTP oder On-Stack mit ABAP Cloud
- Wer entscheidet
- Die Architektur, entlang der Frage nach Datennähe, Betriebsverantwortung und Lebensdauer der Anwendung
- Wer setzt um
- Das Team, das die Anwendung baut, in Abstimmung mit dem Betrieb, weil beide Wege unterschiedliche Betriebsaufgaben nach sich ziehen
- Stolperfalle
- Die Entscheidung fällt danach, welche Leute gerade Zeit haben. Danach steht eine Anwendung an der falschen Stelle, und der Umzug ist kein Umzug, sondern ein Neubau.
Bestandsobjekte, die heute auf Level C oder D liegen
- Wer entscheidet
- Wer für das Produkt im Betrieb geradesteht, gemeinsam mit dem Fachbereich, weil die Ablösung fachliche Entscheidungen erfordert
- Wer setzt um
- Das Team, in einer Reihenfolge nach Wirkung und nicht nach Aufwand, angefangen bei den Objekten, die bei jedem Upgrade auffallen
- Stolperfalle
- Es entsteht eine Liste ohne Termine. Eine Liste ohne Termine ist Dokumentation des Problems und keine Bearbeitung davon.
Modifikationen und implizite Erweiterungen
- Wer entscheidet
- Ausschließlich die technische Leitung, als benannte Ausnahme mit Ablaufdatum, nicht das Team unter Termindruck
- Wer setzt um
- Die Entwicklung, mit einer Begründung im selben Änderungsvorgang, in dem der Eingriff entsteht
- Stolperfalle
- Die Ausnahme wird mündlich erteilt. Ein halbes Jahr später erinnert sich niemand daran, und beim Upgrade steht das Team vor einer Änderung, für die es keinen Anlass mehr findet.
Eigene Objekte, die andere Teams benutzen sollen
- Wer entscheidet
- Das Team, dem das Objekt gehört, gemeinsam mit der Architektur, weil eine Freigabe eine Zusage über die Zeit ist
- Wer setzt um
- Das besitzende Team, mit einer bewusst schmal gehaltenen Schnittstelle statt eines offenen Zugriffs auf alles im Paket
- Stolperfalle
- Andere Teams greifen einfach auf interne Objekte zu, weil sie im selben System liegen. Damit habt ihr das Problem, das Clean Core gegenüber SAP löst, im eigenen Haus nachgebaut.
Vier Level, zwei Wege, eine Frage vor dem Bau
- 01 Level A: ausschließlich öffentlich freigegebene, stabile SAP-Schnittstellen mit Stabilitätszusage.
- 02 Level B: zusätzlich klassische SAP-APIs, damit weiter weg von der Stabilitätszusage.
- 03 Level C: Zugriff auf SAP-interne Objekte, gilt als nur teilweise konform.
- 04 Level D: nicht empfohlen, also Modifikationen, schreibende Zugriffe auf SAP-Tabellen, implizite Erweiterungen.
- 05 Quer dazu: Side-by-Side auf SAP BTP oder On-Stack mit ABAP Cloud im System selbst.
Danach hat jede Erweiterung eine Stufe, und die Stufe steht vorher fest
Clean Core ist keine Technik, sondern eine Entscheidungsordnung. SAP nennt als Ziel, den Kern standardnah und upgradestabil zu halten und den Unterschied dort zu bauen, wo er das Geschäft wirklich unterscheidet. Diese sechs Punkte sind das, was ihr dafür im Haus regeln müsst.
Die vier Level benennen können
Level A nutzt ausschließlich öffentlich freigegebene, stabile SAP-Schnittstellen mit Stabilitätszusage. Level B nutzt zusätzlich klassische SAP-APIs. Level C greift auf SAP-interne Objekte zu und gilt als nur teilweise konform. Level D umfasst die nicht empfohlenen Techniken. Mit diesen vier Begriffen ist jede Diskussion über eine Erweiterung führbar.
Die Stufe vor dem Bau festlegen
Die Frage nach dem Level gehört in die Anforderung und nicht in die Abnahme. Wer sie nachträglich stellt, bekommt eine Rechtfertigung statt einer Entscheidung, denn zu diesem Zeitpunkt ist der Code bereits geschrieben und der Termin bereits zugesagt.
Side-by-Side und On-Stack als zweite Achse behandeln
SAP unterscheidet zwei Wege: Side-by-Side auf der SAP Business Technology Platform, also entkoppelte Anwendungen außerhalb des Kerns, und On-Stack mit ABAP Cloud, also eng integrierte, upgradestabile Erweiterungen im ERP-System selbst. Das ist eine eigene Frage, nicht dieselbe wie die nach dem Level.
Ausnahmen mit Ablaufdatum versehen
Es wird Fälle geben, in denen eine niedrigere Stufe die einzige Antwort ist, die zum Termin passt. Das ist vertretbar, solange die Ausnahme benannt, begründet und mit einem Datum versehen ist, an dem jemand sie wieder aufmacht. Ohne Datum ist es keine Ausnahme, sondern eine Entscheidung.
Den Bestand einsortieren, statt ihn zu bewerten
Eine vollständige Bewertung aller Altobjekte ist ein eigenes Vorhaben und blockiert die laufende Arbeit. Die Einsortierung nach Level dagegen ist eine Fleißaufgabe mit klarem Ende und liefert das, was du für die Schätzung des nächsten Upgrades brauchst.
Den Releasetakt in die Planung nehmen
Seit dem Release SAP S/4HANA 2023 gilt ein Zweijahresrhythmus für die Hauptreleases mit sieben Jahren Wartung je Release, dazu Feature Packs, die in den ersten beiden Jahren eines Release halbjährlich geplant sind. Erweiterungen, die jedes Mal Arbeit machen, machen sie in diesem Takt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum aus drei Ebenen vier Level wurden
Das ältere Modell unterschied Erweiterungen in drei Ebenen und ist über Jahre in Vorträgen, Blogbeiträgen und Konzepten benutzt worden. SAP hat es weiterentwickelt: Um Entscheidungen über Erweiterbarkeit zu klären und die Kriterien zu vereinfachen, ist daraus das Clean-Core-Level-Konzept mit vier Stufen geworden, veröffentlicht am 12. August 2025. Für die tägliche Arbeit ist das kein Etikettenwechsel, denn die neuen Stufen ordnen anders als die alten Ebenen: Sie beschreiben, wie nah eine Erweiterung an einer Zusage über Stabilität liegt.
Das ist der eigentliche Gedanke dahinter. Eine Erweiterung ist nicht deshalb gut, weil sie technisch elegant ist, sondern weil man weiß, was mit ihr beim nächsten Upgrade passiert. Wer ausschließlich öffentlich freigegebene, stabile Schnittstellen mit Stabilitätszusage benutzt, hat eine Aussage darüber. Wer auf ein SAP-internes Objekt zugreift, hat keine, denn interne Objekte dürfen sich ändern, ohne dass das jemand ankündigt. Das ist keine Schikane, es ist die Bedingung dafür, dass sich der Standard überhaupt weiterentwickeln lässt.
SAP nennt für Clean Core drei Zwecke, und sie erklären, warum das Thema jetzt und nicht irgendwann auf den Tisch kommt: Innovationszyklen beschleunigen, technische Schulden begrenzen, Wartung und Upgrades vereinfachen. Das Ziel formuliert SAP selbst schlicht, nämlich den Kern sauber, standardnah und upgradestabil zu halten und trotzdem geschäftsspezifische Unterschiede dort zu ermöglichen, wo sie zählen. Der zweite Teil des Satzes wird beim Zitieren gern weggelassen, und genau er ist der Grund, warum Clean Core kein Verbot ist.
Die vier Level, und was sie beim Upgrade bedeuten
Level A ist die Stufe, auf der eine Erweiterung ausschließlich öffentlich freigegebene, stabile SAP-Schnittstellen mit einer Stabilitätszusage benutzt. Das ist der Zustand, in dem ein Upgrade an dieser Erweiterung im Regelfall nichts zu tun hat. Level B nutzt zusätzlich klassische SAP-APIs, ist also weiterhin ein vorgesehener Weg, liegt aber weiter weg von der Zusage. In der Praxis ist Level B das, was in vielen Häusern realistisch erreichbar ist, und schon das ist ein deutlicher Unterschied zum heutigen Zustand.
Level C beschreibt Erweiterungen, die auf SAP-interne Objekte zugreifen, und gilt deshalb als nur teilweise konform. Solche Erweiterungen funktionieren, sie tragen aber das Risiko, dass ein Upgrade sie ohne Vorwarnung trifft. Level D schließlich fasst die nicht empfohlenen Techniken zusammen: Modifikationen am Standard, schreibende Zugriffe auf SAP-Tabellen und implizite Erweiterungen. Das sind die Objekte, die in jedem Upgrade Arbeit machen und die den Aufwand einer Modernisierung im Wesentlichen bestimmen.
Für die Planung ist die Einsortierung wichtiger als die Bewertung. Wenn du weißt, dass von dreihundert eigenen Objekten zwanzig auf Level D und siebzig auf Level C liegen, kannst du den Aufwand für das nächste Upgrade zum ersten Mal begründet schätzen. Und du hast eine Reihenfolge: Nicht das komplizierteste Objekt zuerst, sondern das, das bei jedem einzelnen Upgrade wieder auffällt. Diese Reihenfolge liefert nach zwei Releases sichtbaren Nutzen, während eine nach technischer Eleganz sortierte Liste nach zwei Jahren immer noch bei Punkt drei steht.
Side-by-Side oder On-Stack: die zweite Achse
Neben der Frage nach dem Level steht eine zweite, die damit oft verwechselt wird. SAP unterscheidet zwei Wege der Erweiterung. Side-by-Side bedeutet, dass eine Anwendung auf der SAP Business Technology Platform entsteht, also entkoppelt und unabhängig vom Kern läuft. On-Stack bedeutet Erweiterung mit ABAP Cloud, also eng integriert und upgradestabil im ERP-System selbst. Beides kann auf einem hohen Level liegen, und beides kann schlecht gemacht werden.
Die Wahl hängt an drei Fragen. Wie eng liegt die Erweiterung an den Daten, wie viel Verkehr entsteht zwischen ihr und dem Kern, und wer betreibt sie später? Eine Prüfung, die bei jeder Belegposition greifen muss, gehört näher an die Daten. Eine Anwendung mit eigener Oberfläche für einen Kreis von Nutzern, die selten mit dem Kern spricht, ist ein Kandidat für den entkoppelten Weg. Der Betrieb ist die Frage, die am häufigsten vergessen wird, denn eine Anwendung auf der Plattform hat einen eigenen Lebenszyklus, eigene Überwachung und eigene Kosten.
Was du vermeiden willst, ist die Entscheidung nach Verfügbarkeit. Wenn eine Anwendung auf der Plattform entsteht, weil dort gerade jemand Zeit hatte, oder im ABAP-Stack, weil das Team nichts anderes kennt, dann steht sie danach an der falschen Stelle. Der Umzug ist in beide Richtungen kein Umzug, sondern ein Neubau, und deshalb gehört diese Frage vor die erste Zeile Code.
Was freigegeben technisch bedeutet
Der Begriff ist präziser, als er klingt. Freigegeben heißt nicht öffentlich zugänglich, sondern mit einem Release-Kontrakt versehen, in der Regel dem Kontrakt C1. Ein solcher Kontrakt ist die Zusage, dass sich dieses Objekt in einer bestimmten Weise verhält und nicht ohne Weiteres geändert wird. ABAP Cloud setzt genau darauf auf: Der Zugriff ist auf Objekte beschränkt, die als freigegebene API klassifiziert sind, und zusätzlich bleiben Objekte im selben Softwarepaket zugänglich.
Der letzte Halbsatz ist wichtig, weil er ein verbreitetes Missverständnis auflöst. In ABAP Cloud ist nicht alles verboten, was nicht von SAP kommt. Eure eigenen Objekte in eurem eigenen Paket sind nutzbar wie eh und je. Die Einschränkung betrifft den Zugriff auf fremde Objekte, und sie ist der Grund, warum eine Erweiterung überhaupt eine Aussage über ihr Verhalten beim Upgrade treffen kann.
Für die Arbeit im Team folgt daraus eine Regel, die einfacher ist als jedes Konzept: Wenn ein benötigtes SAP-Objekt nicht freigegeben ist, ist das eine Entscheidung und kein Detail. Sie wird ausgesprochen, sie wird begründet, und sie wird am Objekt notiert. Wer das durchhält, hat nach einem Jahr eine belastbare Liste dessen, was beim nächsten Upgrade Aufmerksamkeit braucht, ohne dafür je ein eigenes Vorhaben aufgesetzt zu haben.
Wie ihr anfangt, ohne das laufende Geschäft zu blockieren
Der übliche Fehler ist der große Wurf: eine vollständige Bewertung aller Eigenentwicklungen, ein Konzept, eine Richtlinie, eine Präsentation. Das dauert Monate, bindet die Leute, die währenddessen keine Anforderungen umsetzen, und endet mit einem Dokument, das im nächsten Termindruck nicht befragt wird. Der kleinere Anfang wirkt schneller: Ab heute bekommt jede neue Anforderung ein Level, bevor sie gebaut wird. Das kostet zehn Minuten je Anforderung und verändert die Richtung sofort.
Der zweite Schritt ist die Einsortierung des Bestands, und zwar bewusst grob. Es geht nicht darum, jedes Objekt zu bewerten, sondern darum, es einer der vier Stufen zuzuordnen. Diese Arbeit hat ein Ende, sie lässt sich auf mehrere Leute verteilen, und sie liefert genau die Zahl, die für die Planung fehlt. Wer danach fragt, wie teuer das nächste Upgrade wird, bekommt zum ersten Mal eine Antwort, die auf etwas beruht.
Der dritte Schritt ist der Takt. Seit dem Release SAP S/4HANA 2023 gilt ein Zweijahresrhythmus für die Hauptreleases, jedes Release bleibt sieben Jahre in der Mainstream Maintenance, und in den ersten beiden Jahren eines Release sind Feature Packs halbjährlich geplant. In diesem Rhythmus arbeitet ihr, ob ihr wollt oder nicht, und Erweiterungen auf den unteren Stufen machen in genau diesem Rhythmus Arbeit. Wer eine Handvoll davon je Release ablöst, ist nach drei Releases an einem anderen Ort, ohne je ein Modernisierungsvorhaben aufgesetzt zu haben.
Dazu passende Kurse
Weil sich die Stufen nur einhalten lassen, wenn das Team die vorgesehenen Wege sicher beherrscht, sind ABAP-Kurse mit Blick auf upgradestabile Erweiterungen der Unterbau für jede Clean-Core-Regelung.
Und weil die Stufe einer Erweiterung immer auch eine fachliche Entscheidung ist, gehören SAP-Kurse für das Zusammenspiel von Fachbereich und Entwicklung in dieselbe Planung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Bedeutet Clean Core, dass wir gar nicht mehr entwickeln dürfen?
Wir haben ein Konzept mit drei Erweiterungsebenen. Ist das noch gültig?
Was ist der Unterschied zwischen Level C und Level D?
Woran erkennen wir, ob ein Objekt freigegeben ist?
Müssen wir jetzt alle Eigenentwicklungen umbauen?
Quellen
- SAP News: Extend SAP S/4HANA Cloud the Right Way (Clean-Core-Level)
- SAP: ABAP Cloud, das Entwicklungsmodell für clean-core-konforme Erweiterungen
- SAP: ABAP Versions and APIs (ABAP-Schlüsselwortdokumentation)
- SAP: Released APIs (ABAP-Schlüsselwortdokumentation)
- SAP News: neue Release- und Wartungsstrategie für SAP S/4HANA
Passt thematisch dazu
Bevor die erste neue Erweiterung entsteht, will der Altbestand eingeordnet sein, und wie die Einstufung des vorhandenen ABAP-Bestands gelingt, ohne jede Zeile zu lesen, beschreibt der Programmierbereich.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Erweiterungen so bauen, dass das nächste Upgrade sie nicht anfasst
Wie eine upgradestabile Erweiterung aussieht und wo im eigenen Code die Stellen sitzen, die beim nächsten Release Arbeit machen, arbeitest du bei cmt an echten Objekten durch.