![IBacademy_Logo_blau[496]](https://www.ibsolution.com/hs-fs/hubfs/IBacademy_Logo_blau%5B496%5D.jpg?width=200&name=IBacademy_Logo_blau%5B496%5D.jpg "IBacademy_Logo_blau[496]"){kind=logo}
Szenarioabhängige Entscheidungsmuster helfen Unternehmen dabei, den richtigen Migrationsansatz für ihre Schnittstellenarchitektur zu finden. Bei reinen On-Premise-Schnittstellen liegt die Middleware, mit der sich Integrationsszenarien abbilden und implementieren lassen, auf einem lokalen Server und hat keinen direkten Kontakt zur Cloud. Hybride Schnittstellenszenarien verwenden einerseits On-Premise-Middleware und andererseits cloudbasierte Middleware, um komplexe Integrationsszenarien zwischen unterschiedlichen Systemlandschaften (on-premise und Cloud) abzubilden. Reine Cloud-Integrationsszenarien sind dadurch gekennzeichnet, dass sich die Middleware vollständig in der Cloud befindet und es keinen On-Premise-Server mehr gibt, auf dem die Schnittstellen-Middleware – zumindest direkt – interagiert.
Tools für On-Premise und Cloud
Angesichts dieser Möglichkeiten stellen sich Unternehmen die Frage, welche Unterschiede zwischen den verschiedenen Szenarien bestehen, in welchen Fällen welche Architektur eingesetzt werden sollte und welcher Migrationsansatz sich am besten eignet. Für einen direkten Vergleich dient uns im Folgenden SAP Process Orchestration (SAP PO, Version 7.5, Single Stack Java) als On-Premise-Middleware, während SAP Cloud Platform Integration (CPI) als Cloud-Middleware fungiert.
Die erste Version der On-Premise-Middleware SAP PO (damals SAP XI) kam 2002, also vor mehr als 15 Jahren, auf den Markt. Es handelt sich um ein bewährtes und etabliertes Tool, das kontinuierlich weiterentwickelt wurde. Auch künftig wird SAP das Produkt unterstützen und warten. SAP CPI ist hingegen erst seit wenigen Jahren verfügbar. In dieser Zeit hat sich die Middleware im Cloud-Servicebereich bereits als vertrauenswürdiges Werkzeug etabliert.
Einer der prägnantesten Unterschiede zwischen den beiden Integrationsprodukten ist der Maintenance-Lifecycle. Für SAP CPI werden automatisiert alle zwei Monate neue Releases (zunächst für den Dev-Tenant) mit wesentlichen Verbesserungen veröffentlicht. Zudem müssen sich die Nutzer dieses Service nicht weiter um Serverbetrieb, Stabilität und Ausfallsicherheit kümmern, da der Service von Cloud-Plattformen der SAP bezogen wird. Die Middleware-Version SAP PO 7.5 wird bis 2024 SAP-seitig gewartet. Die Content- und Verbesserungsbereitstellungen durch Service- oder Support-Packages sind im Vergleich zu SAP CPI starrer gestaltet. Außerdem liegt die Verantwortung für das Einspielen der Updates und Upgrades bei der unternehmensinternen IT.
Relevante Faktoren für die Entscheidung
Die Middlewares SAP PO und SAP CPI bieten in verschiedenen Bereichen jeweils spezifische Vor- und Nachteile. Klar definierte Best Practices von SAP helfen bei der Entscheidungsfindung. Insgesamt ist die SAP-Strategie eindeutig auf Cloud-Produkte und Cloud-Services ausgerichtet. Daher werden perspektivisch in den kommenden Jahren vermehrt rein cloudbasierte Systemlandschaften zum Einsatz kommen. Diesen Trend gilt es zu beachten, wenn Unternehmen ihre strategischen Ziele mit Blick auf IT-Transformation und Digitalisierung formulieren.
Die Entscheidung über die richtige Migrationsstrategie sollte idealerweise verschiedene Aspekte berücksichtigen: strategische Ziele, Größe des Unternehmens, Timelines von Projekten, Budgetplanung und Digitalisierungsvisionen. Zusätzliche Herausforderungen, denen sich Unternehmen bei der Migration stellen müssen, sind das Lizenzmodell des neuen Service SAP CPI und die Einführung der SAP Cloud Platform, die diesen Service anbietet.
Unterschiedliche Preismodelle
Das Lizenzmodell der On-Premise-Lösung SAP PO stützt sich auf die genutzten Prozessoren der PO-Maschine und der erforderlichen Transkationen sowie auf die Anzahl der Nutzer. Das Cloud-Lizenzmodell ist im Vergleich dazu flexibler und skalierbar aufgebaut. Es basiert entweder auf einer verbrauchsabhängigen oder auf einer abonnementabhängigen Preisgestaltung. Um den Service zu nutzen, ist außerdem eine Lizenz für die SAP Cloud Platform erforderlich, da sie den Service der SAP CPI erst zur Verfügung stellt.
Darüber hinaus sollten sich Unternehmen auch mit den Aspekten IT-Sicherheit, Aufbau einer neuen Cloud-Landschaft und Integration in multidimensionale Landschaften auseinandersetzen. Gegebenenfalls gibt es eine Migrationsphase, in der parallele Systeme in der Produktivumgebung laufen. Das hat den Vorteil, dass man die Verantwortung für den Server abgibt und sich keine Gedanken mehr um Wartung und Server-Uptime machen muss.
Flexibel, skalierbar, günstig
Cloudbasierte IT-Systemlandschaften und ihre Schnittstellen bringen viele Vorteile, zum Beispiel einfache Skalierbarkeit, geringere Kosten, zentral geregelter Zugriff, flexible betriebswirtschaftliche Agilität und natürlich den Standard-Content. Es gibt für die meisten SAP-Services und SAP-Produkte, die über die SAP Cloud Platform genutzt werden, Standard-Content, den SAP CPI bereitstellt. Er lässt sich für verschiedene Integrationsszenarien einsetzen, was immensen Entwicklungsaufwand spart. Zudem lässt sich der Standard-Content individuell anpassen und erweitern (Customizing).
SAP PO bietet mit mitgelieferten Nebenprodukten wie Business Rules Management (BRM) und Business Process Management (BPM) eine Möglichkeit, Geschäftsprozesse vollständig abzudecken. Das vergleichbare Pendant bei SAP CPI heißt Cloud Platform Workflow und lässt sich ebenfalls über die SAP Cloud Platform nutzen.
Szenario individuell wählen
Um herauszufinden, welche Middleware zum jeweiligen Szenario passt, sollte sich ein Unternehmen folgende Fragen stellen:
-
Brauche ich überhaupt Cloud-Schnittstellen?
Für eine verlässliche Antwort müssen Unternehmen ihre Systemlandschaft(en) genau kennen und wissen, ob und welche Cloud-Produkte oder Cloud-Services sie nutzen, die mit anderen Systemen interagieren, also Daten austauschen. Solche Cloud-Services können beispielsweise SAP SuccessFactors, SAP Ariba, SAP S/4HANA Cloud oder SAP C/4HANA sein. Zudem müssen die Unternehmen klären, wie viele Cloud-Schnittstellen sie im Vergleich zu eventuell bereits vorhandenen On-Premise-Schnittstellen benötigen.
-
Nutze ich bereits On-Premise-Schnittstellen?
Hier sollte eine rasche Antwort möglich sein, denn in der Regel gibt es in jedem Unternehmen Integrationsszenarien, die systemübergreifende Schnittstellen benötigen, sofern das Unternehmen Produkte für interne Prozessabläufe nutzt. Falls diese On-Premise-Schnittstellen allerdings auch mit Cloud-Systemen kommunizieren müssen, gilt es abzuwägen, welche Middleware-Produkte (on-premise, aus Cloud-Services bezogen oder hybrid) genutzt werden sollen.
Eine endgültige, zukunftssichere Entscheidung hinsichtlich der Migration von Schnittstellen zu treffen, ist nicht einfach, sondern erweist sich als komplex. Unternehmen müssen perspektivisch planen und vorausschauend handeln, um die Anforderungen der kommenden Jahre abzudecken. Die gewählte IT-Strategie muss auch zur aktuell genutzten Middleware passen.
Übersicht der Möglichkeiten von Multi-Systemlandschaften (Quelle: SAP SE)
Drei Fallbeispiele
Die folgenden Beispiele veranschaulichen drei unterschiedliche Fälle und zeigen auf, unter welchen Voraussetzungen welches Produkt oder welcher Service empfehlenswert ist, um Lizenzkosten zu sparen und auch IT-strategisch sicher für die Zukunft aufgestellt zu sein. Wann ergibt es Sinn, auf eine cloudbasierte Schnittstellenumgebung zu verzichten? Wann sollten Unternehmen einer reinen Cloud-Umgebung, wann einer hybriden Integrationslandschaft den Vorzug geben?
Wir betrachten ein Unternehmen, dessen Systemlandschaft(en) und eingesetzte Systeme, in welcher Systemumgebung diese laufen und wie zukünftig gehandelt werden soll.
Beispiel 1
Im Unternehmen wird perspektivisch mehr als ein Drittel aller IT-Systeme in einer cloudbasierten Systemlandschaft laufen. Mit einem solchen Szenario haben in der Regel Mittelständler zu tun. Es gibt die Option, hybride Systemlandschaften mit hybriden Schnittstellenprodukten (Middlewares) zu integrieren. So lautet auch die Empfehlung von SAP für das skizzierte Fallbeispiel. Es können zwei Integrationsplattformen (hybrid) koexistieren, zum Beispiel SAP PO und SAP CPI.
Auf jeden Fall sollte das Unternehmen die operationellen Kosten im Blick behalten, denn das hybride Integrationsszenario nutzt einerseits SAP PO für die On-Premise-Schnittstellen und andererseits SAP CPI für die Cloud-Schnittstellen. Der Vorteil ist, dass es je Systemkategorie ein Middleware-Produkt und eine klare Kapselung zwischen ihnen gibt.
Einer besonderen Betrachtung bedürfen die bereits entwickelten On-Premise-Schnittstellen bzw. die Frage, wie viele es davon im Unternehmen gibt. Falls es nur wenige Schnittstellen sind, lohnt sich im Hinblick auf die Betriebskosten ein hybrides System nicht. Falls aber schon mehrere On-Premise-Schnittstellen vorhanden sind und noch mehrere Cloud-Schnittstellen hinzukommen, spricht nichts gegen ein hybrides Integrationsszenario.
Beispiel 2
Im Unternehmen wird perspektivisch weniger als ein Drittel aller IT-Systeme in einer cloudbasierten Systemlandschaft laufen. Unter diesen Umständen lohnt weder der Aufwand einer hybriden Systemlandschaft noch die Migration in die Cloud. Die Kosten sind im Verhältnis zum Endergebnis zu hoch, sodass das Unternehmen von einer solchen Architektur nicht profitiert. Das Unternehmen sollte allerdings darauf achten, mit der aktuellsten Version von SAP PO zu arbeiten, da fast jedes Unternehmen in Zukunft auf cloudbasierte Systemlandschaften upgraden muss/sollte.
Beispiel 3
Alle Systeme des Unternehmens werden in Zukunft in einer cloudbasierten Systemlandschaft laufen. Diesen Transformationsansatz verfolgen häufig kleinere Gesellschaften, die bisher keine umfangreiche Systemlandschaft nutzen. Deswegen können sie diese Art der Migration flexibler, dynamischer und unabhängiger gestalten.
In unserem Beispiel geht es um die Ablösung von SAP PO durch SAP CPI. Da man aufgrund des Aufwands und der Ressourcen nicht alle produktiven Schnittstellen gleichzeitig in die SAP Cloud migrieren kann, wird es für einige Zeit ein hybrides Integrationsszenario geben. Es wird empfohlen, ein sogenanntes Phasenmodell für die Migration zu nutzen, um die On-Premise-Schnittstellen Schritt für Schritt durch Cloud-Schnittstellen zu ersetzen.
Schließlich wird die On-Premise-Lösung SAP PO vollständig abgelöst. Die Betriebskosten werden sich dadurch drastisch verringern. Es kommt kurzzeitig zwar zu einem höheren finanziellen Aufwand – wenn beide Produkte koexistieren –, allerdings wird sich dieser nach dem Abschluss der Cloud-Transformation schnell amortisieren.
Fazit: Genaue Analyse muss sein
Die Migration von On-Premise-Schnittstellen in die Cloud erweist sich als komplexes Thema, bei dem zahlreiche Abhängigkeiten beachtet werden müssen. Es gibt keinen Königsweg für die Migration. Vielmehr kommt es bei der Frage, wann wie migriert werden soll und welche Produkte und Services oder welche Systemarchitektur dafür infrage kommen, sehr stark auf die individuelle Ausgangslage des Unternehmens an.
Auch wenn cloudbasierte Schnittstellen viele Vorteile mit sich bringen, lohnt es sich, den besten Migrationsprozess und die Arbeitslast, die er mit sich bringt, gewissenhaft zu ermitteln. Ebenso müssen Themen wie Datenschutz, Sicherheit, Servicequalität, Einsparpotenzial und Integrationskomplexität in die Abwägung einfließen, damit es bei der Umstellung auf Cloud-Schnittstellen nicht zu Verzögerungen kommt, unter denen dann die Performance des Unternehmens leidet. Die IT-Strategie muss an die Migration angepasst werden.
