SAP-Wiki

Clean Core

Clean Core bezeichnet das Prinzip, den SAP-Standardkern von SAP S/4HANA unverändert zu lassen und eigene Anpassungen außerhalb des Kernsystems umzusetzen, etwa über freigegebene APIs oder auf SAP BTP. Updates, Release-Wechsel und der Schritt in die Cloud werden dadurch planbar, weil Erweiterungen den Kern nicht blockieren.

Definition

Was ist Clean Core?

Der Begriff stammt aus der S/4HANA-Cloud-Strategie von SAP und beschreibt die Trennung von Standardsoftware und individuellen Erweiterungen. Modifikationen direkt im Coding des SAP-Systems verschwinden zugunsten von Erweiterungen über offizielle Schnittstellen wie die SAP BTP ABAP Environment oder freigegebene APIs aus dem Extensibility-Guide. Ziel ist ein Kern, der bei jedem Release-Wechsel unverändert bleibt, sich automatisiert testen lässt und ohne größeren Aufwand auf neue SAP-Versionen zieht.

Relevant ist Clean Core für jedes Unternehmen, das auf SAP S/4HANA wechselt oder bereits produktiv läuft, besonders in der Public Cloud, wo Modifikationen am Kern technisch ausgeschlossen sind. In der Private Cloud und im On-Premise-Betrieb bleibt Clean Core eine Empfehlung statt einer Pflicht, wird aber bei jedem Release-Wechsel und jedem Wechsel des Betriebsmodells zum Kostenfaktor. IT-Leitung und Entwicklung tragen die Verantwortung gemeinsam.

In der Praxis beginnt die Umstellung mit einer Custom-Code-Analyse, die bestehende Eigenentwicklungen nach ihrer Kernnähe bewertet. Was sich nicht über freigegebene APIs abbilden lässt, wandert in ein Side-by-side-Szenario auf SAP BTP oder wird über die In-App-Extensibility umgesetzt. Häufig unterschätzt wird der Abstimmungsaufwand mit dem Fachbereich, der auf eine liebgewonnene Eigenentwicklung nur ungern verzichtet, obwohl der SAP-Standard die Anforderung inzwischen abdeckt.

Funktionen

Wie funktioniert Clean Core?

Technisch setzt Clean Core auf ein Konzept freigegebener Erweiterungspunkte: Business Add-Ins, Customer Fields, released APIs und Events, die SAP im Extensibility-Guide pro Anwendung dokumentiert. Eigenentwicklungen laufen entweder in-app innerhalb des S/4HANA-Systems oder side-by-side auf SAP BTP, angebunden über die SAP Integration Suite. Der SAP-Kern selbst bleibt frei von kundenspezifischem Coding, wodurch Regressionstests bei Updates entfallen oder sich auf die Erweiterungsschicht konzentrieren.

Im Zusammenspiel mit SAP BTP übernimmt die Plattform Integration, Datenflüsse und eigene Anwendungen, während S/4HANA für die Kernprozesse zuständig bleibt. Schnittstellen laufen über dokumentierte APIs statt über direkte Tabellenzugriffe, was Versionssprünge und einen Wechsel des Betriebsmodells absichert. Der Custom Code Migration Check innerhalb der SAP-Werkzeuge zeigt, wie viel Altlast noch im System steckt.

Vorteile

Updates ohne Angst

Release-Wechsel laufen ohne aufwendige Regressionstests am Kern, weil Eigenentwicklungen außerhalb liegen.

Cloud-Wechsel offen

Wer sauber erweitert, kann später zwischen Private Cloud, Public Cloud und On-Premise wechseln, ohne Coding neu zu schreiben.

Governance sichtbar

Der Extensibility-Guide macht nachvollziehbar, welche Erweiterung erlaubt ist und welche technischen Schulden sie erzeugt.

Wartung planbar

Weniger Modifikationen bedeuten weniger Aufwand bei jedem Support Package und jedem Upgrade-Projekt.

Prüfbar durch SAP

Der Custom Code Migration Check zeigt objektiv, wie kernnah eine Landschaft heute aufgestellt ist.

Grenzen

Nicht kostenlos

Erweiterungen über APIs oder BTP-Anwendungen brauchen eigene Entwicklung und eigenen Betrieb. Der Aufwand verschiebt sich nur.

Nicht jede Funktion verfügbar

Manche Altfunktion aus dem SAP ECC hat noch keine freigegebene API. Dann bleibt nur Warten auf SAP oder ein bewusster Kompromiss.

Historisch gewachsene Systeme bremsen

Wer seit Jahren modifiziert hat, steht vor einer aufwendigen Aufräumphase, bevor Clean Core überhaupt greift.

Kulturfrage im Fachbereich

Ohne Rückhalt aus den Fachabteilungen bleibt jede Governance-Regel Theorie, weil Ausnahmen sich sonst wieder einschleichen.

FAQ

Häufige Fragen zu Clean Core

Ist Clean Core nur für SAP S/4HANA Public Cloud Pflicht?

Verpflichtend ist Clean Core technisch nur in der Public Cloud, weil Modifikationen am Kern dort ausgeschlossen sind. In Private Cloud und On-Premise ist es eine strategische Entscheidung, die spätere Upgrades und einen möglichen Wechsel des Betriebsmodells deutlich erleichtert.

Was passiert mit bestehenden Eigenentwicklungen?

Sie werden über eine Custom-Code-Analyse bewertet. Was sich über freigegebene APIs abbilden lässt, wandert dorthin. Der Rest läuft side-by-side auf SAP BTP oder wird stillgelegt, wenn niemand die Funktion mehr nutzt.

Lohnt sich Clean Core auch ohne Cloud-Wechsel?

Ja, weil jedes Support Package und jedes Upgrade von der reduzierten Modifikationslast profitiert. Der Effekt zeigt sich spätestens beim nächsten größeren Release-Wechsel in deutlich kürzeren Testzyklen.

Wie lange dauert die Umstellung auf Clean Core?

Das hängt von Zahl und Alter der Eigenentwicklungen ab. Eine belastbare Schätzung liefert erst die Custom-Code-Analyse, weil sie zeigt, wie viele Modifikationen tatsächlich noch aktiv genutzt werden.

Brauche ich für Clean Core zwingend SAP BTP?

Nicht für jede Erweiterung. Viele Anforderungen lassen sich in-app direkt in S/4HANA über freigegebene Erweiterungspunkte lösen. SAP BTP kommt ins Spiel, sobald eine Erweiterung eigenständig laufen soll, unabhängig vom Lebenszyklus des Kernsystems.

Ihr Kontakt

Gabriele Görtz

Head of Sales & Growth

Sprechen Sie mit uns.

Ein Erstgespräch dauert 30 Minuten. Sie können auch direkt mit einem konkreten Thema kommen. Rufen Sie an oder schreiben Sie uns.

+49 40 69 658 50-0

Anwender-Helpdesk für Bestandskunden:

0800 52388 55 (kostenfrei)