Warum Clean Core?
Oft wird der Begriff Clean Core in einem Satz mit der Innovationsgeschwindigkeit von Softwaresystemen genannt.
Für Clean Core sprechen aber auch andere Gründe: An erster Stelle kostet Custom Code eine Menge Geld! Er muss erstellt, getestet und gewartet werden.
Zusätzlich sind beim Upgrade alle Entwicklungen auf Kompatibilität mit dem Zielrelease zu prüfen und zu testen – das wird leider häufig unterschätzt. Der Aufwand beim Upgrade hängt allerdings sehr stark von der Art ab, wie Add-ons und Custom Code in SAP-Systemen implementiert wurden. Und hier hat sich in den vergangenen Jahren einiges getan.
Was ist das Problem?
Für viele unserer Kunden waren beziehungsweise sind Modifikationen das Salz in der SAP-Suppe. Durch diese Technik war es möglich das Verhalten des SAP-Systems stark zu individualisieren und vollständig an die eigenen Prozesse anzupassen. Der Kreativität der Unternehmen waren dabei keine Grenzen gesetzt.
Auch bei einem Upgrade waren technische Modifikationen kein Problem, da SAP bewährte Werkzeuge und Prozesse für den Umgang mit solchen Modifikationen bereitstellt. Dennoch muss jegliche Modifikation bei jedem Upgrade erneut „abgemischt“ werden – das kostet Zeit, Geld und birgt ein nicht unerhebliches Fehlerrisiko.
Darüber hinaus bindet es Personal auf Anwenderseite beim Testen der ERP-Funktionalitäten nach dem Upgrade. Aufgrund des zu erwartenden technischen Fortschritts werden die Häufigkeit von Upgrades und die damit verbundenen Probleme zukünftig stark zunehmen.
Was passiert beim Upgrade?
Kurz gesagt wird der alte Code inklusive aller Modifikationen durch das Upgrade überschrieben. Im Anschluss daran müssen die Modifikationen wieder in den neuen Quellcode eingefügt werden. Meist kein Problem, aber was passiert, wenn der neue Quellcode genau an dieser Stelle geändert wurde oder gar nicht mehr existiert? Dann wird es knifflig und Sie müssen gegebenenfalls:
- Eine neue Stelle im Code suchen,
- den Prozess neu designen
- oder alte Funktion streichen.
Dass Modifikationen problematisch sind, haben die meisten SAP-Betreiber längst erkannt. Aber auch der Zugriff auf andere Entwicklungsobjekte, wie beispielsweise Elemente des ABAP-Dictionary ist problematisch. Häufig wird zum Beispiel im Custom Code lesend auf SAP-Tabellen zugegriffen. Was aber passiert, wenn diese Tabellen nach dem Upgrade aufgrund einer Datenmodelländerung nicht mehr verfügbar sind oder andere Daten beinhalten?
Bei vielen anderen Erweiterungstechniken, wie zum Beispiel BAdIs oder expliziten Enhancements, sieht es heute schon wesentlich unkomplizierter aus.
Was lernen wir daraus?
Modifikationen sind das Salz in der SAP-Suppe, aber Sand im Getriebe des Upgrades, weshalb Sie diese in Ihrem SAP-System unbedingt vermeiden sollten. Das bedeutet aber auch, dass Anwender lernen müssen, darauf zu verzichten. In Zukunft sollten Systeme nur an den durch die SAP freigegebenen Stellen erweitert werden. Davon gibt es eine ganze Menge und es werden täglich mehr. Aber die Flexibilität, die viele Kunden durch den Einsatz von Modifikationen gewohnt sind, wird es nicht mehr geben.
Wie lassen sich SAP S/4HANA-Systeme in Zukunft erweitern?
Zukünftig sollten Systeme anhand des SAP S/4HANA Cloud Extensibility Model erweitert werden. Das sorgt für mehr Effizienz beim Upgrade und öffnet die Türen für die Public Cloud. Dieses sieht neben der bekannten Erweiterung durch Entwickler auch eine Erweiterung von Anwendungen durch Business Experten vor.
Über die sogenannte Key-User Extensibility sind qualifizierte Anwender selbst in der Lage Last Mile Extensions durchzuführen. Der Funktionsumfang ist vielfältig und bietet von optischen Anpassungen (Verschieben und Ausblenden von Feldern, Anpassen von Labels) bis hin zum Implementieren von BAdIs über einen eingeschränkten ABAP-Befehlssatz viele Möglichkeiten.
Sind tiefgreifendere Änderungen an Anwendungen oder Prozessen erforderlich, können diese durch den Entwickler im Zuge der On-Stack Developer Extensibility erweitert werden. Im Rahmen des Cloud Extensiblity Models dürfen dabei jedoch nur noch freigegebene Techniken, wie beispielsweise Fiori oder freigegebene Erweiterungspunkte (Released Objects) verwendet werden.
Welche Möglichkeiten bietet die Side-by-Side Extensibility?
In vielen Fällen ist es vorteilhaft, Anwendungen nicht „On-Stack“ im SAP S/4HANA-System zu betreiben, sondern diese über die Business Technology Platform (BTP) zur Verfügung zu stellen. Dabei bieten sich zum Beispiel Vorteile wie Skalierbarkeit und die Verfügbarkeit von Services. Auf diese Weise werden ERP-Daten bei Bedarf über die Public-API des SAP S/4HANA-Systems von der BTP konsumiert und dem Anwender zur Verfügung gestellt.
Die BTP bietet eine Vielzahl von Services (Mobile Services, Identity Authentication Service, Cloud Foundry Runtime, Integration Suite, KI Services, …), die bei Bedarf von der Anwendung konsumiert werden können und dabei helfen die Effizienz bei der Softwareentwicklung zu verbessern. Auch By-Side können Key-User selbst Anwendungen über die No-Code Plattform „SAP Build Apps“ erstellen.
Wann wird welche Erweiterungstechnik verwendet?
Die Frage nach der Auswahl von Erweiterungs- und Entwicklungstechnik hängt von unterschiedlichen Faktoren ab und kann nicht pauschal beantwortet werden. Über folgende Matrix kann jedoch eine erste Tendenz abgeleitet werden:
Was passiert mit dem alten Code?
Die Entscheidung liegt ganz bei Ihnen! Es hängt davon ab, welche Strategie Sie anstreben. Wenn Sie zukünftig einen Public Cloud Ansatz verfolgen möchten, können Sie nur Software betreiben, die nach den Grundsätzen des Cloud Extensibility Models entwickelt wurde – ohne Ausnahmen! Keine Modifikationen, Reports oder neue Dynpro-Programme und nur freigegebene Erweiterungspunkte.
Hier gilt es zu prüfen, ob Sie mit diesen Einschränkungen die Anforderungen aus dem Business erfüllen können. Weiterhin sind nicht alle Add-ons kompatibel mit der Public Cloud Edition. Der Vorteil: Sie müssen sich zukünftig nur noch wenige Gedanken um Upgrades machen.
Wenn Sie mehr Flexibilität benötigen, können Sie Ihr System in der Private Cloud Edition oder wie bisher On-Premise betreiben. In beiden Fällen steht Ihnen auch zukünftig die volle Bandbreite von Erweiterungstechniken zur Verfügung.
Natürlich sollten Sie nicht den Fehler begehen und neue Software wie bisher zu entwickeln, sondern die Flexibilität nur dort nutzen, wo es begründet und nicht anders möglich ist. Vor allem aber haben Sie in der Private Cloud Edition die Möglichkeit, Ihren vorhandenen Legacy Code weiter zu betreiben und aufzuräumen.
Steht ABAP zukünftig in der zweiten Reihe?
Die Entwicklung im SAP-Umfeld hat sich in den letzten Jahren stark verändert. Nicht nur Fiori oder die BTP konfrontieren die Entwicklergemeinde mit neuen Frameworks und Programmiersprachen. Auch ABAP wurde stark weiterentwickelt und bringt viele neue Ansätze.
Techniken wie das ABAP RESTful Application Programming Model etablieren sich am Markt und machen die Entwicklung von Anwendungen einfacher. Aber keine Sorge, ABAP wird zukünftig sicher nicht in der zweiten Reihe stehen, sondern hat ein paar neue Kollegen im Team.
Fazit
In jedem Unternehmen sind die Kosten für die Erstellung von Custom Code sowie für die erforderlichen Lizenzen ein wichtiges Entscheidungskriterium. Jedoch werden die Kosten für die Wartung des Custom Codes häufig vernachlässigt. Diese Kosten hängen unter anderem von der gewählten Erweiterungstechnik ab. Wir sprechen dabei von „technischen Schulden“, welche sich bei der Entwicklung anhäufen.
Um Ihre Prozesse zu optimieren, können und sollen Sie natürlich auch zukünftig Ihre SAP-Suppe mit Custom Code würzen. Allerdings sollten Sie bei Ihrer Entscheidung auch zukünftige Wartungskosten berücksichtigen. Unter Umständen kann es sinnvoll sein, dabei höhere Entwicklungskosten in Kauf zu nehmen und einer höheren technischen Schuld vorzuziehen.
