0800 71 20000
Kontakt
...
SAP-Eigenentwicklungen ordnen

Clean Core in S/4HANA: was aus euren ABAP-Eigenentwicklungen wird

Entkoppelt heißt nicht verboten. Die Frage ist, welche eurer Erweiterungen nur über freigegebene Schnittstellen arbeitet, welche in interne Objekte greift und welche den Standard verändert.

Passende Kurse ansehen Persönlich beraten lassen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Der Begriff kommt als Vorgabe an, und niemand weiß, was er für den eigenen Bestand bedeutet

Clean Core taucht in den meisten Häusern als Anforderung von außen auf, aus einem Projekt, einer Beratung oder einer Vorgabe der Konzern-IT. Was ankommt, ist meist eine Verkürzung: Eigenentwicklungen sind schlecht, alles muss auf die Plattform. Diese Verkürzung erzeugt zwei falsche Reaktionen. Die eine ist Abwehr, weil in den Eigenentwicklungen genau die Prozesse stecken, mit denen sich das Haus vom Wettbewerb unterscheidet. Die andere ist ein pauschales Umbauprogramm, bei dem auch Dinge angefasst werden, die längst konform sind.

Beides beruht auf demselben Missverständnis. SAP beschreibt clean core nicht als Verzicht auf Erweiterungen, sondern als Entkopplung: Eine Erweiterung soll über öffentlich freigegebene Schnittstellen mit dem Kern reden und nicht in dessen Interna greifen. Damit überlebt sie ein Upgrade, ohne dass jemand sie nachziehen muss. Der Unterschied zwischen einer erlaubten und einer problematischen Erweiterung liegt also in der Art des Zugriffs und nicht in ihrer Existenz.

Die dritte Schwierigkeit ist der Bestand selbst. In einem gewachsenen System stehen oft Tausende von Objekten im Kundennamensraum, und ein erheblicher Teil davon wird seit Jahren nicht mehr aufgerufen. Wer diese Menge ungeprüft in ein Umbauprogramm gibt, bezahlt für Objekte, die man auch hätte abschalten können. Die erste Aufgabe ist deshalb keine technische, sondern eine Bestandsaufnahme: Was existiert, was wird benutzt, und wie greift es auf den Standard zu.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was

Wer im Haus was entscheidet

Clean Core scheitert selten an der Technik. Es scheitert daran, dass Entscheidungen zwischen Fachbereich, Entwicklung und Betrieb hin und her wandern. Die folgende Aufteilung ordnet die sechs wiederkehrenden Themen jeweils einer Stelle zu und benennt, woran es in der Praxis hakt.

Ob eine bestehende Eigenentwicklung umgebaut, ersetzt oder abgeschaltet wird

Wer entscheidet
Der Fachbereich, dem der Prozess gehört, auf Grundlage der Nutzungsdaten und einer Aufwandsschätzung aus der Entwicklung
Wer setzt um
Das ABAP-Team, mit einem eigenen Auftrag je Objekt statt einem Sammelprojekt
Stolperfalle
Die Entscheidung wird an die Entwicklung delegiert, weil es technisch klingt. Ob ein Bericht noch gebraucht wird, kann die Entwicklung aber nicht beurteilen, und deshalb wird im Zweifel alles behalten.

Wo eine neue Erweiterung entsteht, im System oder daneben

Wer entscheidet
Die Architektur, entlang einer schriftlichen Regel und nicht je Vorhaben neu
Wer setzt um
Das Entwicklungsteam, im System mit dem eingeschränkten ABAP-Sprachumfang oder außerhalb auf der Plattform
Stolperfalle
Entschieden wird nach der Verfügbarkeit von Personal statt nach der Aufgabe. Dann landet eine Erweiterung im Kern, weil dort gerade jemand Zeit hat.

Zugriffe auf nicht freigegebene SAP-Objekte

Wer entscheidet
Die technische Leitung, mit einer befristeten Ausnahme statt einer dauerhaften Genehmigung
Wer setzt um
Wer den Code schreibt, mit einem Vermerk an der Stelle und einem Eintrag in einer Liste, die jemand regelmäßig durchgeht
Stolperfalle
Die Ausnahme wird erteilt und nie wieder angesehen. Ohne Datum und ohne benannte Person, die sie erneut prüft, ist eine Ausnahme faktisch eine Dauerlösung.

Modifikationen und implizite Erweiterungen im Bestand

Wer entscheidet
Die IT-Leitung, weil hier der größte Teil der Upgrade-Kosten entsteht und die Entscheidung Budget braucht
Wer setzt um
Das ABAP-Team, indem es je Fall entweder auf eine vorgesehene Erweiterungsstelle umbaut oder die Änderung zurücknimmt
Stolperfalle
Der Aufwand wird beim nächsten Upgrade sichtbar und dort als Upgrade-Kosten verbucht. Solange er nicht der verursachenden Änderung zugeordnet wird, entsteht kein Druck, ihn zu vermeiden.

Die Prüfung im Entwicklungsprozess

Wer entscheidet
Die Entwicklungsleitung, einmalig mit einer festgelegten Prüfvariante und einem Datum, ab dem sie verbindlich ist
Wer setzt um
Die Basis, indem sie die Prüfung an die Freigabe von Transportaufträgen hängt
Stolperfalle
Die Prüfung läuft, aber Verstöße lassen sich ohne Begründung übergehen. Dann ist sie eine Anzeige und keine Regel.

Welche Schnittstellen nach außen benutzt werden dürfen

Wer entscheidet
Die Integrationsarchitektur, mit einer Liste erlaubter Schnittstellen statt einer Einzelfallprüfung
Wer setzt um
Die Teams auf beiden Seiten, indem sie ausschließlich über diese Liste anbinden
Stolperfalle
Für einen dringenden Fall wird direkt auf eine Tabelle zugegriffen, weil es schneller geht. Dieser Zugriff überlebt das Projekt und taucht beim nächsten Upgrade als Ausfall wieder auf.

Vom Bestand zur Arbeitsliste

  1. 01 Wie viele Objekte liegen im Kundennamensraum, und wie viele werden noch aufgerufen?
  2. 02 Welche davon greifen auf nicht freigegebene SAP-Objekte zu?
  3. 03 Gibt es für den jeweiligen Zugriff ein freigegebenes Nachfolgeobjekt?
  4. 04 In welche Stufe von A bis D fällt die Erweiterung nach ihrer Zugriffsart?
  5. 05 Ab wann entsteht Neues nur noch entkoppelt, unabhängig vom Aufräumen im Bestand?
Was du mitnimmst

Wie ihr vom Begriff zu einer Arbeitsliste kommt

Sechs Schritte führen von der Vorgabe zu einer Liste, die sich abarbeiten lässt. Die ersten beiden liefern Zahlen, die nächsten drei ordnen den Bestand, der letzte sorgt dafür, dass die Liste nicht wieder wächst.

Erst zählen, was tatsächlich benutzt wird

Erhebt neben der Menge der Objekte im Kundennamensraum auch deren Nutzung. Ein erheblicher Teil eines gewachsenen Bestands ist tot: Berichte, die niemand mehr aufruft, Hilfsprogramme aus abgeschlossenen Projekten, Kopien von Kopien. Diese Objekte gehören nicht in ein Umbauprogramm, sondern in eine Abschaltliste, und das ist die günstigste Maßnahme überhaupt.

Die technische Prüfung als Erhebung nutzen, nicht als Urteil

Das ABAP Test Cockpit prüft mit der Variante für Cloud-Bereitschaft, welche Stellen im Code auf nicht freigegebene Objekte zugreifen. Das Ergebnis ist eine Fundliste und noch keine Bewertung: Jeder Fund braucht eine Entscheidung darüber, ob umgebaut, ersetzt oder abgeschaltet wird. Lasst die Prüfung einmal über den gesamten Bestand laufen, bevor irgendjemand mit dem Umbau anfängt.

Nachschlagen statt raten, welche Schnittstelle freigegeben ist

SAP veröffentlicht die Liste der freigegebenen Schnittstellen für SAP Cloud ERP in einem öffentlichen Repository auf GitHub, zusammen mit Angaben zu Nachfolgeobjekten für nicht freigegebene. Damit lässt sich für jeden Fund direkt beantworten, ob es einen vorgesehenen Ersatz gibt. Das erspart die Diskussion darüber, was erlaubt sein könnte.

Den Bestand nach Reifegrad einordnen statt pauschal zu bewerten

SAP hat das frühere Drei-Stufen-Modell zu einem Reifegradmodell mit den Stufen A bis D weiterentwickelt. Ordnet jede verbleibende Erweiterung einer dieser Stufen zu. Damit habt ihr eine Reihenfolge: Was in Stufe D fällt, also Modifikationen, Schreibzugriffe auf SAP-Tabellen und implizite Erweiterungen, ist der teuerste Posten beim nächsten Upgrade und gehört zuerst angefasst.

Für neue Entwicklung sofort umstellen, unabhängig vom Bestand

Der Bestand braucht Zeit, die Regel für Neues braucht sie nicht. Ab einem festgelegten Datum entsteht jede neue Erweiterung entweder im System mit dem eingeschränkten ABAP-Sprachumfang für die Cloud oder außerhalb auf der Plattform. Ohne diesen Schnitt räumt ihr hinten auf, während vorne neue Altlasten entstehen.

Die Prüfung in den Entwicklungsprozess einbauen

Eine Prüfung, die einmal im Jahr als Sonderlauf stattfindet, verändert nichts. Wirksam wird sie erst, wenn sie an der Freigabe eines Transportauftrags hängt und ein Verstoß dort auffällt, wo er entstanden ist. Das ist eine Konfigurationsaufgabe und eine Vereinbarung im Team, keine große Investition.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was clean core meint und was es ausdrücklich nicht meint

SAP beschreibt clean core als eine Art, Geschäftsprozesse und Erweiterungen so zu gestalten, dass sie standardisiert und stabil bleiben. Es geht dabei nicht nur um Code. SAP nennt mehrere Bereiche, die zusammen gemeint sind: die Geschäftsprozesse selbst, die Erweiterungen, die Daten, die Integration nach außen und der Betrieb des Systems. Ein System mit sauberem Code, aber ungepflegten Stammdaten und einem Wildwuchs an Punkt-zu-Punkt-Verbindungen erfüllt die Absicht nicht.

Für den Bereich Erweiterungen lautet die Regel: entkoppeln statt verzichten. Eine Erweiterung soll über öffentlich freigegebene Schnittstellen mit dem Kern arbeiten, für die SAP Stabilitätszusagen gibt. Damit überlebt sie ein Upgrade, ohne dass jemand sie nachziehen muss. Genau das ist der wirtschaftliche Kern der ganzen Sache: Der Aufwand eines Upgrades hängt weniger an der Menge eurer Eigenentwicklungen als an der Art, wie sie auf den Standard zugreifen.

Zwei Wege gibt es dafür. Der eine ist die Erweiterung im System selbst, mit dem eingeschränkten, cloud-optimierten ABAP-Sprachumfang, der nur freigegebene Schnittstellen zulässt. Der andere ist die Erweiterung daneben, als eigenständige Anwendung auf der SAP Business Technology Platform, die den Kern über Schnittstellen anspricht. SAP empfiehlt, bei der Wahl zuerst die Plattform zu betrachten und die Entscheidung am Anwendungsfall festzumachen. Für eine Erweiterung, die eng an einer Transaktion hängt, ist der Weg im System oft der richtige. Für eine eigenständige Anwendung mit eigener Oberfläche ist es der Weg daneben.

Vom Drei-Stufen-Modell zu den Stufen A bis D

Die frühere Beschreibung arbeitete mit drei Stufen: die eingeschränkte ABAP-Sprachversion mit freigegebenen Schnittstellen als vorgesehener Weg, eine Zwischenschicht für noch fehlende Schnittstellen und das klassische ABAP für alles andere. Dieses Modell hat SAP inzwischen zu einem Reifegradmodell mit vier Stufen weiterentwickelt, das eine Erweiterung danach bewertet, wie sie gebaut ist, wie gut sie vom Kern entkoppelt ist und wie leicht sie sich aktualisieren lässt.

Stufe A steht für vollständig konforme Erweiterungen, die ausschließlich öffentlich freigegebene und stabile Schnittstellen benutzen, gestützt auf formale Stabilitätszusagen. Stufe B umfasst Erweiterungen, die zusätzlich klassische Schnittstellen von SAP verwenden, also dokumentierte und in der Regel aktualisierungsstabile Wege. Stufe C beschreibt teilweise konforme Erweiterungen, die auf SAP-interne Objekte zugreifen, was SAP für bestehende Fälle ausdrücklich zulässt und mit angekündigten Änderungshinweisen abfedern will. Stufe D fasst zusammen, was nicht empfohlen ist: Modifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen und die ausdrücklich nicht vorgesehenen Objekte.

Der Nutzen dieser Einteilung liegt darin, dass sie eine Reihenfolge erzeugt. Nicht alles muss auf Stufe A, und der Versuch, das zu erreichen, ist in einem gewachsenen System selten wirtschaftlich. Was sich lohnt, ist der Weg heraus aus Stufe D, denn dort entstehen die Kosten beim Upgrade. Und was sich immer lohnt, ist die Regel, dass Neues in Stufe A oder B beginnt, weil eine Erweiterung, die dort startet, dort auch bleibt.

Wie ihr euren Bestand einordnet, ohne alles zu lesen

Die technische Grundlage ist das ABAP Test Cockpit mit einer Prüfvariante für Cloud-Bereitschaft. Sie meldet jede Stelle im Code, die auf ein Objekt zugreift, das nicht freigegeben ist. Ergänzend gibt es die Anwendung zur Analyse des kundeneigenen Codes, die eine Bestandsaufnahme über das ganze System erstellt und Nutzungsdaten mit einbezieht. Beide Werkzeuge liefern eine Liste, und diese Liste ist der Ausgangspunkt, nicht das Ergebnis.

Für jeden Fund braucht ihr zwei Informationen. Die erste: Gibt es ein freigegebenes Nachfolgeobjekt? SAP veröffentlicht die Liste der freigegebenen Schnittstellen in einem öffentlichen Repository, das auch Angaben zu Nachfolgern für nicht freigegebene Objekte enthält. Wenn es einen Nachfolger gibt, ist der Umbau meist eine überschaubare Änderung. Die zweite: Wird das Objekt überhaupt noch benutzt? Ein Bericht, den seit drei Jahren niemand aufgerufen hat, braucht keinen Umbau, sondern eine Abschaltung.

Aus diesen beiden Angaben entsteht eine Einteilung in vier Körbe, die sich unterschiedlich behandeln lassen: abschalten, umbauen mit vorhandenem Nachfolger, umbauen ohne Nachfolger und deshalb mit fachlicher Klärung, und bewusst so lassen mit einer dokumentierten Entscheidung. Nur der dritte Korb ist wirklich teuer, und er ist in den meisten Häusern der kleinste. Diese Aufteilung vorweg zu machen, verhindert, dass ein Umbauprogramm für den gesamten Bestand beauftragt wird.

Was die Umstellung vom Team verlangt

Der eingeschränkte ABAP-Sprachumfang ist für erfahrene Entwicklerinnen und Entwickler zunächst eine Einschränkung, und sie fühlt sich auch so an. Gewohnte Anweisungen sind nicht mehr zulässig, der direkte Zugriff auf SAP-Tabellen entfällt, und für manches gibt es zunächst keinen offensichtlichen Weg. Wer aus dem klassischen ABAP kommt, braucht eine Zeit, in der die neue Denkweise ungewohnt bleibt, und diese Zeit gehört eingeplant statt beklagt.

Was dabei hilft, ist der Blick auf das, was die Umstellung mitbringt. Objektorientierte Programmierung ist im neuen Modell nicht mehr optional, sondern die Grundlage, und dasselbe gilt für die Trennung zwischen Datenmodell, Geschäftslogik und Oberfläche. Das sind keine SAP-Besonderheiten, sondern Handwerk, das sich auch außerhalb auszahlt. Ein Team, das diese Grundlagen sicher beherrscht, findet sich im neuen Modell deutlich schneller zurecht als eines, das sie nebenbei mitlernen muss.

Organisatorisch gibt es zwei Dinge, die den Unterschied machen. Das erste ist ein Datum, ab dem Neues nur noch entkoppelt entsteht, denn ohne dieses Datum verschiebt sich die Umstellung immer auf das nächste Projekt. Das zweite ist eine benannte Person, die die Ausnahmen verwaltet: Wer eine Ausnahme erteilt, trägt sie mit Datum und Begründung ein, und jemand geht die Liste regelmäßig durch. Ohne diese Rolle wird jede Ausnahme zur Dauerlösung, und die Liste erklärt beim nächsten Upgrade den Aufwand.

Dazu passende Kurse

Wenn das Team aus dem klassischen ABAP kommt und die neue Denkweise noch ungewohnt ist, verkürzen ABAP-Schulungen für entkoppelte Erweiterungen diese Phase spürbar.

Damit Fachbereich und Entwicklung dieselbe Sprache sprechen, wenn es um Prozesse und ihre Erweiterungen geht, findest du bei cmt SAP-Seminare für Fachbereich und IT .

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest Python Grundlagen QuizTeste dein Wissen zu Python-Grundlagen. Finde heraus, ob du fit für die nächste Schulung bist. Quiz starten Wissenstest Git Grundlagen QuizTeste dein Wissen zu Branching, Merging, Remote Repositories, Stash und Git-Workflows. Quiz starten
Konkrete Kurse

Wo du genau das übst

Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Einführung in die Programmierung für Programmiereinsteiger
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Groovy Grundkurs
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Unreal Engine Kurs für Einsteiger

Häufige Fragen

Heißt clean core, dass wir keine Eigenentwicklungen mehr haben dürfen?
Nein. SAP beschreibt clean core als Entkopplung und nicht als Verzicht: Erweiterungen sollen über öffentlich freigegebene Schnittstellen mit dem Kern arbeiten, damit sie ein Upgrade überstehen. Was ihr an eigenen Prozessen abbildet, bleibt eure Entscheidung. Was sich ändert, ist die Art, wie diese Erweiterungen an den Standard angebunden werden.
Müssen wir unseren gesamten Bestand umbauen?
Sehr wahrscheinlich nicht. Ein erheblicher Teil eines gewachsenen Bestands wird gar nicht mehr benutzt und gehört abgeschaltet statt umgebaut. Von dem, was bleibt, ist ein großer Teil bereits konform oder mit einem vorhandenen Nachfolgeobjekt schnell umgestellt. Teuer ist nur der Rest, und den grenzt ihr über die technische Prüfung und die Nutzungsdaten vorher ein.
Was ist der Unterschied zwischen einer Erweiterung im System und einer daneben?
Eine Erweiterung im System läuft mit dem eingeschränkten, cloud-optimierten ABAP-Sprachumfang und darf nur freigegebene Schnittstellen benutzen. Sie ist eng an die Vorgänge im Kern gekoppelt und dafür auch gedacht. Eine Erweiterung daneben ist eine eigenständige Anwendung auf der Plattform, die den Kern über Schnittstellen anspricht. SAP empfiehlt, bei der Wahl zuerst die Plattform zu betrachten und die Entscheidung am Anwendungsfall festzumachen.
Womit prüfen wir, ob unser Code konform ist?
Mit dem ABAP Test Cockpit und der Prüfvariante für Cloud-Bereitschaft. Sie meldet jede Stelle, die auf nicht freigegebene Objekte zugreift. Für die Bestandsaufnahme über das ganze System gibt es zusätzlich die Anwendung zur Analyse des kundeneigenen Codes. Welche Schnittstellen freigegeben sind und welche Nachfolger es für nicht freigegebene gibt, veröffentlicht SAP in einem öffentlichen Repository.
Wie fangen wir an, wenn wir gerade erst über die Umstellung nachdenken?
Mit zwei Zahlen: wie viele Objekte im Kundennamensraum liegen und wie viele davon in den letzten Monaten aufgerufen wurden. Der Abstand zwischen beiden ist meist größer als erwartet und verändert die Diskussion sofort, weil er zeigt, dass es nicht um den ganzen Bestand geht. Danach kommt die technische Prüfung, und erst danach die Frage nach dem Budget.

Quellen

Passt thematisch dazu

Für den Altbestand ist die Einordnung eine Aufräumarbeit, für jede neue Anforderung dagegen eine Entwurfsentscheidung, und wie ihr die Stufe vor dem Bau festlegt statt danach , steht im SAP-Bereich.

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

0800 71 20000 E-Mail

Das Team auf das neue Entwicklungsmodell vorbereiten

Bei cmt bekommen ABAP-Teams die Grundlagen, auf denen das entkoppelte Entwicklungsmodell aufsetzt, von objektorientiertem ABAP bis zur sauberen Trennung von Datenmodell, Logik und Oberfläche.

Alle Kurse und Termine Frage stellen

Passt dazu

Alle Themen zu Programmierung