Sie stehen online kostenlos zum "Do it yourself" zur Verfügung, aber auch als bezahlte Beratungsleistung: Die Rede ist von Cloud Readiness Assessments. So reicht das Spektrum der heute gängigen Assessments von proprietären Ansätzen bis zur Nutzung anerkannter Reifemodelle wie zum Beispiel von der ODCA (Open Data Center Alliance), die als Grundlage zur Bewertung einer vollumfänglichen IT-Organisation dienen. Unternehmen bekommen dort einen Satz von Fragen, welche die technische, organisatorische und prozessuale Ebene abdecken. Vielen Cloud-Anbietern dienen sie vor allem dazu, ihre eigenen Leistungen zu verkaufen.
Die Aussagen am Ende solcher Cloud Readiness Assessments identifizieren die Reife einer Organisation und die technischen Rahmenbedingungen für den Einsatz von Cloud Computing. Einige wenige wagen sogar einen pauschalisierten Blick auf die Cloud-Reife der Applikationen. Aus der Reife werden dann mal mehr mal weniger fundiert Schlüsse auf die Handlungsbereiche gezogen und in der Regel versucht der Anbieter dann "seine" Cloud zu verkaufen. Grundsätzlich ist diese Vorgehensweise solide und ein möglicher Startpunkt auf dem Weg in die Cloud.
3 Problemfelder bisheriger Assessments
Wenn ein Unternehmen jedoch den Weg in die Cloud nicht nur beginnen, sondern dann auch konsequent weitergehen will, wird es drei Dinge sehr schnell feststellen:
Auch die Applikationen spielen eine zentrale Rolle auf dem Weg in die Cloud.
Das Management der neuen Modelle, etwa "Multi Provider" oder "Zero Baseline", erfordert grundlegend neue Kooperationsformen und damit Veränderungen weit über die IT hinaus, zum Beispiel im Einkauf.
Die bestehende Management-Landschaft kann die Steuerung von Cloud-Dienstleistern sowohl prozessual als auch toolseitig nicht abbilden.
Diese entscheidenden Herausforderungen lassen sich durch die heutigen Cloud Readiness Assessments nicht abbilden, denn sie gehen über deren simple Frage-Antwort-Logik hinaus. Zusätzliche Dimensionen sind notwendig. Die in der Folge aufgeführten Fragenkataloge hat maßgeblich Matthias Popiolek, Principal Consultant bei der ISG Information Services Group, entwickelt.
Genauer Blick auf Applikationen nötig
Die Bewertung von Applikationen kann in Assessments nur oberflächlich erfolgen. Meistens erlauben diese lediglich eine grobe Aussage über die Nutzung von IaaS (Infrastructure as a Service).
Wer bei Cloud auch über Einkauf von virtuellen Maschinen hinaus denkt, muss hingegen tiefer in die Applikationswelt eindringen und sich zusätzliche Fragen stellen:
Wie sieht das Verhältnis von Kaufsoftware und Eigenentwicklungen aus?
Wird die Kaufsoftware als Standard oder in einer individuell angepassten Version genutzt?
Ist bei der Kaufsoftware ein Umstieg auf SaaS (Software as a Service) geplant?
Wie erfolgt aktuell der Datenfluss zwischen den Applikationen? Automatisiert, vor Ort, nach Abteilungen und Applikationen getrennt oder zentral?
Ist bereits ein ESB (Enterprise Service Bus) implementiert oder kommen verschiedene ETL-(Extract-Transform-Load-)Tools zum Einsatz?
Existiert ein Standardsatz mit Regeln für Eigenentwicklungen? Berücksichtigt dieser bereits die Anforderungen an die Applikations-Bereitstellung für die Cloud?
Wie weit werden diese Standards auch wirklich eingehalten?
Wie groß ist die kulturelle und organisatorische Herausforderung beim Cloud-Umstieg einzuschätzen? Sind die Applikationsverantwortlichen "Cloud-affin"?
Welche Auswirkungen der Cloud-Charakteristika sind auf die Abteilungen außerhalb der IT zu erwarten?
Kann die Transformation in die Cloud mit dem Release-Zyklus der Eigenentwicklungen verzahnt werden?
Neue Modelle, neue Prozesse, neue Regeln
Selbst wenn Unternehmen bereits über Erfahrungen mit Outsourcing verfügen, müssen sie im Zuge der "Cloudifizierung" signifikante Veränderungen vornehmen. So wird die Cloud oft als Hebel für mehr Standardisierung genutzt. Dies hat nicht nur bei den Applikationen vielfältige Auswirkungen. Ein Beispiel sind die Einkaufsprozesse. Sie werden wesentlich schlanker, und auch die Vertragsstrukturen verändern sich.
So wird beim Übergang in die Cloud kaum ein Anbieter Interesse daran haben, Assets und Personal zu übernehmen. Solche Provider gibt es zwar noch, doch sind diese in der Regel einfach nur verzweifelt am Abschluss eines Deals interessiert oder noch nicht für die aktuellen Liefermodelle aufgestellt. In beiden Fällen handelt es sich in keinem Fall um geeignete Kandidaten.
Standardleistungen der Cloud-Provider kaum voneinander unterscheiden
Ebenfalls neu ist die Situation, dass sich die Standardleistungen der Cloud-Provider kaum voneinander unterscheiden und Kunden auf die jeweiligen Service-Kataloge eines Anbieters festgelegt werden. Verbunden hiermit sind dann sogenannte "Zero Baseline Agreements", also Verträge ohne garantiertes Volumen.
Dies erfordert neue Prozesse und Rollen über die bekannten Rollenmodelle wie zum Beispiel ITIL V3 hinaus. So müssen Unternehmen statt "Single vendor"- oder "Dual vendor"-Modellen mehrere Cloud-Anbieter nebeneinanderstellen. Sie müssen Leistungen unterschiedlicher Cloud-Anbieter zu neuen Leistungen kombinieren und diese gegenüber den internen und externen Kunden verantworten. Diese neue Komplexität will gesteuert werden, wozu klassische Sourcing-Modelle lediglich Anhaltspunkte liefern.
Über diese klassischen Modelle hinaus gilt es vor allem zu klären:
Ist der Einkauf mit im Boot, wenn beim Bezug von Standard-Services die darunterliegenden Schichten nicht im Detail beschrieben sind?
Geht der Einkauf den Weg von "Zero Baseline"-Verträgen mit? Kann er mit der dadurch veränderten Dynamik bei der Preisverhandlung umgehen?
Wie ist das Unternehmen aufgestellt, um externe und interne Kunden aktiv bei der Nutzung und Auswahl der neuen Plattformen und Services zu beraten?
Wie verändert sich die Rolle der Enterprise- und Solution-Architektur? Nehmen diese Bereiche heute eine operative Verantwortung wahr?
Sind die Eskalationsprozesse auf ein von verschiedenen Providern zusammengestelltes Lösungsmodell ausgerichtet?
Inwieweit sind bereits "Ende zu Ende"-Betrachtungen etabliert, zum Beispiel beim Monitoring von Prozessen?
Cloud Management Layer
Das Thema des Cloud Managements adressieren die meisten Readiness Assessments nur rudimentär. Denn die Mehrzahl der Assessments ist in einer Zeit entstanden, in der zumeist nur ein Cloud-Service zum Einsatz kam und daher Cloud-Brokerage und -Orchestrierung mehrerer Provider noch kein Thema waren. Letztlich müssen Unternehmen drei wesentliche Phasen im Griff haben:
Erstens Anbietervergleich und -auswahl
Zweitens Beschaffung
Drittens die nachgelagerten "Day 2 Operations".
Nimmt man nun noch die Außerbetriebnahme hinzu, hat man es mit einem kompletten Lebenszyklus zu tun.
Die wenigsten der heute für das Lifecycle Management eingesetzten Toolsets erlauben jedoch die Erweiterung in Richtung Multi-Cloud-Szenario. Doch ist die Beherrschung des Cloud Management Layers ein zentraler Faktor für den Geschäftserfolg.
Auf was kommt es dabei an? Auch hierbei hilft eine Fragenauswahl, die gängige Assessments nicht bieten:
Lassen sich die bestehenden Werkzeuge so erweitern, dass Cloud-Lösungen mitgesteuert werden können?
Soll das zukünftige Cloud Management Layer (CML) selbst verantwortet oder als Service bezogen werden?
Wie lassen sich CML-Service und Cloud-Services auf unterschiedliche Anbieter übertragen, um Interessenkonflikte zu vermeiden?
Welche Tools gibt es für die einzelnen Aufgaben Anbieterauswahl, Beschaffung und "Day 2 Operations"?
Welche Management-Systeme (etwa Self Service-Portale) sollen weiter genutzt werden und müssen mit dem CML interagieren?
Wer wird den CML wie nutzen? Wie ist er in das Identity Management integriert?
Welche Rollen gilt es innerhalb des CML (neu) zu definieren?
Cloud- und Lifecycle-Management digitalisieren
Der wichtigste Schritt, der Unternehmen bevorsteht, ist sicherlich jener in eine Multi-Cloud- und Multi-Vendor-Umgebung. Dies ist die logische Folge von Digitalisierung und "Cloudifizierung". Entsprechend digitalisiert muss auch das Cloud- und Lifecycle-Management der Unternehmen werden. Komplexes standardisieren und automatisieren - dieses Motto betrifft nun nicht mehr nur Infrastrukturen und Systeme.