vorheriger Artikel
Einleitung
Viele Unternehmen entscheiden sich im Rahmen ihrer aktuellen Modernisierung- und Digitalisierungsinitiativen, ihr Data Warehouse (DWH) oder auch ihre Datenplattform in die Cloud zu heben. Dieser Beitrag diskutiert aus fachlicher/organisatorischer Sicht, welche Aspekte dafür besonders wichtig sind und welche Strategien dabei helfen, etwaige Risiken zu minimieren. Eine Migration sollte nicht als rein technische Übung verstanden werden. „Weiche“ Faktoren und Fachlichkeit haben einen deutlich höheren Einfluss.
Motivation
Die Motivation für eine Migration der analytischen Applikationen und dabei insbesondere des DWH in eine Cloud ist vielschichtig und man sollte alle Gründe gleichermaßen im Blick haben.
Beispiele für Migrationen:
Um die Komplexität zu reduzieren und einen hohen Automatisierungsgrad zu erreichen, ist es empfehlenswert, nicht zu viele parallele Stränge zu planen, sondern einzelne Komponenten oder auch Schichten ggf. in einem ersten Schritt nur via Lift & Shift „in die Cloud zu tragen“.
Bei Migrationen von Datenplattformen diskutiert man somit pro funktionalen Baustein verschiedene Migrationsstrategien:
Vorgehensmodell
Um ein strukturiertes Vorgehen, eine saubere Fortschrittskontrolle und vernünftige Risikominimierung zu gewährleisten, sollte die Migration in drei Phasen durchgeführt werden. Die wichtigste Phase ist hierbei die Bestandaufnahme, die einerseits die Komplexität, Kosten und den zeitlichen Ablauf ermitteln soll und andererseits auch über die konkrete Durchführung entscheidet. 
Eine Verschränkung von Migration und Modernisierung bietet sich immer an, wenn neue Daten-Use-Cases zügig umgesetzt werden müssen. Allerdings nur, wenn Änderungen, die im Rahmen der Modernisierung implementiert werden, nicht zu erheblichen manuellen Testaufwänden führen. Zudem führt manchmal zeitlicher Druck (Verlängerungen von Lizenzen etc.) dazu, dass Migration und Modernisierung zeitlich aufeinander folgend geplant werden müssen.
Business Case
Der Business-Wert einer Datenplattform wird sehr häufig nicht sauber diskutiert, weil das Datenteam und die zugehörige Infrastruktur als reine Cost-Center behandelt werden. Dies geht gut, solange das Volumen der analytischen Anforderungen die Umsetzungskapazitäten nicht übersteigt und die Infrastrukturkosten wegen steigendem Datenvolumen oder auch der Anzahl der bewirtschafteten Reports und Analysen überschaubar bleiben. Sehr häufig wird eine Migration aus Kostengründen erwogen, was nur bedingt zielführend ist, da die Entwicklungsaufwände die potenziellen Kostenersparnisse durch modernere Technologien und nutzungsbasierte Abrechnungsmodelle für Infrastruktur sehr häufig übersteigen.
Ein Business Case für eine Migration und Modernisierung besteht deshalb im Detail aus einer Vielzahl von Komponenten, die insgesamt die Frage beantworten muss, ob das Vorhaben a) mit einem Zeithorizont von 3 bis 5 Jahren kommerziell positiv ist oder b) eine reine Kostenoptimierung der bestehenden Lösung unter Beibehaltung der Technologien im ersten Schritt nicht zielführender wäre.
Der Business Case wird positiv, wenn der Wert der migrierten Lösung den Wert der alten Lösung übersteigt. Dies bedeutet teilweise, dass der Business Case bei einer reinen Kostenbetrachtung negativ sein kann. Für kleinere Plattformen übersteigen die Migrationskosten meist die potenziellen Kosteneinsparungen durch die Infrastruktur. In diesem Fall müssen neue Daten-Use-Cases hinsichtlich ihres Mehrwerts im Detail diskutiert und mittel- und langfristige strategische Aspekte berücksichtigt werden.
Bild einer High-Level-Architektur
Zu Beginn der Bewertung und in späteren Phasen ist ein logisches Architekturbild bei Diskussionen hilfreich. Insbesondere die Anforderungen an einzelne Bausteine, Schnittstellen oder auch Modernisierungen lassen sich anhand eines solchen Zielbilds diskutieren und helfen bei der Kommunikation mit der Gesamtorganisation.
Hierbei wird je einzelne Komponente die Migrationsstrategie festgelegt. Ein konkretes Kundenbeispiel (Migration nach AWS), um dies zu verdeutlichen:
Für die optimale Migrationsstrategie sollten immer Kosten, Mehrwert, Zeit und Risiko, wie viele Komponenten parallel migriert werden und was die Gesamtorganisation in einem bestimmten Zeitraum leisten kann, gegeneinander abgewogen werden.
High-Level-Projektplan
Neben Inventarisierung, architektonischen Entscheidungen und Kostenabschätzungen sollte nach der Bestandsaufnahme als wichtiger Punkt auch eine Roadmap entstehen, um die Planung der Migration und Modernisierung während und nach der eigentlichen Migration darzustellen:
Eine Migration benötigt in der Sache wenig Agilität. Trotzdem empfehlen wir die Durchführung mit einem agilen Ansatz, um frühzeitig ein Fortschritts-Monitoring zu haben und Zielkonflikte zwischen Tagesgeschäft und Migration zeitnah zu erkennen und beheben zu können.
Risiken und deren Mitigation
Risiken einer Migration müssen frühzeitig erkannt und angegangen werden:
Fazit
Eine Migration stellt sowohl eine technische als auch eine organisatorische Herausforderung dar. Sie erfordert eine umfassende Transformation, die nicht nur die IT-Infrastruktur betrifft, sondern auch die Arbeitsweise und Prozesse der gesamten Organisation. Mittelfristig sollte das Vorhaben auch zu einer Modernisierung und Umsetzung neuer Use Cases führen, denn nur so ergeben sich neben weichen Vorteilen auch klare monetäre Effekte.
Wenn Du über eine Migration nachdenkst, dann stehen wir sehr gern für eine Bestandsaufnahme zur Verfügung. Neben einem gemeinsamen Verständnis der Motivation sollten ein erster Business Case und die herstellerunabhängige Diskussion verschiedener Migrationsstrategien Ziel dieser Bestandsaufnahme sein. Neben Cloud Readiness Checks bieten wir beispielsweise auch einen Quick Check für die DWH-/Datenplattform-Migration an.
