Cloud-First mit hybrider Integration im SAP-Umfeld

Um die Geschäftsziele bei Fielmann (Schwerpunkte sind eine Omnichannel-Strategie, E-Commerce, Digitalisierung und Internationalisierung) zu unterstützen, müssen wir unsere IT-Infrastruktur an vielen Stellen modernisieren und teilweise neu denken. Dabei stehen die Vertikalisierung der Organisation, eine agile Arbeitsweise und ein Cloud-First-Ansatz im Vordergrund.

Ziel unserer Initiative

Elementare Herausforderungen und zu lösende Fragestellungen sind bei uns:

• Inwieweit muss die Integration neu gestaltet werden?
• Welche Bestandteile einer typischen SAP-Landschaft und welche Standardkomponenten lassen sich dabei (wieder-)verwenden?
• Wie kann das Zusammenspiel mit Nicht-SAP-Lösungen besser realisiert werden?
• Welche organisatorischen und methodischen Veränderungen sind notwendig?

Anhand dieser Punkte möchten wir unsere Ideen skizzieren und die Erfahrungen bei der Umsetzung teilen. Dafür werden wir zu Beginn unsere Ausgangslage und anschließend unser Vorgehen sowie die Ziele der neuen Integrationsplattform und veränderten Arbeitsweise darlegen.

Bestehende SAP-Landschaft geht vollständig in die Cloud

Seit der Gründung der Fielmann AG sind wir sehr erfolgreich im stationären Geschäft. Diesen Erfolg konnten wir mit einer Reihe eigenentwickelter Systeme und SAP Module gut unterstützen. Im Laufe der Jahre hat die Komplexität, Anzahl und Vernetzung der Systeme zugenommen, mit dem Resultat einer heterogenen und unflexiblen IT-Landschaft. Als Reaktion darauf und aus der Notwendigkeit, sich dem Marktgeschehen anpassen zu können, wird verstärkt auf die Individualentwicklung von Cloud-basierten Microservices gesetzt. Im Folgenden liegt der Schwerpunkt auf dem SAP-Bereich, dabei betrachten wir die Integration zahlreicher interner und externer Systeme sowie auch cloudbasierten SaaS-Lösungen, die zunehmend relevant werden. Zwischen den SAP-Systemen und den Microservices kommunizieren wir aktuell überwiegend per KAF-KA, zukünftig werden REST APIs und der „Data Ocean“ eine größere Rolle spielen. Im Jahr 1995 sind wir mit ersten SAP FI-Systemen live gegangen. Kurz danach haben wir auch die Logistik mithilfe von SAP-Modulen unterstützt. Vor einigen Jahren wurde ein zusätzlicher Digitalisierungsbereich geschaffen, um die digitale Transformation und den E-Commerce schneller voranzubringen. In der Folge sind die Anforderungen an den Integrationsbereich deutlich komplexer geworden und es entstanden viele aus heutiger Sicht nicht mehr zielführende Schnittstellen gepaart mit einer Vielfalt an Tools unterschiedlicher Hersteller. Unsere bisherige Systemlandschaft (siehe Abbildung 1) ist geprägt durch eine historisch gewachsene Vielzahl an Werkzeugen mit unterschiedlichen Protokollen bei der Übertragung und eine starke Kopplung der Systeme und Prozesse untereinander. Wir binden heute eine Reihe von Systemen und Partnern an: Dazu zählen Lieferanten, Payment-Dienstleister, staatliche Stellen, nationale und internationale Produktionsstandorte oder unsere Niederlassungen. Da diese Schnittstellen über Jahre, oft unter Termin- und Kostendruck, entwickelt worden sind, ist eine heterogene Landschaft entstanden, zum Beispiel für die Kommunikation mit Lieferanten, mehrere SFTP-Server für einen sicheren Dateitransfer oder Tools für die Übertragung von EDIfact-Nachrichten. Das Zentrum der SAP-Integration bildet heute die Middleware „SAP Process Orchestration“, die die bestehenden SAP (R/3)- und die neuen S/4-Systeme miteinander sowie mit anderen Systemen verbindet. Mit den Microservices-basierten Systemen tauschen wir Events per KAFKA aus.

Herausforderungen und Startschuss für die Modernisierung

Die beschriebene Tool-Landschaft und die sehr operativ geprägte Arbeitsweise haben wenig Platz für eine Modernisierung gelassen und sind für die Herausforderungen der Zukunft nicht mehr leistungsfähig genug. In Kasten 1 sind die vier Themengebiete dargestellt, die die Kernpunkte unseres Modernisierungsvorhabens bilden. Mithilfe von neuen Technologien ermöglichen wir unseren Kunden beispielsweise eine virtuelle Anprobe von Brillen mittels modernster Augmented Reality-Technologie. Dabei bieten wir mit der Fielmann-Fit®-Technologie eine Weltneuheit: Sie vermisst das Gesicht anhand von über 18.900 Messpunkten und gleicht die anatomischen Daten mit der ausgewählten Sonnenbrille ab. Die Migration von Legacy-Systemen ist sehr zeitaufwendig. Um auch in Zukunft eine erfolgreiche Integration gewährleisten zu können, haben wir uns entschlossen, auf Basis des SAP-Cloud-Technologie-Stack und neuen S/4HANA-Systemen eine moderne, cloud- und eventbasierte API-Integrationslandschaft zu etablieren. Kasten 2 fasst die Ziele der neuen cloudbasierten SaaS-Integrationsplattform zusammen.
Basierend auf den genannten Eckpfeilern schaffen wir den „Zoo“ an Tools ab und lösen ihn durch eine moderne Integrationsplattform ab. Dabei rechnen wir nach dem Projekt mit signifikanten Einsparungen durch wegfallende Lizenz- und Wartungskosten, aber auch mit geringeren Kosten für den Betrieb und die Aktualisierung der Systeme mit neuen Versionen und Patches. Wir wollen vor allem schneller und professioneller bei der Entwicklung, dem Test und dem Go-live von neuen Integrationen werden. Das werden wir mit CI/CD, Test-Automatisierung und Standard-Patterns für wiederkehrende Probleme erreichen. Um schnell voranzukommen, haben wir uns entschieden, im Sinne des Prototypings zu experimentieren und anhand von Workshops und Proof of Concepts (PoC) zu bestimmten Themen strukturiert Erfahrungen zu sammeln.

Prototyping/PoC als Startpunkt für unsere Cloud Story

Der Weg in Richtung der neuen Integrationsplattform begann im Herbst 2020 mit einem [SPIKE], der als „Leuchtturm“ für unsere Initiative dient. Als Use-Case haben wir ein Monitoring für die Prozesse in den SAP-Systemen umgesetzt. Neben den nötigen Infrastruktur-Komponenten haben wir dafür einen Microservice mit dem Cloud Application Programming Model [CAP] gebaut. Dieser versorgt das Dashboard in unserem übergreifenden IT-Monitoring mit den Daten aus den SAP-Systemen (siehe Abbildung 2).
Das Dashboard wurde sehr schnell realisiert, auch da die Anbindung über den API Enterprise Hub [HUB] sehr einfach und unkompliziert implementiert werden konnte. Nach Abschluss des PoC hatten wir einen guten Eindruck von der Funktionsweise und dem Zusammenspiel der SAP BTP-Dienste. Somit war es uns erstmals möglich, das bisher etwas schwer zugängliche Monitoring der SAP-Systeme transparent und auf Augenhöhe mit den modernen Cloud-Komponenten zu exponieren. Zudem konnten wir damit aufzeigen, dass eine Zero-Trust-Lösung – ohne eine manchmal aufwendige VPN-und Firewall-Konfiguration – mit einem SAP-Backend-System möglich ist. In unserer Zielarchitektur werden wir so nicht nur schneller, sondern können unsere Backend-Systeme in einer hybriden Architektur auch optimal schützen – mit einem API-Management als zentralen Zugriffspunkt für SAP-Systeme. Mit dem Ansatz [ISA-M], der maßgeblich von der SAP entwickelt wird, haben wir eine technologisch offene Zielarchitektur entwickelt.

Mit dem ISA-M eine Strategie und konkrete Guideline entwickeln

Neben dem Test und dem Aufbau der Plattform haben wir basierend auf dem ISA-M unsere Integrationslandschaft der Zukunft skizziert. Dabei geht es nicht nur um technische, sondern auch um organisatorische Fragen und eine transparente und strukturierte Dokumentation.
Während die bisherige Dokumentation oft isoliert vorgenommen wurde, setzen wir heute auf eine transparente und gleichzeitig pragmatische Dokumentation für unsere cross-funktionalen Teams aus Fach- und IT-Experten. Wir haben mit Jira und Confluence eine Lösung gebaut, die eine Schnittstelle von der Anforderung bis zum Go-live sowie im Betrieb dokumentiert. Dabei werden Ansprechpartner und strukturierte Daten zusammen mit dem Lifecycle in Jira erfasst und die Dokumentation in Confluence abgelegt. Unser Ziel ist es, das Level „Integration Best Practices“ (siehe Abbildung 3) bis Ende 2022 zu erreichen. Dabei liegen die Schwerpunkte auf der Bereitstellung klarer und standardisierter Patterns für die Umsetzung unterschiedlicher Anforderungen sowie auf einer modernen Vorgehensweise, Integrationen zu entwickeln, zu testen und zu betreiben.
Der Fokus liegt ganz bewusst nicht auf der schnellen Migration aller Schnittstellen in die Cloud, sondern darauf, zuerst eine solide Plattform zu bauen und Themen wie CI/CD, Git als zentrales Repository und Möglichkeiten der Automatisierung zu etablieren. Erst wenn wir diese Plattform haben, werden wir die Masse der Schnittstellen in der Cloud aufbauen. Im höchsten Level des ISA-M werden Ideen eines Integration Self Service bzw. einer Shared Developer Community angesprochen, die für uns sehr spannend klingen. Diese und weitere Themen werden wird nach der Etablierung der Integrationsplattform angehen. Ein zentrales Pattern dabei ist die Nutzung eines API-Managements für alle internen und externen Zugriffe: Damit wird erreicht, dass das Ziel einer Schnittstelle immer ein API-Endpunkt ist, um dort unter anderem Authentifizierung und Autorisierung zentral sicherzustellen und ein Developer-Portal mit zentraler Dokumentation zur Verfügung zu haben. Die Open-API-Spezifikation und die direkten Testmöglichkeiten im SAP API Enterprise Hub ermöglichen einen schnellen und einfachen Zugriff auf SAP-Daten, Die Komplexität und die teilweise nicht sprechenden Begriffe der SAP-Welt werden für den Aufrufer in der Cloud-Integration abstrahiert. Mit diesem Pattern orientieren wir uns an der Cloud-native Entwicklung und modernen Architekturprinzipien.
Im Zielbild (siehe Abbildung 4) stellt der sogenannte SAP Cloud Connector (SCC) die Verbindung zwischen den Backend-Systemen und den Accounts in der Cloud her. Der SCC bietet dabei umfassende Möglichkeiten der Konfiguration, um den Zugriff auf die Backend-Systeme zu steuern. Technisch wird die Kommunikation von „innen nach außen“ aufgebaut und damit die Funktionalität eines Reverse Proxy abgedeckt. Der Web Dispatcher im internen Netzwerk wird für das Load Balancing und als weitere Security-Instanz genutzt. In der SAP Cloud werden die APIs über ein Portal bereitgestellt – als API Gateway dient eine Lösung, die technisch Apigee von Google als Grundlage hat. Sollten Konvertierungen nötig sein, werden diese in der Cloud-Integration umgesetzt.

Fallbeispiel: Umsetzung der Integration im Order-to-Cash-Prozess

Mit den SAP-Systemen bilden wir eine Reihe von Capabilities rund um das Thema Order-Fulfilment ab. Wir erhalten von verschiedenen Systemen bzw. Verkaufskanälen Kundenbestellungen in ganz unterschiedlichen Formaten. Das sind zum Beispiel Bestellungen für Kunden aus dem Ausland, Filialbestellungen oder für unterschiedliche Warengruppen, für die zusätzlich Strecken-Bestellungen bei Lieferanten ausgelöst werden müssen. Durch die S/4 HANA-„Clean Core“-Philosophie können wir wartungsaufwendige SAP-Eigenentwicklungen verringern und damit insgesamt die Effizienz deutlich steigern. Der „Clean Core“-Ansatz meint, dass im SAP-Backend die SAP-eigenen Standardprozesse bedient und möglichst selten durch Erweiterungen ergänzt werden. Die kundeneigene Logik wird in der SAP BTP implementiert. Der Vorteil dieses Ansatzes für unser Vorhaben ist, dass die SAP-Backends „sauber“ bleiben, somit effizienter sind, einfacher gewartet und bedient werden können. Die Individualentwicklung in der SAP BTP [BTP] bietet unter anderem den Vorteil, dass moderne Programmiersprachen und Konzepte eingesetzt werden können. Mit der Inbetriebnahme (siehe Tabelle 1) unserer neuen Integrationsplattform beginnt jede Entwicklung einer Schnittstelle mit einem Eintrag in einem Jira-Formular, mit dem wir wichtige Informationen direkt abfragen, um Ansprechpartner zu haben und auch direkt ein Integration-Pattern ableiten zu können. Im dargestellten Szenario haben wir für die eingehenden Kundenbestellungen eine Open-API-Spezifikation erstellt, die unsere Entwickler via API Enterprise Hub einsehen und mit eigenen Beispielen direkt testen können. Dabei handelt es sich um ein generisches Format und keine unterschiedliche Struktur pro System oder spezifischem Use-Case. Im API-Management setzen wir umfangreiche Security Policies um, da wir uns mit der Lösung in einer Zero-Trust-Umgebung ohne VPN befinden. In der Cloud-Integration erstellen wir die nötigen Konvertierungen in die jeweiligen SAP-Formate und ermitteln ggf. noch weitere Werte, damit der Beleg in SAP gebucht werden kann. Damit bleibt das SAP-System sehr standardnah. Je nach Anforderung kann über eine Call-Back-URL der Status der Verarbeitung über eine API abgerufen werden.

Zusammenfassung und Überblick

Wir haben die Initiative für eine neue Integrationsplattform gestartet, da wir mit der gewachsenen Tool-Landschaft und einer fehlenden Automatisierung an eine Grenze gestoßen sind. Um den Aufwand für den Betrieb zu reduzieren und eine zukunftsfähige Lösung zu implementieren, haben wir mit der ISA-M-Strategie eine moderne Architektur, Standard-Patterns und neue Prozesse entwickelt. Technisch haben wir Erfahrungen in einem Trial mit einem konkreten Use-Case gesammelt. Die Plattform entwickeln wir iterativ und inkrementell weiter. Parallel nehmen wir neue Schnittstellen live, um im Betrieb Erfahrungen zu generieren. In den SAP-Backend-Systemen stellen wir in Zukunft die Schnittstellen auf Events und APIs um. Damit können wir die Vorteile der Integrationsplattform für eine flexible und performante Integration optimal nutzen. Zusätzlich zu (a)synchronen APIs werden wir auch Push-Events aus den Backend-Systemen über die neue Plattform an Empfängersysteme verteilen. Dadurch wird ein dauerhaftes Polling, zum Beispiel für den Abruf eines Auftragsstatus, verhindert. Der beschriebene Ansatz ist sicher nicht neu, aber für die Anbindung und Kapselung von SAP-Systemen sehr gut geeignet. Dadurch gewinnen wir für die Zukunft deutlich an Flexibilität: Wann immer Services durch neue Systeme oder Lösungen in der Cloud abgelöst werden, erfolgt die Änderung für das aufrufende System transparent in der Plattform. Wir sind davon überzeugt, dass wir so die Vorteile eines integrierten SAP-Systems mit effizienten und erprobten Standardprozessen optimal nutzen können und gleichzeitig in der Lage sind, unsere Microservice-Landschaft über die beschriebenen Technologien effizient zu integrieren.

Ausblick

Technisch bietet der Ansatz sehr viel Potenzial für eine optimale „Integration der Zukunft“. Für eine Migration auf die Cloud-basierte Plattform mit der dazugehörigen Änderung von Arbeitsabläufen müssen neue Konzepte, Programmiersprachen sowie agile Methoden gelernt und verwendet werden. Dafür bedarf es neben einer fachlichen Weiterbildung eine Bereitschaft zu einer DevOps-Kultur, um zum Beispiel „you build it, you run it“ mit Leben zu füllen. Wenn Daten „das neue Gold“ sind, dann ist eine funktionierende und effiziente sowie effektive Integrationsplattform nicht nur das Fundament für innovative Lösungen, sondern gleichzeitig auch der Enabler für Anforderungen in der Zukunft. Daher sind wir der Überzeugung, dass jetzt für viele Unternehmen und Teams im SAP-Bereich der Zeitpunkt gekommen ist, sich ernsthaft mit der Cloud und innovativen Integrationslösungen zu beschäftigen, Erfahrungen zu sammeln und den Mitarbeitern die Chance zu geben, die Technologien kennenzulernen.
Der Erfolg hängt sicher stark von der Unterstützung und der Bereitschaft für „Neues“ im Management der SAP-Bereiche in Unternehmen ab, wo in der Vergangenheit viel auf Kosten und Effizienz geschaut wurde. Eine große Chance kann dabei auch der unternehmensübergreifende Austausch zu Ideen und Erfahrungen sein, auf den wir uns sehr freuen.

Weitere Informationen

[BTP]
BTP, siehe:
https://www.sap.com/germany/products/business-technology-platform.html

[CAP]
SAP Cloud Application Programming Model, siehe:
https://cap.cloud.sap/docs

[HUB]
Innovation Insight: The Digital Integration Hub Turbocharges Your API Strategy, Gartner, 26.6.2018, siehe:
https://www.gartner.com/en/documents/3880263/innovation-insight-the-digital-integration-hub-turbochar

[ISA-M]
K. Ahsen, New Version of the SAP Integration Solution Advisory Methodology Template released, 14.5.2020, siehe:
https://blogs.sap.com/2020/05/14/new-version-of-the-sap-integration-solution-advisory-methodology-template-released

[SPIKE]
Wikipedia, siehe:
https://en.wikipedia.org/wiki/Spike_(software_development)