Agile Migration

Ein neuer, agiler Ansatz zur Vereinfachung der Migration hochkomplexer Systeme

Auch wenn Re-Engineering in den meisten Fällen unsere bevorzugte Methode ist, gibt es doch Fälle, bei denen andere Ansätze sinnvoll sind. Zum Beispiel wenn ein Standardprodukt existiert, das die Bedürfnisse komplett abdeckt oder wenn im Systemstack eine weitere Anwendung die gleichen Aufgaben wahrnimmt und angepasst werden soll um eine Alt-Anwendung zu ersetzen. Bei solchen Projekten stellt sich oft die Frage wie man die eigentliche Migration von der alten Anwendung auf die neue gestaltet. In sehr einfachen Fällen schaltet man von der alten auf die neue Anwendung und es funktioniert. Aber das ist eher die Ausnahme. In der Regel kommuniziert eine Anwendung mit vielen anderen Anwendungen. Und da eine Systemlandschaft historisch wächst, sind unter diesen anderen Anwendungen auch etliche Alt-Anwendungen die ebenfalls abgelöst werden sollten. Wenn jetzt die neue Anwendung Unterstützung für diese Anwendungen einbaut, ist das mit hohen Kosten verbunden. Zudem ist diese Investition nicht nachhaltig, denn wenn die anderen Alt-Anwendungen abgelöst werden, werden diese Schnittstellen nicht mehr gebraucht. Dass eine alte und eine neue Anwendung die gleichen Schnittstellen nutzen, kommt eigentlich nur vor, wenn man von einer Version einer Standardsoftware auf eine neuere Version migriert. Meistens ist es auch nicht sinnvoll, alte Schnittstellen für neue Software zu übernehmen, denn man möchte auf neue Technologien oder Architekturen setzen, die sich in der Zwischenzeit etabliert haben. Auch fachliche Anforderungen spielen eine Rolle: Neue Produkte die unterstützt werden sollen oder zusätzliche Daten die benötigt werden. Im Ergebnis sind neue und alte Anwendungen schlicht nicht kompatibel und eine Alt-Anwendung nach der anderen zu migrieren wäre sehr aufwändig und ist in den meisten Fällen nicht sinnvoll.

Anschaulich werden die Unterschiede in der obenstehenden Abbildung dargestellt. Hier werden die gleichen Systeme auf beiden Wegen migriert. Im unteren Teil, bei der Big Bang Migration, wird nur ein Schritt durchgeführt, der allerdings teuer und riskant ist. Im oberen Teil, bei der Agilen Migration werden stattdessen viele kleine Schritte durchgeführt. So kann man mit geringerem Risiko ein System nach dem anderen migrieren und dabei flexibel auf geänderte Anforderungen und Probleme eingehen. Am Ende der Migration ist das Ergebnis in beiden Fällen das gleiche, eine neue Systemlandschaft, ohne Rückstände der Alt-Anwendungen.

Eine andere Option bietet die Big Bang Migration. Man koordiniert die einzelnen Ablösungsprojekte und migriert alle Anwendungen auf einmal. Dadurch muss man sich keine Gedanken um alte Schnittstellen machen, alle neuen Anwendungen können sich darauf einstellen, nur die neuen Schnittstellen unterstützen zu müssen. Das ist der Hauptgrund, warum dieser Ansatz so oft verwendet wird. Allerdings hat der Ansatz auch viele Nachteile. Zum einen erfordert die Koordination viel Arbeit. Die einzelnen Migrationsprojekte werden meist von verschiedenen Teams bearbeitet. Da alle Migrationen gleichzeitig erfolgen müssen, muss also der Fortschritt der Teams auch synchronisert werden. Verzögert sich die Arbeit bei einem Projekt, werden auch die anderen Teams mit ihrer Migration warten müssen. Treten während oder nach der Migration schwerwiegende Probleme an einer der neuen Anwendungen auf, bleibt kein anderer Ausweg als wieder von den neuen auf die alten Anwendungen zu schalten, und nach erfolgreicher Fehlerbehebung erneut die Migration zu versuchen. Solche Migrationen sind deshalb sehr teuer, riskant und schwer durchzuführen. In Folge dessen erlebt man häufig, dass sie hinausgezögert oder schlichtweg nicht durchgeführt werden, weil sich niemand findet, der das Risiko auf sich nehmen möchte.

Unser Ansatz, den wir Agile Migration genannt haben, setzt bei diesen Problemen an. Statt einer großen Migration für alle Anwendungen, migrieren wir jede Anwendung einzeln. Um die Probleme mit den alten Schnittstellen zu vermeiden, lagern wir diese in eine eigene Komponente, den Adapter, aus. Der Vorteil ist, dass die neuen Anwendungen frei von Altlasten bleiben. Aus Sicht der Entwickler dieser Anwendungen gibt es nur die anderen neuen Anwendungen. Somit werden alle Probleme der Big Bang Migration von dem Adapter abgefangen. Da der Adapter als Übersetzer zwischen neuen und alten Anwendungen arbeitet kann er Verzögerungen und Rollbacks abfangen. Jede Anwendung kann nun unabhängig von den anderen geplant und umgesetzt werden, die Projekte sind entkoppelt. Nachdem alle Komponenten erfolgreich migriert wurden, kann der Adapter abgeschaltet werden und alle "Altlasten" sind nun restlos aus der Systemlandschaft entfernt. Das ist ein großer Vorteil der Entscheidung die alten Schnittstellen in eine eigene Komponente auszulagern, denn ansonsten bleiben diese "Altlasten" in der neuen Anwendung und müssten erst aufwändig wieder zurückgebaut werden. Vor einer Migration sollte man deshalb abwägen welchen Ansatz man wählt und den Ansatz wählen der für die eigene Situation am sinnvollsten ist.

Die nachfolgende Tabelle stellt nochmal die Agile Migration und die Big Bang Migration gegenüber:

Die agile Migration ist in den meisten Fällen eine lohnenswerte Alternative zur Big Bang Migration, mit der wir und unsere Kunden sehr gute Erfahrungen gemacht haben.

Wie können wir Ihnen helfen? Wenden Sie sich einfach an info(at)tngtech.com, oder nutzen Sie eine der anderen Kontaktmöglichkeiten. Wir unterstützen Sie gerne!