Second Source

Lange habe ich mich gegen intensiven Zentralismus gewehrt. Mein Sinn war immer für Freiheit, Eigenständigkeit und Eigenverantwortung. Leider widersprechen ökonomische Vorteile allzu oft einer verteilten Organisation.

Ein lächerlich kleines Beispiel, aber bezeichnend für unsere Situation: In der Kantine traf ich einen ehemaligen Tennispartner, der jetzt bei uns im zentralen IT-Einkauf arbeitet. Er erzählte mir von Laufwerksrahmen für unsere IBM- und Fujitsu-Server.

Der Rahmen nimmt 2.5-Zoll-SAS/SATA-Laufwerke auf und besteht aus ein wenig Metall, viel Plastik und einem Verriegelungsmechanismus.

Bei unserem gelisteten deutschen Distributor kostet ein Stück deutlich über 100 Euro. Ein Lieferant aus San Francisco bietet genau das gleiche Teil für nicht ganz 20 Dollar an.

Gefunden hat diese Quelle ein Lehrling im Einkauf über Amazon.

Das sind nette Anekdoten, aber es hat einen Nachdenkprozess bei mir ausgelöst: Wir haben eine redundante IT-Infrastruktur mit mehreren Strom-, Server-, Storage- und Diesellieferanten; Letzter für die Notstromaggregate.

Die Liste unserer Zweit- und Drittlieferanten würde ganz leicht ein ganzes E-3 Magazin füllen.

Ausfallsicherheit und Katastrophenpläne sind in unserer globalen IT-Architektur eine Selbstverständlichkeit. Und naturgemäß ist es kein Thema, das die IT allein betrifft.

Werkschutz, Security, Plant-Manager und viele andere sind hier in Disaster-Recovery-Teams zusammengefasst. Keinen Plan gibt es für den Ausfall einer singulären Cloud-Plattform wie SuccessFactors, Ariba, Concur, HEC oder HCP!

Die Sachlage ist komplexer, als es auf den ersten Blick erscheinen mag: Man kann eine redundante RZ-Architektur weltweit betreiben, die sogar in „Echtzeit“ reagiert. Wenn aber in der Software ein Bug ist, der den Algorithmus zum Deadlock führt, dann hilft auch keine ausfallsichere Hardware mehr.

Naturgemäß gibt es auch dafür Lösungen, die aber im normalen kommerziellen Umfeld nicht organisierbar und finanzierbar sind: Eine Aufgabe lässt man von zwei unabhängigen Programmierteams ausarbeiten.

Die Wahrscheinlichkeit, dass beide Teams exakt denselben Algorithmus entwickeln und darin exakt die gleichen Fehler machen, ist sehr gering. Aber auch dieser doppelte Aufwand löst noch nicht alle Probleme.

Im Fall des Kollabierens eines Algorithmus arbeitet der andere hoffentlich weiter – und man ist hinreichend geschützt. Was aber, wenn beide Programme zwar nicht abstürzen, aber unterschiedliche Ergebnisse liefern? Dann bräuchte man ein drittes Programm, um annähernd festzustellen, wie das richtige Endresultat lauten könnte.

Leider kann ich hier keine Lösung für die SAP-Community präsentieren und lediglich einige Gedanken unserer internen Diskussionen wiedergeben: Angesichts der aktuellen technischen Entwicklung und Machbarkeit erscheint die vollständige Abhängigkeit eines Bestandskunden durch Software-as-a-Service, wie es HEC, HCP und viele SAP-Tochterunternehmen darstellen, nicht vertretbar. Eine IoT-Anwendung mit HCP erscheint machbar.

Was passiert aber im K-Fall? Wo sind die Backups der Daten? Nach einem Download: Kann man die Daten weiterverarbeiten? In welchem Format liegen diese dann vor? Welche Software steht lokal und on-premise bereit, um die Daten lesen zu können?

Naturgemäß gibt es gute Gründe für Cloud-Lösungen wie Business ByDesign und HEC oder S/4 in der Cloud. Wer keine IT-Infrastruktur, wenig Ressourcen und sofort eine Lösung braucht, ist wahrscheinlich mit diesen Instant-Lösungen gut beraten: Cloud Computing hat auch eine Lebensberechtigung!

Wer aber seit 30 Jahren treuer SAP-Bestandskunde ist, viel Wissen und Erfahrung angesammelt hat und auch die notwendige ERP-Architektur sein Eigen nennen kann, wird um SaaS-Modelle einen großen Bogen machen. Hybrid-Clouds und Hyper-convergedInfrastructure ja, aber Cloud Computing mit SuccessFactors, Hybris, Concur etc. wahrscheinlich nicht.

Meine langjährige Berufserfahrung zeigt mir, dass viele Probleme sich aus einem anderen Blickwinkel lösen lassen. Wir werden uns Zeit nehmen und das Second-Source-Problem für Software überdenken. Aber ebenso sollte sich auch unsere SAP etwas mehr Zeit geben oder gönnen.

Noch immer gibt es Schauergeschichten über Hana und In-memory-Computing-Anomalien. Den Informatiker wundert es nicht, weil gute Software einen Reifungsprozess durchläuft.

Bis heute gehört es zu den größten Rätseln der SAP-Community, warum man Hana mit der Brechstange in den Markt drücken will. Die Deadline von 2025 auf 2030 zu schieben und S/4 Finance und Logistics die notwendigen Reviews zuzugestehen ist kein Zeichen von Schwäche, sondern von Souveränität und Weitsicht.

Während ich diese Zeilen schreibe, bringen die TV-Nachrichten die Meldung, dass auch VW keine Second Source für ausgewählte Golf-Teile besitzt.

Einen Autohersteller ohne Zweitlieferanten konnte ich mir bis jetzt noch nicht vorstellen – offensichtlich gibt es das. SAP musste es bereits leidvoll erfahren, dass es für SuccessFactors keine Second Source gibt.