Gründe für die Software-Migration
„Günther geht nächstes Jahr in Rente und er ist der Einzige, der sich mit der AS400 auskennt. Was machen wir jetzt?"
„Hier ist ein Brief von der XYZ AG: Sie haben tatsächlich den Support für ihr Framework eingestellt. Ab jetzt gibt es keine Security-Updates und keine Bugfixes mehr!"
„Seit zwei Wochen sind die neuen Gesetze bezüglich der Verwaltung von personenbezogenen Daten relevant. Mit unserer Software können wir die aber nicht abbilden."
Die Gründe, warum die Migration einer Software notwendig wird, sind so vielfältig wie die Software-Systeme selbst. Jeder Software-Entwickler weiß, dass Software auch gewartet werden muss, in der Praxis ist das aber nicht immer leicht zu realisieren.
Begründung für Software-Migration oft schwierig
Wenn man aber ein System hat, das vor vielen Jahren auf Basis des damals aktuellen Software-Stacks entwickelt wurde und seither gute Dienste leistet, ist der Antrieb, die Technologie zu aktualisieren häufig nicht so hoch. Das ist auch nicht weiter verwunderlich. Wie soll man den Anwendern oder noch wichtiger, dem Management verkaufen, dass eine Migration notwendig ist, die zwar viel Geld kostet, bei der nach außen hin aber nachher alles genauso aussieht wie vorher? Also werden Migrationen immer wieder verschoben.
Migration wird unumgänglich
Irgendwann kommt der Zeitpunkt, an dem es nicht mehr weiter geht. Die Technologie, auf der die Software basiert, erreicht zum Beispiel das Lebensende. Mit dem Ende des Supports gibt es auch keine Sicherheitsupdates mehr. Ein anderer Grund kann sein, dass wichtige Wissensträger das Unternehmen verlassen (und sei es in den wohlverdienten Ruhestand).
Manche Systeme haben einen Zustand erreicht, in dem das Entwickeln von neuen Features langwierig und zäh ist. Baut man an einer Stelle etwas an, geht eine andere kaputt, obwohl diese unabhängig zu sein scheint. Eine Modernisierung der Software ist nun notwendig, um zukünftige Features in einer akzeptablen Geschwindigkeit umsetzen zu können. In manchen Fällen ist nicht das reine Umsetzen, sondern der Prozess zur Inbetriebnahme eines Features die Herausforderung. Wenn nur zwei oder drei Releases im Jahr möglich sind, kann eine angemessene Time-to-Market nicht erreicht werden.
Risiken und Herausforderungen der Software-Migration
Auf dem Weg zu einer erfolgreichen Softwaremigration gibt es viele Stolpersteine. Von der Planung bis zur Implementierung erfordert jeder Schritt sorgfältige Überlegungen, eine definierte Vorgehensweise und auch immer wieder Reflexion. Das bedeutet allerdings nicht, dass es immer sinnvoll ist, den gesamten Prozess bis ins kleinste Detail im Vorfeld zu planen.
Risiko minimieren durch iteratives Vorgehen
In der Praxis hat sich gezeigt, dass viele Stolpersteine erst während der Migration erkannt werden können. Deshalb gilt es eine Strategie zu wählen, die die Risiken während der Migration minimiert. Die gewählte Strategie kann dann in einen groben Fahrplan überführt werden. Es kann sinnvoll sein, zunächst einzelne Teile der Software zu migrieren, um Aufwände und Komplexitäten besser abschätzen zu können und so das Risiko zu reduzieren.
Umgang mit Aufwandsexplosion
Viele Migrationen scheitern, weil der Aufwand initial als zu niedrig eingeschätzt wird. Später stellt man fest, dass man das geplante Budget zwar verbraucht hat, aber kein lauffähiges System hat. Bricht man die Migration ab, ist nichts erreicht.
Wir haben Migrationen erfolgreich abgeschlossen, in dem wir sie so geplant haben, dass wir sehr schnell erste Erfolge erzielen konnten. Die Zwischenergebnisse stellten bereits signifikante Verbesserungen dar. Wir führen Migrationen so durch, dass regelmäßig Versionen mit einem Mehrwert in Betrieb genommen werden können.
Dadurch ist auch eine regelmäßige Kosten-Nutzen-Rechnung der verbleibenden Migration möglich. Sollten die Kosten den Nutzen übersteigen, muss eine Migration auch abgebrochen werden können. Wenn das bis dahin Erreichte eine Verbesserung zum Initialzustand darstellt, war die Migration ein Erfolg obwohl sie nicht zu Ende durchgeführt wurde.
Internes Marketing
Ein kritischer Punkt, der gerne übersehen wird, ist die Benutzerakzeptanz bezüglich des Neusystems. Es ist unangenehm, wenn die Software-Migration erfolgreich abgeschlossen wurde, aber die Mitarbeiter Sturm gegen das neue System laufen. Deswegen ist es unerlässlich, dass die Mitarbeiter frühzeitig in die Migration einbezogen werden. Durch Schulungen können sie mit der neuen Software vertraut gemacht werden und so merken, dass auch sie Vorteile bekommen. Das Feedback der Mitarbeiter ist zudem wertvoll und kann das Endergebnis noch besser machen.
Allgemein wird es sehr positiv aufgenommen, wenn der Migrations-Fortschritt transparent im Unternehmen kommuniziert wird. Alle beteiligen Parteien sollten proaktiv über den Verlauf und eventuelle Verzögerungen unterrichtet werden. So werden Missverständnisse vermieden, Feedback wird ermöglicht und vielleicht sogar eine gewisse Vorfreude erzeugt.
Daten und Funktionen sichern
Es ist einfach, eine Applikation zu deinstallieren und eine neue zu installieren. Die Schwierigkeiten beginnen mit der Übertragung der Daten aus dem Bestandssystem in das neue System. Die Strukturen und Abhängigkeiten müssen verstanden werden. Gegebenenfalls ist die Qualität der Daten im Bestandssystem verbesserungswürdig. Wir legen großen Wert darauf, die Bestandsdaten zu verstehen und fachlich korrekt zu überführen. Dasselbe gilt für die wichtigen Funktionen des Bestandssystems.
Hier ist neben der Korrektheit und Vollständigkeit der Daten auch auf die Performance des Transformationsprozesses zu achten. Wenn die Übertragung zu lange dauert, muss man reagieren und die Migrationsprozess entsprechend verändern.
In 6 Schritten zur erfolgreichen Software-Migration
Schritt 1: Festlegung der Ziele und Anforderungen
Zu Beginn muss geklärt werden, welche Ziele mit der Migration verfolgt werden. Es muss die Frage beantwortet werden, was von dem System nach der Migration erwartet wird. Was soll anders sein und im Idealfall besser? Indem wir die Ziele und Anforderungen klären, wird sichergestellt, dass die neue Software den Bedürfnissen entspricht. Dies hilft bei der Auswahl des richtigen Migrationsansatzes und der geeigneten Tools.
Wenn mangelnde Software-Qualität ein Auslöser der Migration ist, dann muss eines der Ziele die Verbesserung derselben sein. In jedem Fall sollte sie mindestens aufrechterhalten werden. Eine Migration stellt auch immer die Chance dar, Fehler aus der Vergangenheit mit dem Wissen von heute zu korrigieren. Diese Chance sollte nicht verpasst werden.
Schritt 2: Analyse der aktuellen Software
Um die Migrationsstrategie wählen zu können, ist es wichtig, die Bestandssoftware sehr gut zu verstehen.
Wir haben viele erfolgreiche Migrationen durchgeführt, in dem wir zunächst analysiert haben, welche Teile der Software besonders wichtig sind und unbedingt in die neue Welt übernommen werden müssen. Das ermöglicht einerseits die Identifikation möglicher Risiken und gibt gleichzeitig einen Überblick über den Umfang der Migration.
Für die Analyse einer bestehenden Software haben wir sehr gute Erfahrungen mit Big-Picture Event-Stormings gemacht. Dies hat sich als effektive Methode erwiesen, um alle Prozesse und beteiligten Komponenten zu identifizieren. Bereits nach dem initialen Workshop ist in der Regel das gesamte Wissen über die Software zusammengeführt, und zwar von allen Stakeholdern und Entwicklern. Das Ergebnis des Workshops ist eine gute Grundlage zur Auswahl der Migrationsstrategie.
Schritt 3: Auswahl der richtigen Migrationsstrategie
Es gibt verschiedene Ansätze, die bei der Softwaremigration verwendet werden können. Die Wahl der richtigen Strategie hängt von verschiedenen Faktoren ab. Dazu gehören z.B. Art, Umfang und Komplexität der zu migrierende Software, dem verfügbaren Budget und den zeitlichen Einschränkungen.
Die Big-Bang-Strategie
Ein Ansatz ist die sogenannte "Big Bang"-Methode, bei der die gesamte Software auf einmal migriert wird. Dieser Ansatz birgt verschiedene Risiken sowohl fachlicher als auch technischer Natur. Die größte Herausforderung bei dieser Strategie ist es, dass die neue Software parallel zum Betrieb der alten entwickelt werden muss. In der Regel ist ein Feature-Freeze in der Bestandssoftware nicht möglich. Deshalb müssen alle Features, die während der Entwicklungszeit der neuen Software in die alte einfließen immer doppelt implementiert werden (einmal in der alten und einmal in der neuen Software).
Wir haben einmal eine Big-Bang-Migration durchgeführt, bei der es um den Wechsel einer Programmiersprache ging. Um das zu realisieren, wurde die neue Software auf Basis des Source-Codes der alten automatisch generiert. Ungefähr ein Jahr lang wurde täglich die automatische Migration testweise durchgeführt. Auf Basis des Ergebnisses wurde der Generator iterativ verbessert. Durch die automatische Migration konnte das doppelte Implementieren von Features vermieden werden. Die Entwicklung des Generators hat in diesem Projekt den großen Teil der Zeit des Projektes eingenommen. Die tatsächliche Migration (also das Generieren des Codes und der Wechsel der Software) wurde dann innerhalb eines Wochenendes durchgeführt.
Strangler-Fig-Application
Die zweite Kategorie von Migrations-Strategien ist die schrittweise Migration. Diese Strategien werden häufig Strangler Fig Application genannt. Der Name Strangler Fig bezieht sich auf einen Blog-Post von Martin Fowler. Er vergleicht darin die schrittweise Migration einer Software mit einer Schlingpflanze, die einen Baum umschlingt, bis er schließlich stirbt. Es werden also nach und nach Teile der Bestandssoftware ersetzt, bis diese schließlich abgeschaltet werden kann.
Feature-basierte Migration
In der Praxis setzen wir je nach Anwendung zwei Arten von schrittweisen Migrationen ein. Die erste ist die feature-basierte Migration. Jedes neue Feature wird komplett in der neuen Anwendung implementiert. Das Bestandssystem wird nur noch für die bestehenden Features verwendet. Die Herausforderung dieser Strategie ist, dass neue und alte Anwendung häufig auf dieselben Daten zugreifen. Diese Daten müssen kontinuierlich synchronisiert werden. Hierfür bietet sich das Event-Interception-Pattern an. Hat man dieses Pattern einmal etabliert, kann man nicht nur neue Features im neuen System umsetzen, sondern auch Features aus dem Bestandssystem Schritt für Schritt im neuen System implementieren.
Modulbasierte Migration
Da das Bestandssystem auch bei der feature-basierten Migration angepasst werden muss (um die Event-Interception zu implementieren), bietet sich an, die Modularisierung nicht auf Basis neuer Features vorzunehmen, sondern fachlich. Bei einem solchen Ansatz geht es zunächst darum, die Software konzeptionell in fachliche Module zu zerteilen. Wir bedienen uns in der Regel den Methoden des Domain Driven Design. Mit den dort existierenden Ansätzen können Bounded Contexts identifiziert werden, die als fachliche Module realisiert werden sollten. Hier eignen sich insbesondere Process Modelling Workshops und Software Design Workshops.
Die gefundenen fachlichen Module extrahiert man während der Migration Modul für Modul aus der Bestandssoftware.
Schritt 4: Planung des Migrationsprozesses
Je nach Migrationsstrategie verläuft die Migration unterschiedlich.
Plant man die Migration trotz aller Risiken als Big Bang, ist die größte Herausforderung die Doppelentwicklung von Features. Die Weiterentwicklung der Bestandssoftware kann nicht komplett gestoppt werden kann, während die neue Software entwickelt wird. Deshalb müssen alle Features, die in der Bestandssoftware neu entstehen, auch in die Entwicklung der neuen Software einfließen. Um das einzuplanen, muss von von vornherein eine Strategie entwickelt werden. Eine Möglichkeit zur Lösung dieses Problems ist die oben beschriebene automatische Migration.
Wählt man den modulbasierten Ansatz, muss zunächst überlegt werden, welches Modul zuerst extrahiert werden soll. Es bietet sich an, eines mit möglichst wenig Abhängigkeiten zu wählen. Auf diese Weise kann ein schneller Erfolg erzielt und das Vorgehen der Migration kann geübt werden. Wenn durch die ersten extrahierten Module eine gewisse Routine und auch Sicherheit gewonnen wurde, sollte ein Modul mit hoher Kritikalität gewählt werden. Das Gelingen der Extraktion eines solchen Moduls minimiert das Risiko der gesamten Migration erheblich.
Wählt man eine feature-basierte Migration, liegt der Fokus auf den Daten, die sowohl vom Bestandssystem und als auch von den neuen Features verändert werden. Für diese muss man eine kontinuierliche Synchronisation planen. Je nach Art des Bestandssystems kann diese Synchronisation unterschiedlich gestaltet sein. Mögliche Lösungen reichen von einem API Gateway, der Requests im neuen und im Bestandssystem ausführt, bis hin zu Datenbank-Triggern.
Schritt 5: Schrittweise Umsetzung des Migrationsplans
Bei der Umsetzung der Migration ist es wichtig, regelmäßige Feedback-Schleifen einzuführen. Wie bereits erwähnt, gibt es viele Stolpersteine, die häufig erst während der Migration auftreten. Dann ist es entscheidend, solche Stolpersteine frühzeitig zu erkennen, um den geeigneten Umgang damit bewusst zu planen. Hierzu ist es wichtig, die Software-Teams nicht allein losrennen zu lassen, sondern den Fortschritt kontinuierlich gemeinsam zu betrachten. Das große Ziel dieser Feedbackschleifen ist es, die Migration so sanft wie möglich zu gestalten und sie dennoch kontinuierlich voranzubringen.
Schritt 6: Erfolge im Blick behalten und kommunizieren
Wie bereits oben erwähnt, sollten alle beteiligten Personen auf dem Laufenden gehalten werden. Dies fördert die Akzeptanz der Migration innerhalb des Unternehmens. Insbesondere kleine Erfolge sollten regelmäßig kommuniziert werden.
Bei der Präsentation eines neuen Features sollte z.B. darauf hingewiesen werden, dass es auf Basis der neuen Plattform entstanden ist (ggf. mit dem Vermerk, dass dieses Feature erst durch die Migration möglich geworden ist).
Fazit
Jede Software-Migration ist anders und muss individuell geplant werden. Dennoch ist es sinnvoll, Erfahrungen aus vorherigen Migrationsprojekten einfließen zu lassen. Die gewählte Strategie muss sicherstellen, dass wichtige Daten und Funktionen sicher übertragen werden. Die Planung des Migrationsprozesses sollte so gestaltet sein, dass die täglichen Geschäftsabläufe so wenig wie möglich beeinträchtigt werden. Mit einer fundierten Analyse und einer soliden Planung kann das gelingen.
