Re-Engineering von Geschäftsanwendungen

auf der SAP BTP

1.       Einleitung

Mit dem angekündigten Wartungsende von SAP Enterprise Core Components (ECC) und der strategischen Ausrichtung auf S/4HANA stehen viele Unternehmen vor der Frage, wie sie ihre bestehenden SAP-Anwendungen zukunftsfähig aufstellen können. Ein zentraler Baustein dieser Modernisierung ist die „Cloudifizierung“ von Geschäftsanwendungen. Zu den Vorteilen der Nutzung von Cloud-Technologien gehören flexiblere Systeme, ein verbessertes Geschäfts-IT-Alignment, eine Reduzierung der Total Cost of Ownership (TCO) und eine optimierte Entwicklung neuer Geschäftsanwendungen. Neben der Sicherstellung der „Cloud-Readiness“ von neuentwickelten Anwendungen ist auch die Portierung bestehender Geschäftsanwendungen auf Cloud-Technologie bedeutend und stellt Unternehmen vor Herausforderungen. Der Hauptgrund hierfür ist, dass in den meisten Fällen ein Re-Engineering von Anwendungen erforderlich ist, um von den neuen technologischen Möglichkeiten zu profitieren, wohin gegen ein bloßes „Lift & Shift“ einer Anwendung in der Regel zu kurz greift (vergleiche die sechs R’s der Cloud-Migration [1]).

Im Kontext des Re-Engineerings von SAP-Anwendungen hin zu einer angestrebten Cloud-Fähigkeit sind insbesondere zwei Prinzipien zu beachten: das Keep-the-Core-clean-Paradigma und der Side-by-Side-Erweiterungsansatz (siehe weiter unten). Beide Ansätze bedeuten in der Praxis eine Verlagerung komplexer Entwicklungen weg vom SAP-Kern hin zur Cloudumgebung Business Technology Platform (BTP). Damit einher geht ein grundlegender Wandel des Entwicklungsmodells: Anstelle eines klassischen, monolithischen Aufbaus tritt ein API-basierter Ansatz, in dem Funktionalitäten über verschiedene Systeme und Laufzeitumgebungen hinweg verteilt bereitgestellt werden. Die technologische Grundlage hierfür bieten die Anwendungsentwicklungsmodelle ABAP-RESTful Application Programming Model (RAP) und Cloud Application Programming Model (CAP). Die Nutzung der BTP in Kombination mit diesen Entwicklungsmodellen eröffnet neue Möglichkeiten für Unternehmen, um Geschäftsanwendungen zu entwickeln, zu erweitern und zu betreiben. Das Re-Engineering bestehender SAP-Anwendungen hin zu BTP und RAP/CAP bringt jedoch gewisse Hürden mit sich.

Dieser Artikel soll eine Orientierungshilfe für das Re-Engineering bestehender SAP-Anwendungen bieten. Im Fokus stehen dabei klassische ABAP-Anwendungen, die in einer On-Premise- oder hybriden Umgebung betrieben werden. Ziel ist deren Überführung in eine modernisierte, API-basierte Architektur, die auf Cloud-Technologien basiert, in der SAP BTP provisioniert und parallel zum SAP-Kern betrieben wird. Dazu geben wir zunächst einen Überblick über die technologischen Grundlagen der BTP und der genannten Entwicklungsmodelle. Anschließend ordnen wir entlang der Phasen der etablierten SAP Activate Methodology konkrete Aktivitäten und Empfehlungen ein, die sich nach unserer Erfahrung beim Re-Engineering von ABAP-Anwendungen als relevant erwiesen haben. Damit bieten wir eine praxiserprobte Orientierung für die Modernisierung bestehender Anwendungen auf Basis der SAP BTP.

1.1                SAP Business Technology Platform

Die SAP Business Technology Platform (BTP) ist eine Cloud-Plattform, die Unternehmen bei ihrer digitalen Transformation unterstützt. Sie stellt einen umfassenden Katalog an Werkzeugen und Diensten bereit, mit denen sich Innovationen und neue Geschäftsmodelle schnell und kosteneffizient umsetzen lassen. Die Plattform gliedert sich in fünf Säulen: (1) Anwendungsentwicklung, (2) Automatisierung, (3) Integration, (4) Daten und Analytics sowie (5) künstliche Intelligenz. Auf Basis offener Standards und Cloud-nativer Technologien ermöglicht die SAP BTP darüber hinaus eine nahtlose Integration von SAP- und Drittanbieter-Systemen.

Die Werkzeuge und Dienste der BTP lassen sich zentral über die Plattform als Services im Abonnementmodell beziehen. Einen Überblick über das verfügbare Angebot bietet das SAP Discovery Center [2]. Während einige dieser Services bereits über andere SAP-Plattformen verfügbar waren, handelt es sich beim Großteil um Neuentwicklungen. Für das Re-Engineering bestehender Anwendungen auf Basis der SAP BTP sind insbesondere zwei Services relevant: (1) das BTP ABAP Environment als Laufzeitumgebung für RAP-basierte Entwicklungen in ABAP sowie (2) die Cloud Foundry-Umgebung als Laufzeitumgebung für CAP-basierte Entwicklungen.

1.2                Erweiterungsmodelle

Wie oben bereits kurz angerissen, ist das bisherige Entwicklungs- und Erweiterungsmodell für SAP-Anwendungen in ABAP von monolithischer Natur: Erweiterungen werden mittels Workflows, Reports, Interfaces, Conversions, Enhancements und Forms (WRICEFs) direkt im SAP ERP-Kern umgesetzt. Dies führt zu Herausforderungen wie erschwerter Wartbarkeit, komplexen Abhängigkeiten zwischen Komponenten und geringer Flexibilität. Um diese Herausforderungen zu adressieren, hat SAP das Keep-the-Core-clean-Paradigma formuliert. Dieses sieht vor, dass weniger komplexe Erweiterungen – etwa Felderweiterungen – weiterhin im SAP-Kern mittels der sogenannten Key User Extensibility realisiert werden, während komplexere, programmierlastige Entwicklungen als Side-by-Side-Erweiterungen auf der BTP im Rahmen der Developer Extensibility umgesetzt werden können. Die Entscheidung für Key User Extensibility oder Developer Extensibility muss dabei stets individuell anhand der konkreten Anforderungen getroffen werden. Der Fokus dieses Artikels liegt auf den Möglichkeiten und Herausforderungen der Developer Extensibility.

Für die Neuentwicklung sowie das Re-Engineering vorhandener, komplexer Anwendungen sind neue Entwicklungsmodelle erforderlich, die durch eine API- und Microservice-orientierte Architektur eine vereinfachte Kommunikation zwischen Systemen und damit durchgängige, systemübergreifende Geschäftsprozesse ermöglichen. SAP adressiert diesen Bedarf mit den Modellen RAP und CAP. Beide basieren auf offenen Standards wie etwa OData [3]. Wie der Name nahelegt, nutzt RAP ABAP als Programmiersprache, während CAP Implementierungen in JavaScript und Java erlaubt. Der Schwerpunkt dieses Beitrags liegt auf dem RAP-Modell; weitere Informationen zu CAP finden sich in [4].

RAP bietet ein Framework um kundenspezifische Entwicklungen release-sicher abzubilden. Es unterstützt die Modellierung fachlicher Entitäten, für die sich CRUD-Operationen automatisch generieren und darüber hinaus weitere, individuelle Operationen implementieren lassen. Diese werden jeweils als OData-APIs bereitgestellt. Zentrales Element der RAP-Entwicklung ist die Konzeption eines Geschäftsobjekts, das aus mehreren verbundenen Entitäten besteht. Eine Entität bildet jeweils ein Element des Geschäftsmodells eines Unternehmens ab. Entitäten stehen in Form einer Baumstruktur hierarchisch zueinander in Beziehung. An der Spitze steht genau ein Root-Objekt. Von diesem können mehrere Entitäten als Kinder-Entitäten abgehen, die dann wiederum als Eltern-Entitäten für hierarchisch tiefer verortete Elemente fungieren können. Nachdem ein Geschäftsobjekt konzeptioniert wurde, kann es in RAP implementiert werden. Dazu werden zunächst die unterschiedlichen Entitäten und ihre Beziehungen mithilfe der Core Data Services (CDS) als Views modelliert. Die CDS-Views beschreiben Sichten auf Daten und können grob als Erweiterung von SQL-Datenbank-Views betrachtet werden. SAP empfiehlt mehrere Views für jede Entität zu erstellen beginnend mit Basis-Views, die Daten aus der Persistierungsschicht lesen. Auf Grundlage dieser Views werden Interface-Views erstellt, die Daten aus verschiedenen Basis-Views selektieren und zusammenführen. Interface-Views bilden wiederum die Grundlage für Consumption-Views, die Daten zum Konsumieren durch Clients anbieten und aus diesem Grund die in Interface-Views vorhandenen Daten gegebenenfalls wieder einschränken müssen. Dieses Modell wird als Virtuelles Datenmodell (VDM) bezeichnet. Bei der Umsetzung mit RAP müssen also zwei Dimensionen berücksichtigt werden: (1) die VDM-Schichten für eine einzelne Entität und (2) die semantischen Beziehungen zwischen verschiedenen Entitäten in Form eines Geschäftsobjektes. Abbildung 1 zeigt schematisch das Zusammenspiel der erläuterten Entitäten.

Abbildung 1: Schematische Darstellung eines Geschäftsobjektes

Im Anschluss an diese Aktivitäten können die einzelnen Entitäten noch mit Verhalten annotiert werden. Grundlage hierfür sind die von SAP definierten Behavior Definitions: Durch diese können eine Vielzahl von Funktionalitäten mit sehr begrenztem oder keinem Programmieraufwand mittels Konfiguration umgesetzt werden. Beispielhaft seien hier genannt (1) Standardoperationen zum Lesen, Schreiben, Ändern und Löschen, (2) die automatische Vergabe von Schlüsseln für Datenbankeinträge, (3) Sperrkonzepte für konkurrierende Zugriffe oder (4) Validierungen von Daten vor der Speicherung. Nach dem Abschluss der Konfiguration können die Entitäten inklusive des definierten Verhaltens als Services exponiert werden. Die Services können dann entweder direkt über Fiori-Apps (siehe unten) von Endnutzern genutzt oder programmatisch von anderen Systemen und Anwendungen konsumiert werden.

2.       Re-Engineering von ABAP-Anwendungen

SAP schlägt für die Einführung und Nutzung der BTP das generische, auf sechs Phasen basierende Prozessmodell Activate Methodology Roadmap vor [5]. Im Folgenden nutzen wir die sechs Phasen der Roadmap als Struktur, um konkrete Aktivitäten und Empfehlungen einzuordnen, die sich nach unserer Erfahrung bei der Portierung von ABAP-Anwendungen auf die SAP BTP als notwendig erwiesen haben.

2.1                Discover

In der Discover-Phase sollte zunächst ein verbindliches Bekenntnis vom Management für die Keep-the-Core-clean-Strategie eingeholt werden, da deren Umsetzung initial technische und fachliche Ressourcen bindet – unter anderem durch die Einarbeitung in neue Technologien. Die langfristigen Vorteile überwiegen diesen Mehraufwand jedoch. Zudem empfiehlt sich die Etablierung einer dedizierten, eigenständigen organisatorischen Einheit, die für das Management von SAP BTP verantwortlich ist. Weiterhin sollten in dieser Phase Applikationen, die sich potenziell für ein Re-Engineering eignen, identifiziert werden. Mögliche Kriterien sind beispielsweise (1) die Komplexität der Anwendung, (2) die Cloud-Readiness der bestehenden ABAP-Codebasis oder (3) die Kompatibilität der Anwendung mit dem Keep-the-Core-clean-Paradigma. Tools wie beispielsweise msg.FIT [6] können bei diesen Aufgaben unterstützen. Darüber hinaus bietet SAP mit dem Cloud ALM Dashboard und der Custom Code Migration App [7] Tools an, die bei diesen Aktivitäten hilfreich sind. Auch sollte die vorhandene Dokumentation der Legacy-Anwendung gesichtet werden sowie die Product Owner identifiziert werden, die die Anwendung und die Business-Anforderungen kennen. Es sollte stets beachtet werden, dass der Fokus das komplette Re-Engineering mit dem Ziel einer Keep-the-Core-clean konformen, parallel zum SAP-Kern bestehenden Anwendung ist. Somit geht der Transformationsprozess deutlich über eine reine Code-Transformation hinaus. Nach Bewertung unterschiedlicher Anwendungen kann ein detaillierter IT-Bebauungs- und Modernisierungsplan erstellt werden. Wir gehen im Folgenden davon aus, dass in einem ersten Schritt genau eine Geschäftsanwendung zur Portierung identifiziert wurde.

2.2                Prepare

Während der Prepare-Phase muss zunächst die SAP BTP-Umgebung konfiguriert werden. Innerhalb der SAP BTP werden Global-Accounts und Sub-Accounts verwendet, um die gesamte Cloud-Umgebung hierarchisch zu organisieren und zu verwalten. In Sub-Accounts können Ressourcen wie Zugänge, Services etc. feingranuliert verwaltet werden, während Global-Accounts mehrere Sub-Accounts zusammenfassen. Als erste Aktivität muss eine Entscheidung darüber getroffen werden, wie viele Accounts und Sub-Accounts im Rahmen der SAP BTP verwendet werden sollen. In der Regel ist ein einzelner Global-Account für eine Organisation ausreichend. Bezüglich der Frage wie viele Sub-Accounts der Account nutzen soll, können unterschiedliche Ansätze verfolgt werden: Wir empfehlen als Minimum eine Trennung in drei Sub-Accounts, um die traditionelle Trennung in Entwicklung, Test und Produktion zu ermöglichen. Die Anzahl der Sub-Accounts kann sich gegebenenfalls weiter erhöhen, wenn spezifischere Anforderungen berücksichtigt werden, um beispielsweise eine Release-Linie und eine BugFix-Linie zu ermöglichen. Im Rahmen der Prepare-Phase sollte auch Klarheit über das Shared Responsibility Modell der SAP-BTP gewonnen werden [8]. Dieses regelt die Verantwortlichkeiten zwischen SAP als Cloud-Anbieter und der Organisation, welche die Cloud nutzt. Weitere, mit der Phase verbundene Aktivitäten sind die Entscheidung (1) für ein Preismodell sowie (2) für die Hardware-Dimensionierung der Sub-Accounts. Derzeit bietet SAP verschiedene Preismodelle an, die sich in fixen und festen Preisen für eine Reihe von subskribierbarer Services unterscheiden. Diesbezüglich bietet SAP Unterstützung für eine Kostenschätzung [9] sowie einen Leitfaden für die Dimensionierung der technischen Infrastruktur an [10]. Weiterhin sollte im Rahmen der Prepare-Phase die Nutzung des notwendigen Toolings vorbereitet werden. Zu diesem gehören beispielsweise die Nutzung von Eclipse ADT und Business Application Studio als Entwicklungsumgebung für ABAP und Fiori und das Einrichten von Verbindungen zu anderen SAP-Systemen mittels des Cloud Connectors.

2.3                Explore

In der Explore-Phase wird zunächst das bestehende Datenmodell analysiert und ein Konzept erstellt, wie es in ein RAP-konformes Datenmodell transformiert werden kann. Dabei muss beachtet werden, dass zwei Arten von Datenmodellen erstellt werden müssen: (1) Das Modell des oder der Geschäftsobjekte der Anwendung[1] inklusive VDM sowie (2) ein relationales Datenbankmodell. Das relationale Datenbankmodell wird zum Management von Daten in tabellenbasierter Form verwendet. Diese Daten werden dann mittels des Geschäftsobjektes auf einer höheren Abstraktionsebene verarbeitet. Somit definiert das Geschäftsobjekt, wie Daten in den API-Schnittstellen verarbeitet werden, während das relationale Datenbankmodell definiert, wie die Daten in Tabellen persistiert werden. Da das Geschäftsobjekt eine zentrale Rolle im gesamten RAP-Entwicklungsprozess spielt, empfehlen wir dringend dieses zuerst zu konzeptionieren. Das relationale Datenbankmodell kann gegebenenfalls aus der bestehenden Anwendung übernommen werden, ohne dass umfangreiche Änderungen erforderlich sind.

In der Explore-Phase muss außerdem der bestehende Code analysiert und ein Mapping der vorhandenen Features auf RAP-Standardfunktionalitäten durchgeführt werden. Dies ergibt sich, da in RAP enthaltene Standardfunktionen möglicherweise Features abdecken, die bisher durch eigene Implementierung umgesetzt wurden. Ein einfaches Beispiel für eine solche Funktion ist das Sperren einer Entität, um ein paralleles Verarbeiten zu verhindern: In der bestehenden Implementierung wurde dies möglicherweise unter Nutzung der bekannten enqueue/dequeue-Funktionen durchgeführt. In RAP kann die Sperrung von Entitäten und auch deren nachgelagerten Entitäten (bis hin zum gesamten Geschäftsobjekt) über Konfiguration implementiert werden. Schließlich müssen die bestehenden Benutzeroberflächen analysiert und ein Mapping auf ein Design gemäß SAP Fiori-Prinzipien durchgeführt werden. Hier ist zu beachten, dass in SAP BTP Fiori-basierte Technologien für Benutzeroberflächen verwendet werden. Es existiert keine Kompatibilität mit der SAP GUI.

2.4                Realize

Während der Realize-Phase wird zunächst das Backend der Anwendung re-implementiert. Dazu wird zunächst das in der vorherigen Phase entworfene Modell des Geschäftsobjektes und das relationale Datenmodell implementiert. Letzteres wird durch Definition von HANA-Datenbanktabellen implementiert, während für das Geschäftsobjekt die Entitäten mittels CDS-Views definiert werden. Die semantischen Beziehungen zwischen den Entitäten müssen ebenfalls in den CDS-Views abgebildet werden. Zusätzlich gilt es, bei der Implementierung die verschiedenen VDM-Schichten (siehe 1.2) für die einzelnen Entitäten zu berücksichtigen.

Neben der Erstellung des Datenmodells müssen auch die zuvor im Feature-Mapping definierten Features implementiert werden. Die Implementierung kann je nach Ergebnis des Mappings wie folgt durchgeführt werden: (1) Durch Hinzufügen von Annotationen zu den Entitäten des VDM mithilfe der vom RAP-Framework bereitgestellten Funktionalitäten oder (2) durch Entwickeln der Funktionen mit ABAP. Ersteres wird durch die Nutzung der beschriebenen Behavior Definitions ermöglicht; letzteres kann durch Übertragen des bestehenden Codes der lokalen Anwendung in die SAP BTP unterstützt werden. Für die Durchführung bietet sich beispielsweise die populäre Versionskontrollsoftware git an. Für git existiert ein Community-entwickelter, ABAP-fähiger Client [11]. Der übertragene Code kann jedoch wahrscheinlich nur als Basis für die Entwicklung dienen, da der in der SAP BTP eingesetzte ABAP-Dialekt ABAP for Cloud Development nicht alle ABAP-Funktionen unterstützt, die im klassischen ABAP verwendet werden. Beispielsweise werden die Schlüsselwörter OPEN/CLOSE DATASET, OPEN/CLOSE CURSOR oder SELECTION-SCREEN in ABAP for Cloud Development nicht unterstützt. Zusätzlich zu diesen Einschränkungen sind nicht alle Objekttypen und APIs, die in einer On-Premise Installation vorhanden sind, in der SAP BTP verfügbar. Beispiele dafür sind „klassische“ Reports, Transaktionen oder Suchhilfen. Um bei der Migration zu unterstützen, bietet SAP die Möglichkeit, Cloud-Readiness-Checks im Tool ABAP Test Cockpit (ATC) auszuführen.

Während der Realize-Phase müssen auch die Benutzeroberflächen in Form von Fiori-Apps entwickelt werden. Dies kann auf zwei Arten geschehen: (1) indem Benutzeroberflächen von Grund auf mit SAPUI5 im Freestyle-Ansatz entwickelt werden oder durch die Verwendung von Fiori Elements. Letzteres ist ein vereinfachter Ansatz für die Entwicklung von Apps, bei dem Benutzeroberflächen anhand archetypischer Floorplans ohne Programmierung konfiguriert werden. Um mehr Flexibilität zu ermöglichen, können die konfigurierten Floorplans um eine eigene Programmierung mit dem auf SAPUI5 basiertem Framework Flexible Programming Model (FPM)[12] erweitert werden. SAP empfiehlt auch beim Verfolgen des Freestyle-Ansatzes das Projekt-Setup mit Fiori Elements durchzuführen.

2.5                Deploy

Sobald das Backend und die Benutzeroberflächen konfiguriert oder programmiert sind kann die Anwendung im Rahmen der Deployment-Phase in den für Test und später Produktion vorgesehenen Sub-Accounts bereitgestellt werden: Die ABAP-Entwicklungsobjekte müssen in das BTP ABAP-Environment des jeweiligen Sub-Accounts transportiert und Entwicklungsobjekte für das User Interface in eine Lösung deployt werden, die ein Fiori Launchpad anbietet. Das Fiori Launchpad stellt die Laufzeit-Umgebung für SAPUI5-basierte Apps dar. In der SAP BTP können verschiedene Lösungen abonniert werden, die ein Fiori Launchpad anbietet. Dazu gehört etwa das Produkt Build Work Zone, Standard Edition. Über ein einfaches Setup hinaus sind für das Fiori Launchpad auch Federationslösungen denkbar. Durch diese wird der Inhalt aus verschiedenen Systemen in ein Fiori Launchpad zusammengeführt, um Usern eine einheitliche Nutzungserfahrung zu bieten. Dies ist insbesondere relevant, wenn Teile einer Systemlandschaft in der Cloud liegen, während andere On-Premise betrieben werden. Weiterhin sollten im Rahmen der Deployment-Phase die Integration einer Identity and Access Management (IAM) Lösung erfolgen, um Nutzer zu authentifizieren und ihnen Aktivitäten entsprechend ihrer Rollen zu ermöglichen. Auch kann in dieser Phase der Aufbau einer Continuous Integration and Delivery (CI/CD) Pipeline in Erwägung gezogen werden [13]. Hierzu empfiehlt es sich, frühzeitig Unit Tests sowie regelmäßige Prüfungen mit dem ATC zu etablieren, um die Codequalität nachhaltig sicherzustellen.

2.6                Run

In der Run-Phase sollte ein intensives Monitoring der Anwendung durchgeführt werden. Die Administrationsoberfläche SAP BTP Cockpit bietet hierfür verschiedene Funktionalitäten.  Darüber hinaus bietet die SAP BTP den Monitoring Service, der ohne Zusatzkosten subskribiert werden kann [14]. Dieser ermöglicht die Definition eigener Metriken und Alarme über die gesamte BTP-Landschaft hinweg. Er kann durch verschiedene Clients genutzt  oder über eine REST-basierte Programmierschnittstelle in eine eigene Monitoring-Lösung integriert werden. Zusätzlich kann zur detaillierten Überwachung einer einzelnen ABAP-Umgebung die mit der Umgebung ausgelieferte Health Monitoring App genutzt werden. Weiterhin kann die Administration der Cloud-Umgebung durch die bereitgestellte Cloud Management Service API erfolgen.

3.       Fazit

Im vorliegenden Beitrag haben wir beispielhaft gezeigt, welche Aktivitäten notwendig sind, um eine ABAP-Anwendung aus einer monolithischen oder hybriden Architektur herauszulösen und in der SAP BTP neu zu implementieren. Dies bringt eine Reihe von Vorteilen mit sich. Aus architektonischer Sicht ist eine vom SAP-Kern losgelöste Anwendung an der Keep-the-Core-clean-Strategie von SAP ausgerichtet, was Zukunfts- und Investitionssicherheit fördert sowie die Wartbarkeit und Upgrade-Fähigkeit des SAP-Kerns verbessert. Zugleich reduziert das Re-Engineering das Risiko technischer Obsoleszenz, da die Anwendung auf Basis moderner Technologien umgesetzt wird. Aus Entwicklungssicht erhöhen das RAP-Entwicklungsmodell und die darunter liegende Technologie die Flexibilität und Anpassungsfähigkeit an sich ändernde Geschäftsanforderungen, da neue Funktionen und Services schneller implementiert werden können. Durch die konsequente Nutzung der Funktionalitäten von RAP lässt sich zudem die Menge individuell geschriebenen Codes deutlich reduzieren und durch Konfiguration ersetzen, was den zukünftigen Entwicklungsaufwand senkt. Die Ausrichtung auf Microservices ermöglicht darüber hinaus eine nahtlose Integration sowohl mit dem SAP-Kern als auch mit Drittsystemen. Aus Sicht der Endnutzer führt die Nutzung von SAP Fiori zu einer verbesserten Benutzerfreundlichkeit und reduziertem Schulungsaufwand. Hinzu kommen die typischen Vorteile einer Cloud-Lösung wie reduzierte Hardware- und Infrastrukturkosten, vereinfachte Administration und dynamische Anpassung der Ressourcen an den tatsächlichen Bedarf. Zusammenfassend erweist sich die Anwendungsmodernisierung als ein zukunftsweisender Schritt, mit dem Unternehmen nicht zu lange warten sollten. Empfehlenswert ist es, frühzeitig und gegebenenfalls mit weniger komplexen Anwendungen zu beginnen, um Erfahrungen zu sammeln und den Weg für umfangreichere Modernisierungsprojekte zu ebnen.

Referenzen

[1] S. Orban, „6 Strategies for Migrating Applications to the Cloud”, AWS Executive in Residence Blog. Verfügbar unter: https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/

[2] SAP SE, „SAP Discovery Center”. Verfügbar unter: https://discovery-center.cloud.sap/serviceCatalog

[3] M. Pizzo, R. Handl und M. Zurmuehl, „OData Version 4.01. Part 1: Protocol“. Verfügbar unter: https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html

[4] K. Kopecz, Anwendungsentwicklung auf der SAP Cloud Platform – Das SAP Cloud Application Programming Model. Bonn: Rheinwerk, 2020.

[5] K. Bose, „New SAP Activate Roadmap for SAP Business Technology Platform”. Verfügbar unter: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/new-sap-activate-roadmap-for-sap-business-technology-platform/ba-p/13584237

[6] F. von Binzer, „msg.FIT“. Verfügbar unter: https://www.msg.group/de/loesungen/sap/msgFIT

[7] SAP SE, „Custom Code Migration Guide for SAP S/4HANA 2023”. Verfügbar unter: https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2023.000/en-US/CustomCodeMigration_EndToEnd.pdf

[8] P. Boch, „Shared Responsibility in SAP S/4HANA Cloud”, 2024. Verfügbar unter: https://assets.dm.ux.sap.com/webinars/sap-user-groups-k4u/pdfs/240215_shared_responsibility_in_sap_s4hana_cloud.pdf

[9] SAP SE, „Local Estimator“. Verfügbar unter: https://discovery-center.cloud.sap/estimator/?commercialModel=btpea

[10] SAP SE, „ABAP System Sizing“. Verfügbar unter: https://help.sap.com/docs/btp/sap-business-technology-platform/abap-system-sizing

[11] „abapGit“. Verfügbar unter: https://abapgit.org/

[12] SAP SE, „SAP Fiori Development Portal”. Verfügbar unter: https://ui5.sap.com/test-resources/sap/fe/core/fpmExplorer/index.html

[13] W. Lemaire, „DevOps in BTP with CI/CD and cTMS service“. Verfügbar unter: https://community.sap.com/t5/technology-blog-posts-by-members/episode-33-devops-in-btp-with-ci-cd-and-ctms-service/ba-p/14152328

[14] SAP SE, „Monitoring Service for SAP BTP”. Verfügbar unter: https://api.sap.com/package/SAPCPMonitoring/overview

[1] Im Folgenden wird aus Gründen der Lesbarkeit von genau einem Geschäftsobjekt ausgegangen