Unternehmen wechseln in die Cloud, weil sie den Ruf hat, hochverfügbar und ausfallsicher zu sein. Trotzdem empfiehlt es sich, bereits am Anfang ein mögliches Ende zu planen. [...]
So geschehen: Die IT-Strategen der Bank verkünden laut „Cloud first!“. Das lassen sich die Fachabteilungen nicht lange sagen und entwickeln, was das Zeug hält. Binnen zwölf Monaten und unter hohem Personal- und Budgeteinsatz wird eine Cloud-gestützte Kommunikationslösung gebaut, die zahlreiche Bankprozesse unterstützen soll. Kurz vor dem Go-live fragt der Outsourcing-Beauftragte der Bank den Product Owner und sein Team nach dem Exit-Konzept – und blickt in fragende Gesichter. Wofür soll das gut sein? Der Cloud-Service-Provider, einer der großen drei amerikanischen Anbieter, werde ja schon nicht pleitegehen. Und wenn eines der Rechenzentren ausfiele, schwenke man eben einfach auf eines der anderen, die der Provider anbiete – diese Hochverfügbarkeit sei ja gerade der Grund, weshalb man eine Cloud-Lösung gewählt habe.
Das vorläufige Ende dieser mit Konjunktiven gespickten Geschichte: Der Outsourcing-Beauftragte bestand auf das regulatorisch zwingend notwendige Exit-Konzept, die anschließenden Diskussionen führten dazu, dass das Projekt erst einmal zurückgestellt, neu überdacht und schließlich völlig neu aufgesetzt wurde. Leider ist das kein Einzelfall, wie der Blick auch in andere Banken und Versicherungen zeigt. Häufig wollen die IT- und Fachabteilungen die vielfältigen Möglichkeiten, die moderne Cloud-Anwendungen und Use-Cases bieten, so schnell wie möglich nutzen und dem Kunden präsentieren.
Die technischen Schwierigkeiten und Bedenken werden kurzerhand aus dem Weg geräumt, die Begeisterung lässt den Code rasch wachsen – und Gedanken an Datenschutz und Regulatorik werden ganz weit nach hinten gestellt. Ein fataler Fehler. Denn gerade Banken und Versicherungen müssen sehr genau hinschauen, welche Schritte in die Cloud erlaubt sind und welche nicht. Und auch, wie man eigentlich aus der Cloud wieder herauskommt, wenn es denn nötig werden sollte. Denn das ist eine Frage, die gar nicht so einfach zu beantworten ist.
Cloud-„Notausgang“ ist Pflicht
Die Anforderung, ein Exit-Konzept vorlegen zu können, war im oben geschilderten Fall der Stolperstein. Schauen wir auf die Regulatorik der Banken, so sind diese nach den Outsourcing-Regelungen aus AT 9 der MaRisk dazu verpflichtet, bei wesentlichen Auslagerungen zum einen Vorkehrungen für den Fall einer beabsichtigten oder erwarteten Beendigung zu treffen. Zum anderen sind für den Fall unbeabsichtigter und unerwarteter Beendigungen „etwaige Handlungsoptionen auf ihre Durchführbarkeit zu prüfen“. Der erste Teil der Anforderungen ist noch relativ einfach zu erfüllen, indem Kündigungsmöglichkeiten mit entsprechenden Fristen und – quasi als Exit-Unterstützung – Verlängerungsoptionen z.B. um ein Jahr mit dem Cloud-Service-Provider vereinbart werden.
Das, was sonstigen Anwendern von den Hyperscalern versagt wird, hat in deren Standardverträge für Banken und Versicherungen mittlerweile Einzug gehalten. Die beabsichtigte oder erwartete Beendigung ist also nicht das Problem. Der zweite Teil hinsichtlich unbeabsichtigter oder unerwarteter Beendigung ist hingegen schon schwieriger zu bewerkstelligen. Schon die Definition möglicher Exit-Szenarien ist nicht einfach. Will man sich wirklich vorstellen, dass Amazon, Google oder Microsoft in die Insolvenz geraten? Oder einfach von heute auf morgen ihr Geschäft einstellen?
Auch in sonstigen Beendigungsüberlegungen gerne verwendete Katastrophenfälle wie ein Bombenanschlag oder ein Flugzeugabsturz, bei dem ein Rechenzentrum völlig zerstört wird, hat bei den amerikanischen Hyperscalern wenig Durchschlagskraft: „Wenn das eine RZ wegfällt, schalten wir eben auf ein anderes um – Problem gelöst“, so antwortete achselzuckend ein Cloud–Security-Officer eines Cloud-Anbieters auf entsprechende Nachfragen der Aufsicht.
Ein Cloud-Ausstieg kann viele Gründe haben
Es gibt jedoch auch Exit-Szenarien, die ganz andere Schwierigkeiten in sich bergen: Angenommen, der Datenschützer steht vor der Tür und untersagt, beispielsweise mit Verweis auf das Schrems-II-Urteil des Europäischen Gerichtshofs, den Datenaustausch mit amerikanischen Unternehmen. Oder ein Handelskrieg zwischen den USA und Europa bricht aus und hat zur Folge, dass amerikanischen Unternehmen Geschäfte mit deutschen Firmen untersagt werden. Angesichts der immer noch weithin ungeklärten Lage nach dem Wegfall des Privacy Shields und angesichts von Handelsembargos gegen einen deutschen Reeder, der bei Nordstream II unterstützt, sind das durchaus realistische Szenarien.
Doch wie könnte eine Vertragsbeendigung in diesen beiden Fällen aussehen? Ein Umschwenken beispielsweise von der Google Cloud Platform auf Microsoft Azure wäre zwar theoretisch und technisch – mit viel Aufwand – machbar. Aber sowohl Google als auch Microsoft, oder ihr in der Finanzwelt noch immer nicht wirklich angekommener Konkurrent Amazon, kämen aufgrund ihrer US-amerikanischen Herkunft als Alternative gar nicht in Frage. Alibaba dürfte aus demselben Grund ausfallen, so dass nur noch europäische Cloud-Angebote zur Auswahl stünden – oder eben eine Rückkehr in die eigene Private Cloud.
Diese Möglichkeiten stellen jedoch keine echte Alternative dar, die sich auch nur im Entferntesten rechnen oder gar durchführen ließen. Und so bleibt es den Unternehmen nur noch, sich auf andere Art und Weise die Beendigung ihrer Auslagerungen und damit ihr Exit-Konzept zurechtzurücken. Und der Ansatzpunkt ist hier bei den Exit-Szenarien selbst zu suchen. Denn so, wie man mit Fug und Recht eine mögliche Insolvenz der großen drei wegdiskutieren kann, so kann man es mit ein wenig Phantasie auch hinsichtlich der anderen Beendigungsmöglichkeiten.
So könnte man zum Ergebnis kommen, dass mangels eines Exit-Szenarios ein Ausstieg überhaupt nicht stattfinden wird. Oder man geht von der Annahme aus, dass zumindest eine vom jeweiligen Use Case und der Menge der zu migrierenden Daten abhängige, jedoch ausreichend große Zeitspanne zur Verfügung steht, die eine Rückführung der ausgelagerten Use Cases in geordneter Art und Weise möglich macht.
So planen Sie eine Cloud-Exit-Strategie
Dies prozessual und mit entsprechend kreativen Exit-Konzepten und -Strategien zu unterfüttern sowie auch eine regelmäßige Überprüfung der Durchführbarkeit sicherzustellen, ist Aufgabe der Outsourcing-Abteilungen:
- festzulegen sind dabei die einzelnen, möglichst genau definierten Schritte, die bei einer Migration vorgenommen werden müssen;
- auch der zeitliche, personelle und finanzielle Aufwand für eine derartige Migration sind zu schätzen;
- mögliche Tools oder Dienstleister, die bei einem Exit unterstützen können und deren Verfügbarkeit ebenfalls (zumindest theoretisch) sichergestellt sein muss, helfen dabei, Handlungsoptionen für die Fälle einer unbeabsichtigten oder unerwarteten Beendigung einer Auslagerung genauer zu fassen.
Und so kann zum Beispiel die Klassifizierung gleichgelagerter Use Cases und die Erstellung von für die entsprechenden Klassen standardisierten Exit-Konzepten dabei helfen, wenn in einem Factory-Ansatz zahlreiche Use Cases in die Cloud verlagert werden sollen. Oder es finden sich im Unternehmen Abteilungen, die für die durch die Cloud-Service-Provider angebotenen Services eigene Exit-Konzepte vordenken, die dann von anderen Abteilungen im Unternehmen ohne großen Aufwand übernommen werden können. Sind es nur eine Handvoll Cloud-Anwendungen, könnten auch eigene, ohnehin bereits vorgehaltene Ressourcen in Frage kommen. Die Ansätze im Markt sind hier noch uneinheitlich, und bislang hat sich auch die Aufsicht zu den Ansätzen noch nicht geäußert. Es bleibt also weiterhin spannend.
*Branimir Brodnik schreibt als Experte zu Sourcing-Themen in der IT in Zeiten von Cloud und Digitalisierung. Er ist Gründer und geschäftsführender Gesellschafter der microfin Unternehmensberatung GmbH und weist eine über 20-jährige Berufserfahrung in den Bereichen Financial Services und Consulting auf.
Be the first to comment