SAP S/4HANA: Neuer Architektur-Blueprint für Eigenentwicklungen

Viele Unternehmen wollen auf SAP S/4HANA wechseln. Doch die Migration der oft mehreren hundert Eigenentwicklungen bereitet ihnen Kopfzerbrechen. Was tun?

Roman Bartlog bemüht eine Analogie aus der Medizin, um klarzumachen, wie die künftige IT-Architektur in den Konzernen in den nächsten Jahren aussehen könnte. Das Herz sorgt dafür, dass das Blut in die Adern gepumpt wird und sämtliche Extremitäten bis in den kleinen Finger durchblutet sind. Arme und Hände sind wendig und flexibel. Sie sind in der Lage, sich auf viele Aufgaben einzustellen - Whatsapp-Nachrichten zu tippen, Geigenbögen zu führen, Türen aufzuschließen. Das Herz ist für den Capgemini-Experten Bartlog SAP S/4HANA - ein Standard, der stabil bleiben sollte. Die Arme und Hände hingegen entsprechen in seinem Vorschlag einer Microservice-IT-Architektur, die flexibel die Funktionalitäten von SAP S/4HANA bereichern. Der Architekturansatz: Sämtliche Eigenentwicklungen aus der Vergangenheit werden in weit verbreiteten Programmiersprachen wie etwa Java und JavaScript auf dem 'XSA-Server ' (kurz für SAP HANA Extended Application Services, Advanced Model) betrieben. SAP S/4HANA bleibt davon unberührt (siehe Grafik).

Grafik: Capgemini

SAP S/4HANA plus Microservices: Die Vorteile der Architektur

1. Eigenentwicklungen im XSA-Server weiter nutzen

Viele Unternehmen haben ihre Prozesse über Jahre hinweg immer wieder weiter entwickelt und spezialisiert. Manche ließen sich nicht im ERP-Standard abbilden. So entstanden nicht selten mehrere hundert Eigenentwicklungen, die bei einem Wechsel auf SAP S/4HANA nicht ohne weiteres weiter verwendet werden können und in vielen Fällen an SAP S/4 HANA angepasst werden müssen. 'Dieser Aufwand kann dafür genutzt werden, die Entwicklungen aus dem Core heraus zu lösen und die Anwendung in eine moderne Programmiersprache wie Java zu überführen', sagt Bartlog. Der Vorteil: Dadurch, dass die Anwendung auf dem XSA-Server läuft, wird sie vom Core unabhängig - und damit agiler. Zudem operieren die Anwendungen auf dem XSA-Server und SAP S/4 HANA auf der gleichen Datenbanktechnologie, was den Datenaustausch und Zugriff erleichtert. 'Auf Datenbankebene können über die SAP-Technologie Smart Data Integration Zugriffe auf Daten gewährt werden, ohne diese kopieren zu müssen', erläutert SAP-Experte Bartlog einen weiteren Vorteil. Zudem kann auf Applikationsebene über das offene Format für den Datenaustausch Open Data Protocol (OData) kommuniziert werden.

2. On-Premise-Ansatz als zusätzliche Option

Für viele Unternehmen ist es ein großer Schritt, auf SAP S/4HANA zu wechseln. Die SAP Cloud Platform gleich mit zu nutzen und damit auch direkt bestehende Eigenentwicklungen in die Cloud mitzunehmen, kommt für manche Unternehmen aufgrund der aktuellen IT-Strategie nicht in Frage. So werden selbst entwickelte Zusatzapplikationen etwa als unternehmenskritisch angesehen. Der SAP-HANA-basierte Applikationsserver ermöglicht nicht nur den Betrieb der bestehenden Eigenentwicklungen, sondern bietet die Chance, neue Lösungen zu entwickeln und für den späteren Cloud-Betrieb vorzubereiten. Er überbrückt sozusagen die Zeit, die ein Unternehmen benötigt, um sich eventuell später für eine Cloud-Strategie zu entscheiden und die SAP Cloud Platform einzusetzen.

3. Updates von SAP S/4HANA lassen sich vorab testen

Im Jahrestakt bringt SAP neue Releases für SAP S/4HANA heraus, die 'on premise' - also fest installiert - bei Kunden betrieben werden. Darin enthalten sind viele Innovationen, doch benötigt der Kunde nicht unbedingt alle Features. Einzelne Neuerungen kann der Kunde vorab auf dem XSA-Server testen und - etwa nachdem er die Funktionen ein Jahr lang getestet hat und sie nachweislich Stabilität und Mehrwert bringen - risikofrei in das SAP-S/4HANA-System einspielen.

4. Architektur der zwei Geschwindigkeiten abgebildet

Innovationszyklen für SAP S/4HANA sind in festen Zeitfenstern geplant und folgen nicht den aktuellen Anforderungen in den Unternehmen. Die Fachbereiche jedoch kennen die veränderte Nachfrage nach Produkten und drängen die IT, schnell und flexibel Lösungen zu schaffen. SAP S/4HANA dient als stabiler Kern, der als Standard beibehalten wird. Microservices - abgebildet auf dem XSA-Server - können jederzeit und auf Anforderungen aus dem Fachbereich modifiziert und neu geschaffen werden. Da SAP HANA die einheitliche Datenbasis für SAP S/4HANA und die Microservices bietet, ist es in dieser Architektur möglich, einerseits die Daten aus dem 'Herz' zu nutzen, als auch schnelle neue Lösungen zu bauen.

5. Microservices-Architektur-Pattern einsetzbar

Nach einer Definition von Martin Fowler entstehen Microservices idealerweise in eigenverantwortlichen Teams, die das User Interface, die Middleware und die Datenhaltung in der Entwicklung berücksichtigen. Diese Agilität ist auch in diesem Ansatz möglich. Mit einem Unterschied: Die Datenbasis ist mit SAP HANA einheitlich.

6. Wechsel auf SAP Cloud Platform möglich

Der Anwender lernt mit Hilfe des XSA-Servers, Microservices selbst zu entwickeln und auf SAP-HANA-Basis zu nutzen. Ist das erste große Transformationsprojekt SAP S/4HANA bewältigt, kann er nun mit seinen Erfahrungen, die er bereits im agilen Teil der Architektur mit Microservices gemacht hat, auch in der Cloud umsetzen, und dies mithilfe der SAP Cloud Platform. 'Unternehmen, die zunächst auf dem XSA-Server Microservices entwickeln, sind zudem gut darauf vorbereitet, mit diesem Vorgehen in die SAP Cloud Platform zu migrieren', meint SAP-Experte Bartlog.

7. Nicht-SAP-Systeme sind integrierbar

Neben SAP S/4HANA und den Microservices auf dem XSA-Server ist es möglich, eine dritte Säule für Nicht-SAP-Anwendungen zu integrieren. Die Architektur bietet also die Möglichkeit, eine Single Source of Truth zu etablieren. Siehe auch: Warum SAP HANA auch zu Java-Umgebungen passt.

Weitere Informationen:

Erfahren Sie mehr vom 26. bis 28. September 2017 auf dem diesjährigen DSAG-Jahreskongress in Bremen oder während der SAP S/4HANA Roadshow Series.