Wer sich in den letzten Jahren mit Clean Core beschäftigt hat, kennt das Drei-Tier-Extensibility-Modell. Seit dem Update des ABAP Extensibility Guide im Sommer 2025 gilt jedoch eine neue Landkarte: das Clean Core Level Concept mit den vier Stufen A bis D. Die gute Nachricht vorweg – wer bereits nach Tier-1-Prinzipien entwickelt, ist automatisch auf dem richtigen Kurs. Das neue Modell ändert nicht die Richtung, sondern bringt deutlich mehr Granularität dorthin, wo die meisten Bestandssysteme heute stehen: ins Classic ABAP.
Warum ein neues Modell?
Das alte Tier-Modell war im Kern eine binäre Entscheidung: sauber oder nicht sauber. Für Neuentwicklungen funktioniert das gut. Für ein gewachsenes System mit tausenden Z-Objekten ist es aber wenig hilfreich, wenn 80 Prozent des Codes pauschal in „Tier 3″ landen – ohne Unterscheidung, ob ein Objekt nur einen klassischen BAdI nutzt oder den SAP-Standard modifiziert. Genau diese Differenzierung liefert das Level-Modell: Es bewertet, wie nah jede einzelne Erweiterung an den Clean-Core-Prinzipien liegt, und ermöglicht damit eine schrittweise Transformation im eigenen Tempo.
Level A: Der Zielzustand
Level A umfasst die saubersten Erweiterungen – gebaut entweder on-stack mit dem ABAP-Cloud-Entwicklungsmodell direkt im S/4HANA-System oder side-by-side auf der SAP BTP, etwa mit ABAP Cloud, CAP oder Low-Code-Werkzeugen aus SAP Build. Gemeinsamer Nenner: Es werden ausschließlich freigegebene APIs und Erweiterungspunkte genutzt, für die SAP Stabilitätszusagen gibt. Fehlt eine benötigte API, kommt das bewährte Wrapper-Konzept zum Einsatz – die Kapselung des nicht freigegebenen Zugriffs hinter einer eigenen Schnittstelle bleibt der saubere Übergangspfad. Level-A-Erweiterungen sind maximal upgrade-stabil und Public-Cloud-ready.
Level B: Classic ABAP nach den Regeln
Level B ist neu – und für Bestandssysteme die vielleicht wichtigste Stufe. Hier landet klassisches ABAP, das den SAP-Entwicklungsempfehlungen folgt und die als klassische APIs angebotenen Frameworks nutzt: BAdIs, freigegebene Funktionsbausteine, dokumentierte Erweiterungstechniken. Kein ABAP Cloud, aber diszipliniert gebaut. Die Botschaft dahinter ist bemerkenswert pragmatisch: Gut gemachtes Classic ABAP ist kein Sanierungsfall. Es muss nicht zwingend migriert werden, um als weitgehend clean zu gelten.
Level C: Bedingt sauber – mit Prüfpflicht
Level C enthält Erweiterungen, die auf beliebige SAP-interne Objekte zugreifen – also das, was in gewachsenen Systemen den Löwenanteil ausmacht: direkte Selects auf SAP-Tabellen, Aufrufe nicht freigegebener Bausteine. Der interessante Punkt: Diese Objekte gelten als „conditionally clean“, wenn vor jedem Release-Upgrade dedizierte Prüfungen gegen die Änderungshistorie der genutzten SAP-Objekte laufen. Aus einem diffusen Risiko wird damit ein kontrollierter Prozess – vorausgesetzt, man weiß, welche Objekte betroffen sind.
Level D: Der eigentliche Handlungsbedarf
Level D ist nicht Clean Core. Hier liegen Erweiterungen mit schweren Verstößen gegen die SAP-Entwicklungsempfehlungen: Modifikationen am Standard, nicht empfohlene Objekte und abgekündigte Erweiterungstechnologien. Das ist der Bereich, der bei jedem Upgrade zuverlässig Aufwand und Fehler produziert – und auf den sich eine Clean-Core-Roadmap zuerst konzentrieren sollte.
Was heißt das praktisch?
Für Neuentwicklungen bleibt die Regel einfach: Level A zuerst, BTP-first wo sinnvoll, Wrapper wo APIs fehlen. Für den Bestand verändert das Modell die Rechnung grundlegend: Statt „alles muss irgendwann nach ABAP Cloud“ lautet die Aufgabe jetzt, D-Objekte gezielt abzulösen, C-Objekte in einen kontrollierten Prüfprozess zu überführen und B-Objekte schlicht sauber zu halten. Das ist deutlich realistischer – setzt aber voraus, dass man weiß, wie sich der eigene Custom Code auf die vier Levels verteilt.
Sie möchten wissen, wie Ihr Custom Code auf die Levels A–D verteilt ist? Mit unserem Clean-Core-Assessment schaffen wir in wenigen Tagen Transparenz – sprechen Sie uns an.