Wie migriert und entwickelt man zukünftig SAP Custom Code?

Bei der Migration von Eigenentwicklungen (SAP Custom Code Migration) nach S/4HANA sind den SAP-Anwenderunternehmen zwei Punkte besonders wichtig: Aufräumen vor der Migration und eine hohe Geschwindigkeit bei der Umstellung. Wie stellt man SAP-Eigenentwicklungen für SAP ECC und S/4HANA auf eine neue Technologiebasis? Was braucht man, um schnell, schlank, plattformunabhängig, agil und außerhalb des Kerns zukünftige Erweiterungen Cloud-native zu entwickeln? Wer bei Eigenentwicklungen weiterhin ausschließlich an ABAP denkt, kennt vielleicht alternative Optionen nicht.

Erweiterungen und Integrationen sollte man später gegebenenfalls auf jeder Cloud-Platform nutzen können, damit man mit kundenindividuellen Erweiterungen keine neuen Silos oder Abhängigkeiten von Cloudanbietern aufbaut. Eine Antwortmöglichkeit für diese Herausforderungen ist die Red Hat Openshift Container Platform.

 

SAP Custom Code Migration: Herausforderungen

Wir fragten die SAP-Community, was bei der Custom Code Migration nach S/4HANA am wichtigsten ist. Zwei Herausforderungen sind dominierend: Aufräumen vor der Migration (39 Prozent) und eine hohe Geschwindigkeit bei der Migration (28 Prozent).

Mehr als zwei Drittel der SAP-Anwenderunternehmen präferieren selektive oder Brownfield (like-to-like) Migrationen nach S/4HANA und wollen vieles oder alles unverändert lassen, wie sich unser SAP-Community Stimmungsbarometer mit mehr als 1.000 abgegebenen Stimmen deuten lässt.

Viele Unternehmen dürften demnach eine eher „technische“ S/4HANA-Migration wählen, um schnell auf die neue Technologiebasis zu kommen — und erst zu einem späteren Zeitpunkt Innovationspotenziale nutzen. Wer bei den Eigenentwicklungen jedoch weiterhin ausschließlich an ABAP denkt, kennt vielleicht alternative Optionen nicht.

 

SAP Custom Code ausmisten und schnell migrieren 

Mit dem Studium der SAP „simplification list“ für S/4HANA oder einem S/4HANA Readiness Check gewinnt man Erkenntnisse, welches kundeneigene ABAP Coding weiterhin funktioniert und welches angepasst werden muss.

Aus Kundenprojekten hören wir, dass oft ist ein Großteil der kundenindividuellen Anpassungen ausgemistet werden kann, weil er schon lange nicht mehr benutzt wird. In vielen Unternehmen dürften zudem ABAP-Berichte und ABAP-Reports einen Großteil des ABAP-Codes ausmachen. Auch hiervon wird nur ein Bruchteil benötigt werden, wenn die SAP-Systeme zehn Jahre oder länger in Betrieb sind.

 

Modernisierung kundeneigener SAP-Entwicklungen

Über Jahrzehnte war der beste Weg, Modifikationen am SAP-System mittels ABAP-Code vorzunehmen. Mit der Microservice-Architektur und Cloud-Strategie der SAP gibt es andere (oft leistungsfähigere) Optionen zur Erweiterung von Lösungen und zur Ende-zu-Ende Integration von Prozessen. Das S/4HANA-Paradigma heißt: Modifikationen sollen außerhalb des Kernproduktes stattfinden. Der Kern bleibt modifikationsfrei und jederzeit updatefähig.

Mit einer „side-by-side“ Erweiterbarkeit der SAP-Systeme sind viele Vorteile verbunden. Das SAP-Universum lässt sich einfach mit Innovationsbausteinen der Cloud-Plattformen (IoT, ML, KI, …), externen Datenströmen und mit Non-SAP-Lösungen kombinieren.

Unternehmen können ihre Agilität steigern und schneller Innovationen umsetzen. Das ist wichtig, weil die SAP-Landschaft für die Unternehmen im Daten-Zeitalter weiter an Bedeutung gewinnt. Ein schneller time-to-market oder idea-to-market und eine modernisierte SAP-Strategien und SAP-Architekturen sind dafür in vielen Unternehmen nötig.

Wichtig: Auch SAP ECC Anwenderunternehmen können (und sollten) schon heute Eigenentwicklungen zukunftsorientiert entwickeln, auch wenn die S/4HANA-Migration vielleicht noch gar nicht konkret geplant ist. Dadurch lässt sich bereits jetzt die spätere Komplexität beim S/4HANA-Umstieg reduzieren.

 

Containerisierung von SAP-Entwicklungen schafft Unabhängigkeit vom Cloud-Provider

Mit einer Containerisierung, beispielsweise – auch on-premises betrieben – der Red Hat OpenShift Container Platform, erreicht man für SAP-Eigenentwicklungen zudem Unabhängigkeit vom Betriebsmodell und insbesondere vom Cloud-Anbieter.

Wenn Fachabteilungen oder Landesgesellschaften mit nicht abgestimmten Innovationsbausteinen der Cloud-Plattformanbieter proprietäre Lösungen entwickeln, kann es schnell zu einem vendor-lock-in kommen. Entwickelt man Cloud-native und nutzt eine Container-Managementumgebung wie OpenShift, kann man hingegegen jederzeit den Cloud-Provider wechseln.

Auf S/4HANA migrierte ABAP-Entwicklungen, Fiori-Apps und andere Anwendungen lassen sich in Kubernetes-Containern betreiben und von überall nutzen. Das dürfte beispielsweise für globale Organisationen interessant sein, da sich das IT-Management und Rollouts vereinfachen lassen.

 

Management hybrider SAP-Umgebungen 

Bei der Ende-zu-Ende Infrastruktur von Red Hat bekommen SAP-Anwenderunternehmen weitere Optionen „en-passant“ mitgeliefert: Automatisierungsmöglichkeiten im Betrieb, Integrationsservices, Sicherheitsfunktionen, Konnektoren für SAP HANA und eine Validierung für SAP Data Intelligence (früherer Name: SAP Data Hub) und Interoperabilität für on-Premises, hybride und Multi-Cloud SAP-Umgebungen. Natürlich kann man zudem Red Hat Enterprise Linux als Betriebssystem für die SAP-Landschaft nutzen.

Übrigens hat Red Hat gemeinsam mit SAP für 2021 eine „SAP Cloud Platform – Private Edition“ auf der OpenShift Container Platform angekündigt. Damit bekommen IT-Abteilungen mehr Kontrolle und Einflussmöglichkeiten für ihre Cloud-Komponenten. Das dürfte ein weiteres wichtiges Argument für den Einsatz von Red Hat OpenShift werden.

 

SAP Discovery-Workshop: Möglichkeiten zur SAP-Modernisierung finden

Red Hat bietet SAP-Kunden und SAP-Partnern einen kostenlosen „SAP Discovery-Workshop“ an, der einen Tag dauert und bei dem verschiedene Möglichkeiten und Ebenen der Modernisierung (Hosting, Platform, Architektur) individuell beleuchtet und diskutiert werden können. Auch DevOps-Prozesse bei der Entwicklung neuer SAP-naher Applikationen, Automatisierung, SAP HANA Deployments in 15 Minuten, Zero Downtime Maintenance und Patch Management Automatisierung können thematisiert werden.

Die Workshops dürften insbesondere auch für SAP-Partner interessant sein, die eigenes Hosting oder Add-On / Eigenentwicklungen anbieten oder SAP-Anwenderunternehmen bei der Aktualisierung ihrer SAP-Strategie helfen wollen.

 

 

Weiterführende Informationen:

Webinar: SAP Side-by-Side Extensibility und SAP Custom Code Migration

PoC-Bericht: SAP ABAP Applikationsserver in Kubernetes