Konzeptkarte

Clean-Core-Prinzip

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Clean-Core-Prinzip?

Clean Core ersetzt 5.000–50.000 Zeilen ABAP-Anpassungen im Kern durch drei Erweiterungsmodelle (70 % Key-User, 25 % Entwickler, 5 % Side-by-Side), die außerhalb des Kerns leben.

Clean Core ist die architektonische Disziplin, die eine S/4HANA-Landschaft (und, in der Erweiterung, eine Business-Data-Cloud-Landschaft) upgradefähig hält, ohne dass jedes Mal, wenn SAP ein Release ausliefert, ein mehrmonatiges Regressionsprojekt nötig wird. Das Prinzip ist einfach zu formulieren und schwer durchzusetzen: Nichts, was der Kunde baut, soll von SAP gelieferte Objekte verändern, und alles Kundenspezifische soll in einer klar getrennten Erweiterungsschicht leben, die SAPs Release-Prozess nicht berührt. Für einen Berater ist Clean Core weniger eine Technologie als eine Governance-Haltung — der Unterschied zwischen einer Landschaft, die vierteljährliche Upgrades als Routinewartung behandelt, und einer, die sie als gefürchtetes, teures Ereignis behandelt.

Was es ist und warum es wichtig ist

Bevor Clean Core zur Doktrin wurde, hatte der typische ECC-Kunde über Jahre kundenspezifisches ABAP angehäuft, das direkt innerhalb oder neben dem SAP-Namensraum saß — modifizierte Standardprogramme, angehängte Tabellen, User-Exits, die durch die Kernlogik gefädelt waren. Eine solche Landschaft konnte leicht fünftausend bis fünfzigtausend Zeilen kundenspezifischen Code tragen, der so eng an den Kern gekoppelt war, dass jedes Quartalsrelease Regressionstests erzwang und nicht selten Patches oder regelrechtes Refactoring erforderte, bevor das Upgrade fortschreiten konnte. Diese Kopplung ist der mit Abstand größte Grund, warum S/4HANA- und BW-Modernisierungsprojekte lange dauern: Die Migration wird nicht durch die neue Plattform blockiert, sondern dadurch, das zu entwirren, was Kunden oben auf der alten aufgebaut haben.

Warum es zählt

Keine Änderung an von SAP geliefertem Code oder Tabellen ist die erste von fünf Invarianten — die Regel, die vierteljährliche Upgrades von mehrmonatigen Regressionsprojekten zu Routine-Cloud-Ereignissen macht.
70 % der typischen Erweiterungen passen in die Key-User-Erweiterbarkeit ohne Code und ohne Transporte — die meisten „Custom-Requirement"-Tickets brauchen überhaupt keinen Entwickler.
Side-by-Side-First als Standardleitlinie bedeutet: im Zweifel die Erweiterung nach BTP schieben statt in den Kern — die Rückfallentscheidung, die jeder Architekt vorab vereinbart haben muss.

Kernpunkte

Drei Erweiterungsmodelle: Key-User (70 %) · Entwickler-RAP (25 %) · Side-by-Side-BTP (5 %).
Fünf Invarianten: keine Änderungen am SAP-Namensraum · nur Kunden-Namensräume · nur freigegebene APIs · Side-by-Side zuerst · Disziplin bei vierteljährlichen Upgrades.
Aufteilung des Legacy-Code-Refactorings: 60-80 % abschalten · 15-25 % migrieren · 5-10 % neu gestalten.
Upgrade-Kosten vor Clean Core: 5-15 Mio. € / 6-18 Monate. Danach: ~0 € / 2-Wochen-Regressionszyklus.
Break-even nach einer Refactoring-Investition von 2-10 Mio. €: 18-30 Monate.
Datasphere-CDS-Views (C032) sind Clean-Core-konform — Analytics hängt upstream von Clean Core ab.
Brownfield-Migration (C034) erbt Legacy-Schulden; Greenfield (C035 hybrid) startet sauber.
30-50-fache Reduktion des Upgrade-Overheads über 5 Jahre bei Clean-Core-konformen Tier-1-Kunden.
Das Clean-Core-Prinzip ist erst beherrscht, wenn es eine benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.

Begriffe auf dieser Seite

Clean Core: SAP-Architekturprinzip, wonach S/4HANA-Upgrades reibungslos bleiben müssen — Erweiterungen AUSSERHALB des Kerns, Konfiguration statt Modifikation.
Key-User-Erweiterbarkeit: No-Code-Erweiterung über Fiori-UI-Tools — kundenspezifische Felder, Formulare, einfache Apps. 70 % der Erweiterungsfälle.
Entwickler-Erweiterbarkeit (RAP): ABAP RESTful Application Programming in Kunden-Namensräumen mit strikten Verträgen über freigegebene APIs. 25 % der Fälle.
Side-by-Side-Erweiterung: Vollständige App auf BTP (Cloud Foundry, Kyma), die SAP über OData/Events konsumiert. Maximale Entkopplung. 5 % der Fälle.
Kunden-Namensraum: Z*-, Y*- oder vom Kunden registrierte Namensräume, in denen kundenspezifischer Code lebt. Änderungen am SAP-Namensraum sind verboten.
Freigegebene API: Stabile, versionierte API, deren Pflege SAP über Releases hinweg zusagt. Kundenspezifischer Code konsumiert nur freigegebene APIs.
Brownfield-Bremse: Kosten des Erbens von Legacy-ABAP-im-Kern während der S/4-Migration — typischerweise 2-10 Mio. € Refactoring.
Disziplin bei vierteljährlichen Upgrades: Clean-Core-Praxis, jedes S/4-Cloud-Release innerhalb von 2 Wochen Regressionstests zu absorbieren, ohne Auslassen.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →