Seite 2: Migrationsszenarien

Inhaltsverzeichnis

Mögliche Migrationsszenarien

Neben der Überlegung, welche Module des Altsystems sich durch Neuentwicklung, Kapselung oder Konversion migrieren lassen, stellt sich die Frage, welche Strategie für die Übergabe zu wählen ist. Grundsätzlich unterscheidet man zwischen inkrementeller und Big-Bang-Umstellung. Die Übergabestrategie legt – abhängig von der gewählten Umstellungsstrategie – die Form der Übergabe ("Cut-over") des migrierten Systems und damit zusammenhängend die Form der Ablösung des Legacy-Systems fest. Projektleiter müssen entscheiden, ob das migrierte System als Gesamtheit zu einem bestimmten Termin oder schrittweise in den operativen Einsatz zu übergeben ist (vgl. [2]).

Beim Big Bang Approach, der auch unter dem Namen "Cold Turkey" (sinngemäß etwa "harter Entzug") bekannt ist, handelt es sich um eine komplette Neuentwicklung des Altsystems mit modernen Entwicklungsmethoden, Architekturen, Tools und Datenbanken. Der Prozess läuft zudem auf neuen Hardwareplattformen. Entwicklung und Tests für das neue System finden parallel zum alten statt. Hat die Neuentwicklung alle Tests bestanden, deaktiviert das Operations-Team in einem finalen Schritt, dem "Big Bang", das Altsystem und das neue übernimmt die Arbeit.

Dieses Vorgehen birgt laut M. Brodie und M. Stonebraker [4] einige Schwierigkeiten. Zunächst muss ein besseres System versprochen werden, denn meistens reicht dem Management die vage Aussicht auf geringere Betriebskosten in der Zukunft nicht. Außerdem stehen die Geschäftsregeln niemals still, das heißt, Änderungen sind sowohl im Altsystem als auch im neuen System umzusetzen beziehungsweise anzupassen. Das kann fehleranfällig und kostenintensiv sein. Spezifikationen sind rar, oft ist der Code die einzige Dokumentation. Die Entwickler des alten Systems sind häufig nicht mehr verfügbar. Dadurch wird das Verständnis der Funktionsweisen von Code oder der Programmiertechniken erschwert. Meist existieren nicht dokumentierte Abhängigkeiten zu anderen Systemen. Ihre Anzahl wächst erfahrungsgemäß mit dem Alter der Applikationen.

Die Datenmenge ist eventuell zu groß, um sie in angemessener Zeit zu migrieren, da ein Dump oder der Export der Daten schon Tage oder Wochen dauern kann, was somit zu einer inakzeptablen Downtime der Produktionsumgebung führen würde, da in der Zeit weitere Änderungen an den Daten verhindert werden müssen.

Zu bedenken ist darüber hinaus, dass das Managen solch großer Projekte kompliziert ist, Verspätungen normalerweise nicht toleriert werden und große Projekte dazu tendieren, sich aufzublähen, also umfangreicher ausfallen als geplant. Führt man sich das alles vor Augen, kann die Angst vor Veränderung und der neuen Technik die Liebe zum alten System aufblühen lassen, was durch mangelnde Motivation ebenfalls die Migration erschwert. Langwierige Analysen verhindern den Projektbeginn zusätzlich, denn statt zu starten wird analysiert und analysiert.

Brodie und Stonebraker lehnen den Flash Cut, also den abrupten Umstieg, der dem Big Bang Approach zu Grunde liegt, grundsätzlich ab. Sie sagen, dass er ohne eine Downtime von Datenbank oder Applikation nicht möglich ist (vgl. [4]). Zu den Vorteilen dieser Variante zählen die geringen Entwicklungskosten und die Geschwindigkeit des Migrationsprozesses.

Kleinteilig vorgehen

Die Chicken-Little-Alternative ist eine inkrementelle Migrationsstrategie mit elf Schritten. Je kleiner die Schritte, desto kleiner das Risiko. Sollte ein Schritt fehlschlagen, ist nur er zu wiederholen, nicht das ganze Projekt (vgl. [4]).

Für eine derartige Strategie ist es notwendig, das Gesamtsystem in kleine Pakete unterteilen zu können, um im Anschluss eins nach dem anderen zu migrieren. Um Anfragen und Daten zwischen den betroffenen Komponenten des Alt- und Neusystems zu übersetzen und Komponenten von Änderungen an anderen Komponenten abzuschirmen, kommen temporär Gateways zum Einsatz (siehe Abb. 2). Außerdem ist es ihre Aufgabe, zwischen den betroffenen Komponenten zu koordinieren, um die Konsistenz bei Änderungen sicherzustellen. Tabelle 1 enthält einen Vergleich der Migrationsstrategien Cold Turkey und Chicken Little.

Tabelle 1: Migrationsstrategien im Vergleich
	Cold Turkey	Chicken Little
Risiko	Groß	Kontrollierbar
Fehleranfälligkeit	Das ganze Projekt schlägt fehl.	Nur einzelne Schritte schlagen fehl.
Ergebnisse	sofort nach Fertigstellung sichtbar, eventuell aber nicht von langer Dauer	Nutzen steigt stetig mit der Entwicklung des neuen Systems
Ausblick	Nicht vorhersagbar bis zum Endergebnis	Konservativ optimistisch

Beim Analysieren des Altsystems ist zwischen unstrukturierten, semistrukturierten (siehe Abb. 3) und gut strukturierten Systemen zu unterscheiden. Bei gut strukturierten Systemen sind Präsentation, Datenzugriff und Logik voneinander getrennt. Bei unstrukturierten ist das Gegenteil der Fall und alles passiert in einem Modul. Gut strukturierte Systeme sind gut für eine inkrementelle Migration geeignet. Bei allen anderen Zuständen sind meist umfangreiche Sanierungsarbeiten am Altsystem zu leisten. In semistrukturierten Systemen lässt sich die Präsentationsschicht noch separieren, jedoch sind die Anwendungs- und Datenschicht eng miteinander verbunden.

Die in Tabelle 2 erläuterten elf Chicken-Little-Schritte sind bei der Migration eines jeden Inkrements anzuwenden. Entwickler können sie in einer beliebigen Reihenfolge durchführen und nicht benötigte weglassen. Chicken Little bedeutet im Endergebnis zwar eine komplette Neuentwicklung des Systems, allerdings mit geringeren Risiken als beim Big-Bang-Ansatz (vgl. [4]).

Tabelle 2: Chicken Little in elf Schritten
1. Inkrementelle Analyse des Altsystems	Anforderungen des Altsystems sind zu spezifizieren. Eventuell muss das Altsystem mit Reverse-Engineering-Techniken analysiert werden.
2. Inkrementelle Strukturierung des Altsystems	Bei semi- oder unstrukturierten Systemen sind Abhängigkeiten zwischen Modulen zu eliminieren und eindeutig definierte Schnittstellen zwischen Modulen und Datenbankservices zu erstellen.
3. Inkrementelles Design der Ziel-Interfaces	Spezifikation der Benutzerschnittstellen und Entscheidung darüber, ob ein Gateway zu erstellen ist.
4. Inkrementelles Design der Zielanwendungen	Entwickler übernehmen Funktion und Prozessfluss der Altanwendungen oder erstellen sie neu.
5. Inkrementelles Design der Zieldatenbank	Eventuell sind Tabellen in relationalen Schemas anders zu gestalten.
6. Inkrementelles Installieren der Zielumgebung	Anforderungen an die Zielumgebung werden identifiziert, installiert und getestet.
7. Inkrementelles Erstellen und Installieren von Gateways	Entsprechend der Anforderungen (Funktionen, Architektur und nicht funktionalen Anforderungen) ist ein Gateway zu entwickeln oder zu kaufen und zu installieren.
8. Inkrementelles Migrieren der Datenbank	Installation des Datenbankmanagementsystems (DBMS) und Implementierung des Schemas aus Schritt 5.
9. Inkrementelles Migrieren der Anwendungen	Auswahl und Migration eines oder mehrerer Module
10. Inkrementelles Migrieren der Interfaces	Auswahl und Migration eines oder mehrerer Interfaces
11. Inkrementelles Umschalten auf die Zielumgebung	Das System lässt sich Modul für Modul, Oberfläche für Oberfläche umschalten (Cut-over).