Der Wechsel zu S/4 HANA ist eine gute Gelegenheit, mit Entwicklungen auf der SAP Business Technology Platform (SAP BTP) den Nutzen von bestehenden Modifikationen zu erhalten und gleichzeitig zukünftige Upgrades und Releasewechsel einfacher und schneller zu absolvieren. Darüber hinaus bietet die BTP gänzlich neue Möglichkeiten, die im On-Premise-System nicht existieren. Unternehmen müssen jedoch strategisch planen, ob und wie sie die Plattform verwenden wollen.
Vorteile der SAP Business Technology Platform nutzen
S/4HANA-Umzug: Entwicklungen auf der SAP BTP statt On-Premise entschlacken das gesamte System
Die Ziele, die Unternehmen mit einer Migration ihrer SAP-ERP-Systeme nach S/4HANA erreichen wollen, sind vielfältig:
- Verschlankung von Prozessen, zur Optimierung der Innovations- und Reaktionsfähigkeit bei Veränderungen,
- Verbesserung der Optimierungsmöglichkeiten sowie
- Schaffung neuer, erweiterbarer Integrationsszenarien mit Kunden und Lieferanten
- und viele mehr.
Oft soll mit der Umstellung auf S/4HANA die eigene SAP-Landschaft auch wieder näher an den SAP-Standard rücken, sodass zukünftige Upgrades und Releasewechsel einfacher und schneller absolviert werden können.
Manchen Unternehmen steht beim Umzug der Weg offen, Eigenentwicklungen und vielleicht sogar Systemmodifikationen zurückzubauen. Tatsächlich scheint es eine gute Gelegenheit, sich bei einem solch großen Software-Sprung auch gleich von alten, teils womöglich veralteten und nicht mehr benötigten Individualentwicklungen und Modifikationen zu trennen. Dies gilt insbesondere bei Greenfield-Einführungen, bei denen man mit dem Aufbau des neuen S/4HANA-Systems metaphorisch auf der grünen Wiese beginnt, also nicht bloß ein technisches Upgrade (Brownfield-Konvertierung) des bisherigen SAP-ERP-Systems auf S/4HANA durchführt.
Entwicklungen auf BTP statt On-Premise: Wieder näher am Standard
SAP bietet mit der SAP BTP eine Cloud-Plattform, die neben vielen anderen Funktionen auch zahlreiche Bausteine und Services für Entwicklungs-, Erweiterungs- und Integrationsvorhaben bereitstellt. Damit ergeben sich neue Wege, den Ansatz „Keep the core clean” zu verfolgen – also die eigenen SAP-Systeme möglichst nahe am Standard zu halten. Denn Entwicklungen, die bislang mangels Alternativen innerhalb der SAP-On-Premise-Systeme erfolgten, können SAP-Kunden stattdessen in der SAP BTP implementieren und ausführen. Damit ist neben einer zügigen Entwicklung durch viele Services und Best Practices eine lose Kopplung zwischen den eigenen Erweiterungen und dem SAP-Standard möglich. Diese unterstützt das bereits genannte Ziel, zukünftige Upgrades und Releasewechsel einfacher und schneller durchführen zu können.
Wann eignet sich die BTP?
Erweiterungen auf der BTP umsetzen zu können, über die BTP angebotene Business Services zu verwenden oder Partner beziehungsweise Systeme über die BTP zu integrieren, öffnet vielfältige Möglichkeiten. Legt man den Fokus auf Entwicklungen in der BTP, sind jedoch trotz aller Vorteile grundlegende Abwägungen notwendig. Denn nicht jedes Unternehmen wird vollständig auf S/4HANA Cloud (Public) setzen und damit ausschließlich über die BTP entwickeln. Außerdem wird es auch zukünftig S/4HANA-Systeme als On-Premise geben. Um eine qualifizierte Entscheidung zu treffen, sind folgende Kriterien relevant:
Höhere Einstiegskosten bei der BTP amortisieren sich schnell
Die Kosten teilen sich in drei Bereiche auf: Entwicklungskosten, Betriebskosten, Cloud-Gebühr. Besonders bei den ersten Versuchen wird eine Entwicklung auf der BTP zunächst eher mehr Aufwand verursachen, da die Entwickler:innen sich zumeist auf Neuland bewegen. Hier ist entscheidend, durch entsprechende Schulungsmaßnahmen und eine geschickte Zusammensetzung des Teams eine steile Lernkurve zu erzeugen.
Die internen Betriebskosten einer BTP-Applikation dürfen als geringer angesehen werden, da die Plattform vollständig als Service bereitgestellt wird. Im Gegenzug fallen aber auch Gebühren für die Nutzung der Services an.
Schlankere Infrastruktur und mehr Möglichkeiten selbst mit älteren ERP-Systemen
Besonders Anwendungen, die extern verwendet werden, profitieren von einer Abbildung auf der BTP. Hier sind die Fragen des gesicherten Zugriffs auf die Applikation, die Verbindung zu On-Premise-Systemen und die Anbindung von Daten bereits durch entsprechende Services beantwortet. Bei Anwendungen, die eine große Menge an Daten aus On-Premise-Systemen verarbeiten, müssen Unternehmen wohldurchdachte Architekturentscheidungen treffen. Es gibt diverse Mittel und Wege, große Menge an Daten – auch near realtime – in die BTP zu replizieren. Aber das muss gut durchdacht sein, um tatsächlich eine lose Kopplung zu erreichen und die Daten nicht in ein weiteres Silo zu verbringen.
Effizienzfragen bei der Integration beachten
Zuletzt ist der gesamte Prozessablauf und die Gesamtarchitektur zu betrachten. Wenn eine neue Applikation sinnvollerweise auf viele im On-Premise-SAP-System vorhandene Funktionen (Funktionsbausteine, Klassen und Methoden etc.) zugreifen sollte, spricht das eventuell eher für eine Implementierung im On-Premise-System als für eine Umsetzung in der BTP. Ähnlich verhält es sich, wenn die neue Funktion nur ein kleiner Baustein in einer Massenverarbeitung im On-Premise-Netzwerk ist. Ein ständiges „Ping” (Funktionsaufruf) vom On-Premise-System in die BTP, wiederholt für viele tausend Datensätze, dürfte auch keine besonders performante Lösung darstellen.
Schritte zur eigenen BTP
All diese Überlegungen sind sinnvoll und für eine wohldurchdachte Entscheidung notwendig. Sie können aber auch in entsprechenden Entscheidungsbäumen oder Strategiepapieren für die nächsten Fälle vorgehalten werden, sodass sich eine gewisse Routine einstellt bei der Entscheidung, ob im Einzelfall On-Premise oder in der BTP entwickelt wird. Bewegt sich die Waage zugunsten der BTP, stehen vor den ersten richtigen Entwicklungstätigkeiten zunächst Überlegungen zur passenden Architektur innerhalb der BTP sowie zur Cloud-Struktur beziehungsweise Gesamtarchitektur.
Neben den Kriterien, die allgemein zwischen einer Entwicklung auf der BTP und On-Premise unterscheiden, müssen Unternehmen auch die für sie passende Architektur innerhalb der BTP finden. Dazu stehen drei Umgebungen zur Verfügung:
- Cloud Foundry
- Kyma
- ABAP
Diese Entscheidung ist abhängig von den umzusetzenden Anforderungen und den vorhandenen Skills der Architekt:innen und Entwickler:innen.
SAP stellt jedem Kunden, der sich für die BTP entschieden hat, einen Global Account zur Verfügung. Dieser bildet eine Klammer um die sogenannten Subaccounts, als abgeschlossene Bereiche zum Beispiel zur Trennung von Projekten oder Stages.
Die Subaccounts sind das wichtigste Strukturelement innerhalb der SAP BTP, da sie bei der Erstellung einmalig festgelegte Parameter enthalten. Ein Global Account kann einen oder mehrere Subaccounts enthalten, für die jeweils einzeln definiert wird, in welcher geografischen Region, zum Beispiel Nordamerika, Westeuropa oder andere, und bei welchem Infrastruktur-Anbieter der Subaccount physisch implementiert wird.
Für die Wahl des geeigneten Subaccount-Modells spielen daher folgende Fragen eine zentrale Rolle:
- Ist eine Staged-development-Umgebung – Dev, Cons, Prod – in der BTP notwendig?
- Sollen Daten in der BTP zentral in einem oder verteilt in mehreren Subaccounts gespeichert werden?
- Sollen Applikationen, die vergleichbare Architekturen – CF, Kyma, ABAP – nutzen, alle in einem, in möglichst wenigen oder in jeweils einem separaten Subaccount laufen?
- Werden Schnittstellen beziehungsweise APIs in einem zentralen oder in jedem einzelnen Subaccount vorgehalten?
- Ist es aus organisatorischen Gründen (zum Beispiel Zugriffsschutz) notwendig, bestimmte Anwendungen und/oder Daten über dedizierte Subaccounts von anderen zu separieren?
Anschließend muss in Abstimmung mit dem Subaccount-Modell das Security-Modell definiert werden. Hierbei sind vor allem die Aspekte zur User-Authentifizierung und -Autorisierung relevant.
Bei der Entwicklung einer Anwendung ist dann zu betrachten, welche Layer (User Interface, Business-Logik, Persistenz) betroffen sind beziehungsweise auf der BTP umgesetzt werden. Je mehr Layer ein Unternehmen auf der BTP abbildet, umso bedeutungsvoller wird die Wahl des Programmiermodells. Für eine UI5-App, die Daten aus einem On-Premise-SAP-System verwendet, ist diese Entscheidung sehr einfach. Für eine komplexere Applikation, die möglicherweise viele Daten benötigt, steigen auch die Anforderungen an das Programmiermodell.
Für optimale Weiterbildungsmaßnahmen sollten Verantwortliche zusätzliche Ausbildungsaktivitäten einplanen, um die technischen Neuerungen in der Cloud-Plattform zu beherrschen. Fundierte Kenntnisse über OData, SAPUI5, Fiori Elements, ABAP CDS und generell ein gutes Verständnis für das ABAP RESTful Application Programming Model sind für die Erstellung von Fullstack-Entwicklungen (mit dem RAP Modell) unverzichtbar.
Ähnlich wie bei Anwendungen innerhalb des firmeneigenen Netzwerks, die sich hinter der Unternehmensfirewall befinden, müssen auch die Anwendungen in der SAP BTP mittels Authentifizierung und Autorisierungsmechanismen abgesichert sein. Sollten Fehler geschehen, ist das Schadensrisiko in der Cloud natürlich ungleich größer. Das Absichern aller Anwendungen im gesamten Lebenszyklus muss also eine zentrale Rolle einnehmen, indem alle Beteiligten die Konzepte und Guidelines unbedingt beachten und verinnerlichen.
Auch hinsichtlich des Betriebs kommen mit der Nutzung von Platform-as-a-Service als Basis für Unternehmensanwendungen neue Perspektiven auf Unternehmen zu. Der Aufbau neuer Infrastruktur in der Cloud geht auf Knopfdruck, ein neuer Subaccount ist innerhalb von Minuten zusammengestellt und steht lauffähig zur Verfügung. Auch um die technische Stabilität von Hardware und den grundlegenden Cloud-Services („Oberkante Betriebssystem“) kümmert sich der Cloud-Anbieter – bei der SAP BTP also der jeweilige Infrastruktur-Betreiber wie etwa Microsoft, Amazon, Google oder andere, die oben genannt wurden – sowie natürlich SAP selbst. Andererseits gibt man auch einige selbstverständlich gewordene Gewohnheiten auf, wie zum Beispiel die Möglichkeit, frei und selbstbestimmt die Release-Zyklen alle Software-Stacks auch unterhalb der Anwendungsschicht festlegen zu können.
Fazit zum Wechsel zu S/4HANA
SAP stellt für Entwickler:innen viele Werkzeuge bereit, um den Alltag zu erleichtern und den Entwicklungsprozess zu beschleunigen. Durch die organisatorische und IT-technische Offenheit der SAP-BTP-Anwendungen und die in der SAP BTP vorhandenen umfangreichen Integrationswerkzeuge können nun Szenarien viel einfacher und schneller umgesetzt werden. Lieferanten, Kunden und weitere Partner können somit eng(er) mit den eigenen Daten und Prozessen vernetzt werden, sodass hierbei echte End-to-end-Prozesse vorliegen.
Sie haben Interesse an Entwicklungen auf der SAP Business Technology Platform?
Dann informieren Sie sich jetzt über unsere große Bandbreite an SAP Services und nehmen Sie gern Kontakt mit uns auf. Wir freuen uns Sie kennenzulernen!