Nur wenige Fragen im Fiori-Umfeld sorgen, zumindest in meinem Fall und Umfeld, für so viele Diskussionen und Differenzen wie die Frage der Architektur der SAP-Landschaft bezüglich SAP Gateway. Nie hätte ich vor einigen Jahren gedacht, dass dieses Thema doch so entscheidend ist. Nicht die Frage “Wie geht SAPUI5?” oder “Mache ich das mit Fiori Elements oder native Ui5”, sondern die Frage “Hub oder Gateway” sind die Fragen die am meisten gestellt werden. Es ist einfach ein abstraktes Thema und schwer greifbar und hat einen wahnsinnigen Impact auf die gesamte Fiori-Strategie, kurzfristig wie langfristig. Es gab mal eine Zeit da meinte man einen weg gefunden zu haben. Dieser Weg hieß Hub-Deployment. Diese Zeit war aber vor S/4HANA und vor der Ankündigung seitens SAP spätestens ab 2027 den “FES für S/4HANA” bereitzustellen und den Frontend Server 6.0 auslaufen zu lassen. Ätsch Hub-Deployment und jahrelange Arbeit vieler Kunden eine sinnvolle Fiori-Architektur aufzubauen.
Aber vielleicht merkte die SAP doch was in den Unternehmen aus dem Hub-Deployment alles so für Probleme und Fragestellungen resultierten. In der Retrospektive wurde diese frage nämlich immer nur aus technischer Sicht angegangen. “Frontend von Backend unabhängig patchen” oder “Security” waren, einfach formuliert, Vorteile des Hub-Deployments. Gerade Ersteres verpuffte in der Praxis aber schnell, stand doch in den Meisten Frontend-bezogenen Hinweisen einfach gesprochen sowas wie “Denk dran auch dein Backend entsprechend nachzuziehen”… na toll. Es ergaben sich aber plötzlich ganz andere Fragestellungen. Diese waren auch prozessualer und organisatorischer Natur. Sowas merkt man immer erst wenn es soweit ist. Die Frage ist wie man die entsprechenden Gateway-Systeme in die jahrelang gewachsenen SAP-Landschaften integriert? Ein Gateway-Strang für alle Systeme als “Single-Frontend” oder doch für vielleicht jeden Produktstrang eine analoge Gateway-Landschaft? Man darf nicht vergessen. Verschiedene Landschaften haben unterschiedliche Patchzyklen, Entwickler, Systemadministratoren, Auslieferungsprozesse, Produktverantwortliche, uvm. Je mehr dieser Variablen eine Gateway-Landschaft abdecken muss desto unflexibler und starrer. Also doch pro Produkt-/Systemstrang eine Landschaft? Sicher flexibler aber auch mit einer Menge Mehrarbeit verbunden. Es bedarf eine menge Abstimmungsaufwand gerade der Verantwortlichen der Gateway-Landschaften alle Spezifika der Backend-Stränge einzufangen. Die Frage ist dann: Was machen die Basis-Admins und Entwickler bzw. Berater. Sind die nur für die Gateways ihrer analogen Backends zuständig oder für alle? vielleicht hat man nur einen SAPUI5-Entwickler der für mehrere Stränge entwickeln soll? Die Backend-Entwickler sind aber in bestimmten Prozessen und Strukturen ihres entsprechenden Strangs verhaftet.
Weiterhin vernachlässigen darf man auch bestimmte Faktoren nicht wie Auslieferungsprozesse, z.B. eine Anbindung an ChaRM, die über ein Hub-Deployment eine nicht zu vernachlässigende Umstrukturierung erfordern. Auch genauso die vorhin angesprochene Patchplanung, die jetzt vielleicht mehrere Systeme enthält. Genauso steigt die Komplexität der Landschaft. Und sind wir ehrlich diese Landschaften sind heterogen und ohne separate Gateway-Systeme schon eine Herausforderung.
Für mich alles Argumente der SAP-Aussage zu folgen und zu sagen: Wenn möglich Embedded!
Aber noch ist ja nicht 2027 und noch hat man in vielen Unternehmen ein Hub-Deployment. und gerade das Thema Security ist darüber sehr komfortabel abbildbar und nach außen verkaufbar. Was nicht heißt, dass ein Embedded-Betrieb nicht auch sicher abbildbar wäre. Aber hier fließt auch viel Emotionalität, Historie und Subjektivität mit ein. Vielleicht auch der Gedanke “Jetzt haben wir das jahrelang aufgezogen und jetzt wieder zurück zum Anfang?”… Für Security-Zuständige hat man durch das Hub-Deployment was gutes geschaffen. Deren Wort ist nicht zu vernachlässigen. Warum soll man das also wegnehmen? Das ist eine Sicht auf die Frage, wo vielleicht die oben genannten Punkte gar kein Gewicht haben. Ein Hoftor vor der Haustüre hält vielleicht den ein oder anderen Einbrecher mehr ab.
Was ist jetzt die Folge daraus? Man ändert nix und stellt ab 2027 schwergewichtige Gateway-Systeme hin mit Basis S/4HANA? Man führt die die Diskussion ganzheitlich? Es bleibt spannend aber das Thema “Hub vs. Embedded” ist sicher nicht auserzählt.
Der Vollständigkeit halber muss man sagen, dass dieser Beitrag viel auf subjektiven Meinungen und speziellen Gegebenheiten beruht. Je nach Systemarchitektur, Organisationsstruktur, Prozessmodell und Strategie können sich diese Fragen nicht stellen oder sich einfach andere Fragen stellen. Vielleicht bin ich ja auch der einzige der sich so über diese Frage und ihre Hintergründe Gedanken macht. 🙂
Du bist nicht der Einzige der sich darüber Gedanken macht. 😉
Selbst wenn man die Frage für sich schon mit Embedded beantwortet hat, weil man rechtzeitig gemerkt hatte dass die SAP Empfehlung sich um 180Grad gedreht hatte und man das gerade noch umsetzen konnte – selbst dann bleiben genug der Fragen/Klärungsbedarfe die du aufgeführt hast.
Und unterm Strich ist das eine Komplexitätsdimension und Variantenvielfalt für Lösungsansätze die sich nach meiner Ansicht gar nicht geben dürfte.
Weder kann man „dem Business“ erklären warum man da nicht „einfach macht“, noch ist es dem Ziel einer Standardisierung dienlich. Stattdessen entstehen Kundenindividuelle Lösungskonzepte die einer geforderten „Transformation“ im Wege stehen weil sie unnötig Kräfte binden.
Danke für deine Darstellung der Situation.
Christian
Danke Christian. 🙂
So sehe ich das auch.
Gerade der letzte Satz trifft den Nagel auf den Kopf.
Viele Grüße
Sascha