Unternehmen, die sich besonders euphorisch dem Transfer ihrer Workloads in die Multi-Cloud verschreiben, sind nicht unbedingt die erfolgreichsten. Denn sie wollen in der Regel zu viel in zu kurzer Zeit. Technisch mögen ihre Ziele noch umsetzbar sein. Doch unterschätzen sie die organisatorischen und fachlichen Grenzen, die ihnen die eigene IT sowie die Fachabteilungen setzen. Skalieren und migrieren lässt sich fast alles. Aber: Wie viel(e) Cloud(s) kann ein Unternehmen überhaupt stemmen, ohne den Überblick in Sachen Kosten, Infrastruktur und Sicherheit zu verlieren? Steht das Management voll hinter den definierten Zielen und ist es bereit, im Fall der Fälle dafür auch einzustehen?
Foto: Maximumm - shutterstock.com
Auf in die Cloud – aber wie?
Ein Beispiel ist das Aufgeben der eigenen Rechenzentren. Das Abschalten stellt technisch gesehen keine Herausforderung mehr dar. Allerdings verhindert die Angst davor, seine Daten nicht mehr inhouse zu speichern und das Verteidigen der althergebrachten Unternehmenskultur nicht selten diesen notwendigen Schritt. Notwendig deshalb, weil der Schritt in die Multi-Cloud sonst die erwünschten Kosteinsparungen nicht mit sich bringt, sondern sogar zu Mehrkosten führt.
Nicht nur das Management muss sich zu einer Multi-Cloud bekennen – auch die Verantwortlichen müssen von Anfang an deutlich kommunizieren, wohin die Reise geht. Dies beugt dem berühmten „Flurfunk“ vor. Die so übermittelten strategischen Ziele der Cloud-Migration sind in der Regel das Ergebnis von sogenannten „Cloud Readiness Assessments“. Sie analysieren, wie viel Cloud ein Unternehmen wirklich „ertragen“ kann: Ist zum Beispiel die technische Infrastruktur der Standorte für bestimmte Cloud-Technologien überhaupt gewappnet? Wenn der Internet-Traffic die Netzwerke eines 1.000-Mitarbeiter-Unternehmens bereits voll auslastet, reicht die Anbindung für die meisten Cloud-Vorhaben zumeist nicht aus – zumal, wenn plötzlich alle 1.000 Mitarbeiter Cloud-Anwendungen beziehen. Schon der Ausbau einer solchen Internetanbindung lässt so manche Mehrwert-Rechnung eines Cloud-Szenarios zur Makulatur werden.
Ebenfalls auf den Prüfstand müssen sämtliche Anwendungen: Sind sie in der Cloud abbildbar? Werden sie überhaupt noch nennenswert genutzt oder fallen sie unter die Rubrik „Phantomsoftware“? Bei welchen Anwendungen muss deren Architektur geändert werden, damit sie ihren Weg in die Cloud finden können?
Nicht zuletzt wollen viele Mitarbeiter den Weg in die Multi-Cloud nicht mitgehen – vorrangig Mitarbeiter aus der IT, die nun vor völlig anderen Aufgaben stehen, da ihre bisherigen Tätigkeiten wegfallen. Neben einer klaren und entschiedenen Kommunikation hat sich in vielen Fällen ein schrittweises Vorgehen bewährt, bei dem die Unternehmens-IT zunächst ihre lokale Architektur mit Blick auf die Cloud umbaut – etwa durch die Einführung einer Private Cloud im eigenen Rechenzentrum. In sie können die Workloads nach und nach einfließen, die Mitarbeiter werden sukzessive an die neue Technologie herangeführt, spielen Anwendungsszenarien durch und lernen so den Mehrwert der neuen Lösung kennen und schätzen.
Was während der Cloudifizierung zu tun ist
Geht es vor dem Schritt in die Multi-Cloud vor allem darum, nicht den zweiten Schritt vor dem ersten zu tun und erst einmal zu klären, was die geplante Cloudifizierung konkret umfassen soll, ist während der eigentlichen Umsetzung Stringenz und Konsequenz angesagt. Denn nichts ist in Cloud-Projekten schlimmer, sprich teurer, als einmal getroffene Entscheidungen immer wieder zu ändern. Wer Rechenkapazitäten und Anwendungen nicht wie vereinbart außer Betrieb setzt, schafft automatisch Zwei- bis Dreifach-Architekturen, welche die gesamte IT ausbremsen können. Sogenannte „Phantomapplikationen“ entstehen, die faktisch niemand mehr nutzt oder deren Prozesse nicht mehr existieren.
In diesen Situationen ist konsequentes Ab- und Ausschalten gefragt. Eine klare Segmentierung der Infrastruktur hilft bei der Einsortierung der jeweiligen Workloads und Anwendungen. So kann ein Unternehmen beispielsweise drei „Töpfe“ bilden: eine SAP-Cloud und eine Microsoft-Cloud, sowie eine „Krypta“, in der abzuschaltende Systeme abgelegt und sprichwörtlich mit einem Grabstein versehen werden. Diese Aufteilung verhindert ausufernde Diskussionen, die dazu führen, dass bestimmte Systeme einfach weiterlaufen. Und dass dadurch das Ziel der „Zero IT“ immer weiter in die Ferne rückt.
Die Fachabteilungen spielen in solchen Diskussionen die Schlüsselrolle, denn nur sie können den Mehrwert von Anwendungen beurteilen und nicht externe Berater oder die Kollegen der IT. Entsprechend muss das Management dafür sorgen, dass die Fachexperten während der gesamten Cloud-Migration mit an Bord sind – und das nicht nur zu zehn Prozent, sondern gleichberechtigt mit der IT. Hinzu kommt die Einbindung externer Cloud-Experten, die nicht so emotional mit dem Thema umgehen wie die Internen und die nach dem Vier-Augen-Prinzip eine unabhängige Sicht einbringen. Dies macht die Transformationsprozesse erfahrungsgemäß nicht nur schneller, sondern erhöht auch deren Qualität.
Cloud-Migration - der Tag danach
Ist ein Unternehmen dann in der Multi-Cloud angekommen und sind die Altsysteme abgeschaltet, steht ein erneuter Perspektivwechsel an. Denn „am Tag danach“ gilt es, die unterschiedlichen Cloud-Lösungen auch optimal zu nutzen. In der herkömmlichen IT gingen implementierte Systeme in eine sogenannte „Frozen Zone“ über, in der sie weitgehend unangetastet blieben, solange sie reibungslos liefen. Um die Prozesse in der Cloud muss sich ein Unternehmen nach der Implementierung hingegen fortlaufend kümmern – wenn auch unter anderen Gesichtspunkten. Es geht nicht mehr um die Wartung und Pflege von Anwendungen und Systemen, sondern um andere Fragen: Wie lässt sich eine Anwendung noch mehr auf die Anforderungen der Fachabteilung zuschneiden? Welche potenziellen Mehrwerte der gebuchten Dienste sind noch ungenutzt? Wie handhabe ich das Update-Management? Welche Cloud-Workloads lassen sich wieder außer Betrieb nehmen? Überlasse ich dieses Management dem Provider? Oder setze ich besser auf Cloud-Experten, die sich je nach Bedarf buchen lassen? Als Vorgehensweise ist dabei ein agiles Vorgehen wie DevOps unersetzlich, ohne dass sich eine Multi-Cloud kaum sinnvoll nutzen lässt.
Cloud-Berater im Betrieb einer Multi-Cloud-Umgebung sollten entweder aus dem eigenen Unternehmen kommen oder Externe sein – nie jedoch vom Provider selbst gestellt werden. Sonst ist die Gefahr zu groß, Services zu buchen, die im Cloud-Zeitalter hinfällig werden. Zwei Beispiele: Niemand muss für Exchange Online noch Wartung zukaufen. Auch beim Einsatz von Microsoft Office 365 ist keine Support-Hotline mehr erforderlich.
Cloud muss weniger betrieben als beraten werden. Dementsprechend braucht es statt Server-Managern nun Service-Manager, die an der Schnittstelle zwischen Fachabteilung und Cloud-Anbieter fungieren. Sie unterstützen etwa, wenn ein Cloud-Workload über Wochen und Monate weitgehend ungenutzt läuft und unterbreiten kostengünstigere Alternativen. Auf diese Weise halten sie einen kontinuierlichen Verbesserungsprozess in Gang, der keine „Frozen Zones“ für Anwendungen mehr kennt.