Thought Leadership
„Cloudtechnologie als Enabler für ihre SAP-Strategie“ – das passt nicht? Dann vielleicht besser: „SAP im Kern und ergänzend dazu Cloudtechnologie“? Obwohl heute jeder über die Vorzüge von Cloud-Native-Technologie spricht, übernehmen Hostsysteme und ERP/SAP-Monolithen eine tragende Rolle in den meisten IT-Infrastrukturen deutscher Großunternehmen.
Und nein: In meiner Definition handelt es sich bei SAP S/4 HANA nicht um echte Cloud-Technologie. Auch wenn der Hersteller aus Walldorf oder andere SAP-Berater das gebetsmühlenartig wiederholen. Warum ich diese Meinung vertrete ist einfach: Haben sie schon einmal ein vollständiges HANA-Deployment in 20 Minuten auf einer beliebigen Infrastruktur gesehen? Kann ihr HANA horizontal skalieren, also einzelne Services nach Bedarf und temporär hoch oder wieder runterfahren? Oder eine vollautomatische Update Pipeline bzw. auch Rollbacks einzelner Softwaremodule ohne eine Minute Downtime? All das ist mit SAP oder auch einem Hostsystem, völlig unmöglich und wird es aufgrund der Technologie auch in Zukunft bleiben. Aber genau solche Aspekte sind die Vorzüge von echter Cloud-Native-Technologie. Nicht überall, wo ein Anbieter oder Dienstleister „Cloud“ draufschreibt ist auch „Cloud“ drin.
Bestehendes ERP-System
Was ist das Credo, wenn SAP nicht wirklich Cloud fähig ist? SAP einfach durch Cloud-Native-Technologie ersetzen? Wohl kaum. Es ist sicherlich in fast allen Fällen nicht trivial, ein bestehendes ERP-System vollständig durch eine andere Technologie und andere Konzepte abzulösen. Zu teuer, zu risikoreich, zu langwierig und dazu politisch in den meisten Fällen kaum vermittelbar. Zudem dürfte es nahezu unmöglich sein, eine IT-Organisation, die es seit Jahren gewohnt ist, zentral oder standardisiert zu denken und zu handeln, im Rahmen eines Riesenprojektes auf Kommando agil arbeiten zu lassen. Von daher ist es vielleicht sinnvoller, einen Micro-Service-Kosmos neben dem bewährten IT-Stack entstehen zu lassen und über klar definierte Schnittstellen von und zum SAP-System zu betreiben. Diese Koexistenz aus alter und neuer Welt ist auch deshalb sinnvoll, weil es nicht zielführend ist, über Jahre eingespielte technische Prozesse schlagartig auf eine agile Lösungsplattform zu portieren. Nicht alles, was ein klassischer SAP-Monolith bietet, ist schlecht – ganz im Gegenteil. Nur in den Bereichen, in denen die klassischen SAP-Systeme keine leistungsfähigen und bezahlbaren Antworten liefern, sollte zweimal hinterfragt werden, ob eine teure Überforderung von Lösungen wirklich sinnvoll ist.
Ein Beispiel für eine derartige Überforderung ist, nicht benötigte Daten (z. B. Alt- oder Archivdaten) in der HANA-Infrastruktur zu belassen. Denn was mit Oracle-Datenbanken schon teuer war, wird in der technischen HANA-Infrastruktur zum massiven Kostenblock. Von daher eignet sich eine Datenauslagerung, sehr gut als konkretes Anwendungsbeispiel, wie man die SAP-Welt mit Cloud-Technologie aufwerten kann.
Es gibt drei primäre Gründe, seine Daten aus einem SAP-System auszulagern:
1. Produktive Datenbanken entlasten (Kosten sparen)
2. Langzeitarchivierung zur Erfüllung rechtlicher Anforderungen (GoBD)
3. Nutzung von SAP-Daten durch Drittsysteme
Datenauslagerung
Egal welcher Grund in der individuellen Situation für eine Datenauslagerung spricht, eines ist klar: Sofern hier andere Systeme zur Datenhaltung zum Einsatz kommen, spricht nichts dagegen an dieser Stelle auf echte Cloud-Native-Technologie zu setzen. Es geht also um eine sinnvolle Co-Existenz der alten und neuen Welt. Dennoch ist es gar nicht so einfach in diesem Bereich gute Cloudtechnologie zu finden, die dem technischen Anspruch von Cloud-Native-Paradigmen genügen. Es reicht eben nicht vorhandene OnPremises-Software auf einem virtuellen Server in AWS zu installieren. Es reicht auch nicht, ein Docker Image auf einem virtuellen Server in AZURE zu installieren. All das wird zwar als „Cloud“ oder „Cloudlösung“ verkauft, ist aber nichts anderes, als alte Technologie in eine moderne Infrastruktur zu pressen ohne dabei die o. g. Mehrwerte, wie Autoscaling oder Rolling Updates, wirklich nutzen zu können. Nahezu alle Hersteller von Archivlösungen, die heute in diesem Bereich eine Rolle spielen, tun sich schwer damit, vollwertige und einfach deploybare Cloud Services anzubieten. Das liegt vor allem daran, dass der technologische Kern dieser Lösungen meist schon 15 bis 20 Jahre alt ist. Ein Beispiel dafür, dass die klassischen ECM-Hersteller sich bei der Bereitstellung von Container Deployments schwertun, liefern standardisierte Security Scans auf deren ausgelieferten Images. Nicht selten füllen die kritischen Findings dabei eine ganze DIN-A4-Seite. Cloudtechnologie sagen und Cloudtechnologie liefern, sind leider zwei unterschiedliche Dinge, die gerne von den Vertriebsmitarbeitern der Softwarehäuser verwechselt werden.
Weiterhin ist es für die ersten beiden o. g. Gründe einer SAP-Datenauslagerung noch nicht mal notwendig, ein ganzes ECM-System einzusetzen. Selbst Anforderungen der GoBD/DSGVO aber auch die einfache SAP-Datenarchivierung zur Systementlastung, können schlanker realisiert werden. Hier bieten Firmen wie KGS oder nextevolution schlankere Ansätze. Auch PBS findet man immer wieder in diesem Bereich, gleichwohl PBS als Schwerpunkt immer noch Teile seiner Software in SAP selbst integriert, was zum einen den Betrieb eines SAP selbst verkompliziert und zum anderen dadurch eine echte Cloud-Native-Lösung schon per Design ausschließt.
Schlanke Lösung
Entscheidet sich ein Unternehmen für so eine schlanke Lösung, sollte darauf geachtet werden, die Infrastruktur so zu designen, dass Cloudtechnologie ihre Wirkung auch voll entfalten kann. Wichtig ist dabei anzumerken, dass Lösungen nicht zwangsläufig in der Cloud eines Hyperscalers laufen müssen. Ganz im Gegenteil. Niemand zwingt ein Unternehmen in die SaaS-Falle von AWS, Microsoft oder Google zu laufen. Sofern ein SAP-System noch OnPremises oder bei SAP selbst in Walldorf gehostet wird, ist nicht davon auszugehen, dass man sich langfristig mit der Abhängigkeit zum Softwareservice eines Hyperscalers einen Gefallen tut. Insofern wäre das Idealbild einer Lösung, über ein containerisiertes Service Deployment zu verfügen, dass innerhalb von 20 Minuten in jeder IT-Infrastruktur lauffähig ist. Egal ob bei AWS oder im eigenen Rechenzentrum und egal ob man Open Shift oder Kubernetes zur Orchestrierung der Container nutzen will. Nur eine solche Lösung bietet einem Unternehmen die maximale Flexibilität und optimale Nutzung seiner individuellen Möglichkeiten. Und lassen sie sich nicht erzählen, dass man echte Container Services auch ohne Orchestrierungsschicht sinnvoll betreiben kann. Das würde nur jemand behaupten, der seine alte Software in einen Container gepresst hat, ohne bei der Entwicklung auch nur ansatzweise in einzelnen Services gedacht zu haben. Hauptsache man kann einen Haken bei „Container“ machen. Microservices sind aber nur dann sinnvoll, wenn man sie auch verteilen und skalieren kann und diese noch dazu sicher sind. Das hier bei der Entwicklung einiger Lösungen nicht wirklich bis zu Ende gedacht wurde, zeigen schon einfache Security Scans. In der heutigen Zeit sollte es eigentlich selbstverständlich sein, einem Hacker nicht alles auf dem Silbertablett zu servieren. Die reale Welt zeichnet an der Stelle leider häufig ein erschreckend anderes Bild.
Lösungsanbieter überschaubar
Legt man diese Maßstäbe an eine sinnvolle Lösung an, wird die Zahl der potentiellen Lösungsanbieter sehr überschaubar. Über ein vollständiges Service Deployment zur SAP-Archivierung, das dazu noch ein aktuelles Container-Security-Audit mit guten Werten überlebt, kann derzeit nur nextevolution aus Hamburg liefern. Und das gilt auch bei einer weltweiten Betrachtung von Lösungen. KGS folgt mit etwas Abstand, denn hier tut man sich schwer damit, schlanke Services in einer beliebigen Containerumgebung bereit zu stellen. Auch wenn das Angebot auf dem IT-Markt recht dünn ist, bleibt erfreulicherweise anzumerken, dass die deutschen Hersteller hier deutlich die Nase vor der ausländischen Konkurrenz haben.
