Clean Core Strategie erfolgreich umsetzen: Ein Deep Dive in das A-D Extensibility Modell.

Die Architektur von Unternehmenssoftware durchläuft einen fundamentalen Wandel. Historisch gewachsene ERP-Landschaften zeichnen sich durch tiefgreifende, monolithische Strukturen aus. Kundenindividueller Code greift häufig in Form von Modifikationen oder User Exits direkt und ungeschützt in den Kern des Systems ein. Diese über Jahrzehnte übliche Praxis führt heute zu erheblicher technischer Schuld, bremst die Agilität von Unternehmen, und macht Systemupgrades komplex und kostenintensiv. Um in einem dynamischen Marktumfeld wettbewerbsfähig zu bleiben, ist die Umsetzung einer Clean Core Strategie unerlässlich. Diese fordert eine strikte technologische Entkopplung von Standardsoftware und individuellen Anpassungen. Unser erster Beitrag dieser dreiteiligen Blogreihe richtet sich gezielt an Enterprise Architekten, leitende SAP-Entwickler und IT-Strategen, die eine performante, wartbare und zukunftssichere Systemlandschaft konzipieren möchten.

Clean Core Strategie im SAP Kontext

Der Begriff des „sauberen Kerns“ wird in der globalen Entwicklergemeinschaft intensiv diskutiert und oft missverstanden. Kundenindividueller Code muss nicht vollständig vermieden werden. „Clean Core“ bedeutet Erweiterung technologisch so zu entkoppeln und zu standardisieren, dass der eigentliche SAP-Standard unangetastet bleibt. Dadurch lassen sich künftige Releases ohne manuellen Anpassungsaufwand einspielen. Das Ziel ist es, Upgrades reibungslos zu gestalten, Altlasten abzubauen und neue Technologien wie Künstliche Intelligenz nahtlos zu integrieren. Für einen dauerhaft effizienten Betrieb stützt sich dieses Architekturkonzept auf fünf Kernprinzipien: durchgängige Prozesse, nahtlose Integration, verlässliche Datenqualität, effiziente Operations und eine standardisierte Erweiterbarkeit.

Im Bereich der Erweiterbarkeit hat die SAP ihre Vorgaben zuletzt stark an die Realität historisch gewachsener Systeme angepasst. Ursprünglich wurde der Entwickler-Community ein striktes Drei-Tier-Modell vorgegeben. Dieses unterschied zwischen Cloud-konformen Erweiterungen (Tier 1), Brückenlösungen (Tier 2) und klassischen, modifizierenden Anpassungen (Tier 3). Dieses binäre System aus „erlaubt“ und „verboten“ erwies sich jedoch in der Migrationspraxis als viel zu restriktiv. Als Lösung führt die SAP ein differenziertes Modell mit vier Leveln ein, das die Kompatibilität von Erweiterungen wesentlich granularer bewertet und einen realistischeren Transformationspfad aufzeigt.

Das Clean Core A-D Extensibility Modell

Das sogenannte A-D Extensibility Modell klassifiziert den individuellen Code anhand seiner technischen Umsetzung und der genutzten Schnittstellen in folgende vier Kategorien beziehungsweise Stufen:

• Level A (ABAP Cloud Readiness): Die sauberste Form der Erweiterung nutzt exklusiv offiziell freigegebene SAP-APIs sowie das ABAP Cloud Entwicklungsmodell. Diese Stufe garantiert höchste Upgrade-Stabilität ohne manuellen Anpassungsaufwand und ist vollständig Cloud-ready.

• Level B (Classic SAP APIs): Auf dieser Ebene nutzt der Code klassische, gut dokumentierte SAP-APIs wie BAPIs oder freigegebene BADIs und folgt den etablierten Best Practices für die klassische ABAP-Entwicklung. Diese Stufe bietet eine sehr hohe Stabilität, erfordert bei Upgrades in der Regel nur marginale funktionale Prüfungen und gilt im Rahmen von Private Cloud Deployments oder On-Premise-Szenarien als valide und zukunftssichere Basis.

• Level C (Unreleased SAP Objects): Diese Stufe umfasst die Nutzung interner SAP-Objekte, die nicht offiziell für Kunden freigegeben wurden. Die Stabilität ist hier nur bedingt gegeben, da vor jedem Upgrade eine zwingende technische Verifizierung der genutzten Objekte über das Changelog erforderlich ist.

• Level D (Modifications & Technical Debt): Diese kritische Stufe umfasst die Nutzung explizit nicht empfohlener Objekte, direkte Kernmodifikationen des SAP-Standards oder veraltete, invasive Techniken wie implizite Enhancements. Code auf diesem Level erzeugt massive technische Schulden, verhindert reibungslose Upgrades und muss im Rahmen der Transformation zwingend in höhere Level refaktoriert werden.

Die rein theoretische Definition dieser vier Level reicht für eine erfolgreiche und nachhaltige Architektur-Transformation jedoch bei Weitem nicht aus. Es bedarf einer strengen Governance, um sicherzustellen, dass Entwicklungsteams diese Leitplanken im Arbeitsalltag konsequent einhalten. Die technische Einhaltung dieser strikten Vorgaben wird durch das ABAP Test Cockpit (ATC) unterstützt, welches den Code automatisiert auf seine ABAP Cloud Readiness prüft und detaillierte Fehler oder Warnungen ausgibt, sobald ein Entwickler den im System definierten Clean Core Standard verlässt. Um Entwicklern den Übergang zu erleichtern, stellt die SAP den SAP Extensibility Explorer sowie das Cloudification Repository zur Verfügung. So können Sie bereits in der Designphase freigegebene Schnittstellen identifizieren und neue Erweiterungen direkt konform zu Level A entwickeln.

Herausforderungen in der Umsetzung

Trotz dieser klaren strategischen Ausrichtung gibt es in der realen Projektpraxis weiterhin erhebliche Herausforderungen. Die Deutschsprachige SAP-Anwendergruppe (DSAG) hat diese kritische Situation bereits auf den Technologietagen 2025 unter dem Motto „Strategy Royale: Call, Raise or Fold?“ intensiv diskutiert. Die mit Abstand größte technische Hürde bei der Umsetzung der Clean Core Paradigmen ist derzeit die mangelnde Verfügbarkeit von Level-A-kompatiblen, freigegebenen Schnittstellen.

Wie sich diese theoretischen Vorgaben in der Praxis umsetzen lassen und welche Kriterien die architektonische Entscheidung zwischen On-Stack-Erweiterungen und Side-by-Side-Bereitstellungen beeinflussen, beleuchten wir im zweiten Teil dieser Blogreihe.

Gehen Sie den nächsten Schritt

Eine fundierte Entscheidung bildet hier das Rückgrat Ihrer digitalen Transformation. Unser Expertenteam begleitet Sie gerne bei der strategischen Neuausrichtung Ihrer Systemlandschaft. Wir führen tiefgreifende Code-Analysen Ihres S/4HANA-Systems mittels ATC durch und erarbeiten einen belastbaren Refactoring-Plan, um Ihre historischen Modifikationen sicher in die Level A und B zu überführen. Nehmen Sie Kontakt mit uns auf, um Ihre individuelle Roadmap für einen Clean Core zu definieren.