Business Technology Platform

Darüber hinaus bietet die Business Technology Platform, BTP, neue Möglichkeiten, die im On-premises-System nicht existieren. Unternehmen müssen jedoch strategisch planen, ob und wie sie die Plattform verwenden wollen. Die Ziele, die Unternehmen mit einer Migration der ERP-Systeme nach S/4 erreichen wollen, sind vielfältig: verschlankte Prozesse, die Chance auf mehr Innovation und erhöhte Reaktionsfähigkeit bei Veränderungen, bessere Optimierungsmöglichkeiten sowie neue, erweiterte Integrationsszenarien mit Kunden und Lieferanten und viele mehr. Oft soll mit der Umstellung auf S/4 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 dabei 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/4-Hana-Systems metaphorisch auf der grünen Wiese beginnt, also nicht bloß ein technisches Upgrade (Brownfield-Konvertierung) des bisherigen ERP-Systems auf S/4 durchführt.

Andere Unternehmen jedoch benötigen viele Eigenentwicklungen und Modifikationen, auch nach dem Wechsel auf S/4. Diese mit in das neue System umzuziehen, ist ein naheliegender Gedanke. Doch damit bliebe alles beim Alten und der SAP-Standard in weiter Ferne. Für sie kann die BTP eine Lösung sein.

SAP bietet mit der BTP, die bis Herbst 2020 als SCP, SAP Cloud Platform, bekannt war, 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-premises-Systeme erfolgten, können Bestandskunden stattdessen in der 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. Doch wann ist die Nutzung der BTP überhaupt sinnvoll und wie sollten Unternehmen bei der Umsetzung vorgehen?

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/4 Hana Cloud (Public) setzen und damit ausschließlich über die BTP entwickeln. Außerdem wird es auch zukünftig S/4-Systeme als On-prem geben. Um eine qualifizierte Entscheidung zu treffen, sind folgende Kriterien relevant: Kosten, Infrastruktur und Integration.

Einstiegskosten bei der BTP

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 Entwicklerinnen und Entwickler sich zumeist auf Neuland bewegen. Hier ist entscheidend, durch entsprechende Schulungsmaßnahmen und eine geschickte Zusammensetzung des Teams eine steile Lernkurve zu erzeugen. Zukünftige Entwicklungen profitieren davon und alle Entwickler wissen die von SAP bekannten Beschleuniger zu schätzen. 

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. Ein Estimator Tool kann diese sehr gut vorhersagen. Dann gilt es noch, eine geschickte Mischung aus Subscription, Pay-as-you-go und CPEA (Cloud Platform Enterprise Agreement) zu finden, um die Kosten zu optimieren.

Demgegenüber stehen die eingesparten Kosten bei zukünftigen Upgrades des On-prem-Systems. Jede dort nicht vorhandene Individualentwicklung kann dann auch keine Aufwände verursachen. Auch andere Kostenvorteile, zum Beispiel bei End-to-End-Prozessen mit eingebundenen externen Partnern, können sich je nach Anwendungsfall ergeben.

Schlankere Infrastruktur

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-premises-Systemen und die Anbindung von Daten bereits durch entsprechende Services beantwortet. Bei Anwendungen, die eine große Menge an Daten aus On-premises-Systemen verarbeiten, müssen Unternehmen geschickte Architekturentscheidungen treffen. Es gibt diverse Mittel und Wege, große Mengen 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.

Die verfügbaren Services können manche Anwendungsfälle erst ermöglichen und andere deutlich beschleunigen. So sind die Möglichkeiten, KI-Modelle für Vorhersagen zu verwenden, in On-premises-Systemen erst mit einer aktuellen Version von S/4 möglich. Über die BTP können diese auch für ältere ERP-Systeme verwendet werden. Ein anderes Beispiel ist die Entwicklung eines Chat Bots, für die die BTP einen entsprechend auszuprägenden Service mitbringt.

Effizienz bei der Integration

Zuletzt ist der gesamte Prozessablauf und die Gesamtarchitektur zu betrachten. Wenn eine neue Applikation sinnvollerweise auf viele im On-premises-SAP-System vorhandene Funktionen (Funktionsbausteine, Klassen und Methoden etc.) zugreifen sollte, spricht das eventuell eher für eine Implementierung im On-prem-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-prem-System ist. Ein ständiges „Ping“ (Funktionsaufruf) vom On-prem-System in die BTP, wiederholt für viele Tausend Datensätze, dürfte auch keine besonders performante Lösung darstellen. All diese Überlegungen sind sinnvoll und für eine wohldurchdachte Entscheidung notwendig. Die Evaluierung kann auch in entsprechenden Entscheidungsbäumen oder Strategie-Papieren für die nächsten Fälle vorgehalten werden, sodass sich eine gewisse Routine einstellt bei der Entscheidung, ob im Einzelfall On-prem oder in der BTP entwickelt wird. Bewegt sich die Waage zugunsten der BTP, stehen vor den ersten richtigen Entwicklungstätigkeiten zunächst Überlegungen zur richtigen Architektur innerhalb der BTP sowie zur Cloud-Struktur beziehungsweise Gesamtarchitektur.

Cloud Foundry, Kyma, Abap 

Neben den Kriterien, die allgemein zwischen einer Entwicklung auf der BTP und on-premises 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 und Abap. Diese Entscheidung ist abhängig von den umzusetzenden Anforderungen und den vorhandenen Skills der Architekten und Entwickler. Über Cloud Foundry können beispielsweise in kurzer Zeit Fiori-Apps intern und extern sehr leichtgewichtig bereitgestellt werden. Die Abap-Umgebung in der BTP ist relativ schwergewichtet und erzwingt unter anderem eine dedizierte Hana-DB in der Cloud. Dafür bietet sie die Möglichkeit, in der wohlbekannten SAP-Programmiersprache zu arbeiten und eine sehr enge Integration an On-prem-Funktionen zu implementieren. In der Kyma-Umgebung können containerisierte Applikationen entwickelt und eingesetzt werden. Allen Umgebungen gemein ist die gute Integration in die SAP-Landschaft.

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 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.

Derzeit sind dies: AWS, Microsoft Azure, Google Cloud Platform, Alibaba Cloud und SAP-Cloud-Infrastruktur. SAP überlässt dem Kunden zwar die Wahl des Hyperscalers, das Vertragsverhältnis besteht jedoch ausschließlich mit SAP. Darüber hinaus müssen Unternehmen festlegen, ob sie den Subaccount für Entwicklungen im Cloud-Foundry-Standard, für Kyma-basierte containerisierte Microservice-Architekturen oder für Abap-Entwicklungen einsetzen wollen.

Es ist ratsam, direkt zu Beginn der Nutzung der BTP ein Subaccount-Modell zu konzipieren, um Synergieeffekte zu ermöglichen und Services und Daten wiederverwenden zu können. Selbstverständlich ist auch eine ordentliche, transparente und nachvollziehbare Struktur für wachsende Plattformen unbedingt notwendig. Es gilt zu prüfen, welche gleichartigen Applikationen einen Subaccount (pro Stage) gegebenenfalls teilen können und wie strikt die Trennung erfolgen soll. Einzelne Anwendungen können nicht oder nicht ohne Weiteres die Ressourcen wie etwa Services oder Daten eines anderen Subaccounts „sehen“ und nutzen. 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?

Security

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-prem-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 die Wahl der Programmiersprache und -tools stehen die drei zuvor erwähnten Ansätze zur Auswahl: Cloud Foundry, Kyma und Abap.

Während Cloud-Foundry- und Kyma–Umgebungen diverse Programmiersprachen, etwa Java, Node.js oder Python, erlauben, sind Abap-Umgebungen in der BTP natürlich für die Entwicklung von Abap-Code vorgesehen. Die richtige Auswahl zu treffen, hängt also von mehreren Faktoren ab. Dabei sind sowohl technische Möglichkeiten der einzelnen Plattformen als auch das jeweils in der Organisation vorhandene technische Wissen – zum Beispiel der Entwicklerinnen und Entwickler – zu berücksichtigen.

Während sich also klassische SAP-Entwickler in der BTP noch am ehesten in Abap-Umgebungen wiederfinden werden, stehen mit Cloud Foundry und Kyma jetzt auch technische Ansätze zur Verfügung, die es „Nicht-SAP-Entwicklern“ ermöglichen, Anwendungen im SAP-Kontext zu bauen.

In beiden Fällen 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. 

Im Falle von Cloud-Foundry-Entwicklungen sollten die mit der BTP befassten Mitarbeiter für die Entwicklung von Fiori–Apps OData, SAPUI5 und gegebenenfalls Fiori Elements erlernen. Für Fullstack-Applikationen ist darüber hinaus auch SQLscript, Node.js und natürlich das CAP-Modell relevant. Für viele heutige Entwicklerinnen und Entwickler dürfte dies einen anspruchsvollen, aber unbedingt auch interessanten und zukunftsorientierten Ausbildungspfad darstellen.

Dass die Entwicklung und der Betrieb von cloudbasierten Anwendungen auch besondere Anforderungen an Sicherheit, Zugriffsschutz und den technischen Betrieb stellen, ist bekannt. Hier bildet die Busi-ness Technology Platform keine Ausnahme. Ähnlich wie bei Anwendungen innerhalb des firmeneigenen Netzwerks, die sich hinter der Unternehmensfirewall befinden, müssen auch die Anwendungen in der 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ümmern sich der Cloud-Anbieter – bei der 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 aller Software-Stacks auch „unterhalb“ der Anwendungsschicht festlegen zu können. In der BTP (wie in vermutlich praktisch allen anderen Cloud-Umgebungen) ist dies im Normalfall zentral von SAP vorgegeben und sorgt für eine stets aktuelle Basis für die eigenen Anwendungen.

Fazit

Neben den erwarteten Vorteilen im Betrieb, einer schnelleren Entwicklung und der sehr guten Integration in die SAP-Welt ist die BTP als Entwicklungsumgebung bei Neben den erwarteten Vorteilen im Betrieb, einer schnelleren Entwicklung und der sehr guten Integration in die SAP-Welt ist die BTP als Entwicklungsumgebung bei Einsatz von SAP-SaaS-Anwendungen sogar teils die einzige Möglichkeit, eigene Erweiterungen vorzunehmen. SAP stellt für Entwicklerinnen und Entwickler, wie wir es von dem Unternehmen gewohnt sind, viele Werkzeuge bereit, um den Alltag zu erleichtern und den Entwicklungsprozess zu beschleunigen.

Aber auch über die Entwicklung von Anwendungen hinaus ist die BTP die strategische Plattform für SAP-Anwender. Ein kleines Beispiel ist ein Service für die Bereitstellung von Wechselkursen auch ohne S/4 bereits im ERP-System. Aber auch weitere Business Services wie eine zentrale Stammdatenintegration oder die X-Rechnung befinden sich schlüsselfertig im Angebot.

Nicht zuletzt ergeben sich für Unternehmen mit der Business Technology Platform bislang nicht vorhandene Chancen und Möglichkeiten für die Etablierung vollkommen neuer Business-Prozesse. Durch die organisatorische und IT-technische Offenheit der 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. 

Die stetig wachsenden intelligenten Services (KI-Services) in der BTP, die Unternehmen hervorragend mit eigenen Anwendungen verknüpfen und kombinieren können, helfen bei der Wertschöpfung aus Daten. Bei konsequenter Umsetzung und Nutzung unterstützt die SAP BTP auf diese Weise dabei, sich für aktuelle und zukünftige Herausforderungen fit zu machen und sich agil an Veränderungen der Marktsituation anzupassen.