{"id":2834,"date":"2026-07-23T08:53:42","date_gmt":"2026-07-23T06:53:42","guid":{"rendered":"https:\/\/secat.de\/?p=2834"},"modified":"2026-07-23T08:54:13","modified_gmt":"2026-07-23T06:54:13","slug":"von-tier-1-3-zu-level-a-d-das-neue-clean-core-level-modell-verstehen","status":"publish","type":"post","link":"https:\/\/secat.de\/1\/von-tier-1-3-zu-level-a-d-das-neue-clean-core-level-modell-verstehen\/","title":{"rendered":"Von Tier 1\u20133 zu Level A\u2013D: Das neue Clean-Core-Level-Modell verstehen"},"content":{"rendered":"\n

Wer sich in den letzten Jahren mit Clean Core besch\u00e4ftigt 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 \u2013 wer bereits nach Tier-1-Prinzipien entwickelt, ist automatisch auf dem richtigen Kurs. Das neue Modell \u00e4ndert nicht die Richtung, sondern bringt deutlich mehr Granularit\u00e4t dorthin, wo die meisten Bestandssysteme heute stehen: ins Classic ABAP.<\/p>\n\n\n\n

Warum ein neues Modell?<\/h2>\n\n\n\n

Das alte Tier-Modell war im Kern eine bin\u00e4re Entscheidung: sauber oder nicht sauber. F\u00fcr Neuentwicklungen funktioniert das gut. F\u00fcr ein gewachsenes System mit tausenden Z-Objekten ist es aber wenig hilfreich, wenn 80 Prozent des Codes pauschal in \u201eTier 3″ landen \u2013 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\u00f6glicht damit eine schrittweise Transformation im eigenen Tempo.<\/p>\n\n\n\n

Level A: Der Zielzustand<\/h2>\n\n\n\n

Level A umfasst die saubersten Erweiterungen \u2013 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\u00dflich freigegebene APIs und Erweiterungspunkte genutzt, f\u00fcr die SAP Stabilit\u00e4tszusagen gibt. Fehlt eine ben\u00f6tigte API, kommt das bew\u00e4hrte Wrapper-Konzept zum Einsatz \u2013 die Kapselung des nicht freigegebenen Zugriffs hinter einer eigenen Schnittstelle bleibt der saubere \u00dcbergangspfad. Level-A-Erweiterungen sind maximal upgrade-stabil und Public-Cloud-ready.<\/p>\n\n\n\n

Level B: Classic ABAP nach den Regeln<\/h2>\n\n\n\n

Level B ist neu \u2013 und f\u00fcr 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.<\/p>\n\n\n\n

Level C: Bedingt sauber \u2013 mit Pr\u00fcfpflicht<\/h2>\n\n\n\n

Level C enth\u00e4lt Erweiterungen, die auf beliebige SAP-interne Objekte zugreifen \u2013 also das, was in gewachsenen Systemen den L\u00f6wenanteil ausmacht: direkte Selects auf SAP-Tabellen, Aufrufe nicht freigegebener Bausteine. Der interessante Punkt: Diese Objekte gelten als \u201econditionally clean“, wenn vor jedem Release-Upgrade dedizierte Pr\u00fcfungen gegen die \u00c4nderungshistorie der genutzten SAP-Objekte laufen. Aus einem diffusen Risiko wird damit ein kontrollierter Prozess \u2013 vorausgesetzt, man wei\u00df, welche Objekte betroffen sind.<\/p>\n\n\n\n

Level D: Der eigentliche Handlungsbedarf<\/h2>\n\n\n\n

Level D ist nicht Clean Core. Hier liegen Erweiterungen mit schweren Verst\u00f6\u00dfen gegen die SAP-Entwicklungsempfehlungen: Modifikationen am Standard, nicht empfohlene Objekte und abgek\u00fcndigte Erweiterungstechnologien. Das ist der Bereich, der bei jedem Upgrade zuverl\u00e4ssig Aufwand und Fehler produziert \u2013 und auf den sich eine Clean-Core-Roadmap zuerst konzentrieren sollte.<\/p>\n\n\n\n

Was hei\u00dft das praktisch?<\/h2>\n\n\n\n

F\u00fcr Neuentwicklungen bleibt die Regel einfach: Level A zuerst, BTP-first wo sinnvoll, Wrapper wo APIs fehlen. F\u00fcr den Bestand ver\u00e4ndert das Modell die Rechnung grundlegend: Statt \u201ealles muss irgendwann nach ABAP Cloud“ lautet die Aufgabe jetzt, D-Objekte gezielt abzul\u00f6sen, C-Objekte in einen kontrollierten Pr\u00fcfprozess zu \u00fcberf\u00fchren und B-Objekte schlicht sauber zu halten. Das ist deutlich realistischer \u2013 setzt aber voraus, dass man wei\u00df, wie sich der eigene Custom Code auf die vier Levels verteilt.<\/p>\n\n\n\n

Sie m\u00f6chten wissen, wie Ihr Custom Code auf die Levels A\u2013D verteilt ist? Mit unserem Clean-Core-Assessment schaffen wir in wenigen Tagen Transparenz \u2013 sprechen Sie uns an.<\/em><\/p>\n\n\n\n

Quellen<\/h2>\n\n\n\n