Migrationsstrategien im Vergleich

Unter Migration versteht man jegliche Art von Umstellung und häufig ist das ganze Anwendungssysteme betroffen. Zwar können die Gründe für solch einen Prozess vielfältig sein, Ziel ist jedoch immer, fachliche Funktionen zu erhalten.

Know-how  –  0 Kommentare
Migrationsstrategien im Vergleich

Der Begriff "Migration" bezeichnet eine technische Transformation, bei der die Anforderungen klar definiert sind. Allgemein lassen sich Migrationen dem Software Reengineering zuordnen, wo sie neben zentralen Vorhaben wie Wartung, Systemerhaltung, Integration, Erweiterung, Sanierung, Redokumentation oder Ablösung eine hervorgehobene Rolle einnehmen (vgl. [1]). Meist werden sie so lang wie möglich hinausgezögert. Sollte das System alle Anforderungen erfüllen, ist das zwar legitim, manchmal sind Transformationen jedoch unumgänglich.

Eine in der Literatur häufig erwähnte Alternative ist, auf Standardsoftware umzusteigen. Allerdings stellt das für die meisten Organisationen keine Option dar, da es für spezielle Anforderungen keine solche Software gibt. Die weiteren Ausführungen beschreiben Migrationsstrategien sowohl in Bezug auf die Art der Transformation als auch auf die Art der Umstellung und Übergabe der migrierten Software.

Ein Migrationsprojekt durchläuft diverse Phasen, in denen Tätigkeiten aus spezifischen Kern- oder unterstützenden Basisbereichen relevant sind (Abb. 1). Während der Konzept- und Designphase bestimmt das Team die Transformations- und Migrationsstrategie, die zum Einsatz kommen soll.

Ein Migrationsprozess setzt sich aus vielen Einzelschritten zusammen (Abb. 1).

Die Transformationsstrategie beschreibt die technische Umsetzung einer Migration. Sie spezifiziert für jede Systemkomponente, durch welche Technik (Neuentwicklung, Kapselung oder Konversion) Daten und Programme in die neue Umgebung beziehungsweise Form zu überführen sind (vgl. [2]).

Harry Sneed beschreibt in seinem Buch "Objektorientierte Softwaremigration" [3] drei Vorgehensweisen in Migrationsprozessen:

  • Neuentwicklung
  • Konversion
  • Kapselung

Bei einer Neuentwicklung weist das Team den Daten neue Strukturen zu. Dabei kann es sie umformatieren oder umschlüsseln. Prinzipiell lässt sich alles ändern, nur die Werte bleiben erhalten und damit die semantische Bedeutung der Daten. Bei Programmen wird nur das Wissen über deren bisherige Funktion weiterverwendet. Der Programmcode ist komplett neu zu schreiben.

Bei einer Konversion versuchen die Entwickler, durch Transformation so viel wie möglich aus dem bisherigen System zu übernehmen. Dabei werden nicht nur die Daten umgewandelt, sondern auch die Programme. Allerdings sollte die Wiederverwendbarkeitsrate des Altsystems sehr hoch sein, denn eine automatische Überführung von einer Programmiersprache in eine andere ist zwar theoretisch möglich, jedoch meist nur nach einer aufwendigen Sanierung des Altsystems. Daher bleibt meist nur die Kapslung oder Neuentwicklung.

Mehr Infos

Sonderheft "Altlasten im Griff"

Mehr Artikel zum Thema Legacy-Code sind im Sonderheft iX Developer 01/2017 zu finden, dass sich unter anderem im heise Shop erwerben lässt.

Bei der eben erwähnten Sanierung handelt es sich um ein Aufbereiten von Daten, Programmen und Oberflächen, um sie danach automatisiert migrieren zu können. Sneed splittet die automatisierte Datensanierung in zehn Schritte auf. Oberflächensanierung wäre nötig, um die Form der Benutzerschnittstellen von deren Inhalt, sowie die Präsentationslogik von der Applikationslogik zu trennen. Zur Programmsanierung gehören Aspekte wie Reformatierung, Konstantenbereinigung, Zugriffsauslagerung, Verfeinerung und Restrukturierung. Eine Sanierung ist in den meisten Fällen sehr aufwendig.

Bei einer Kapselung sind Daten und Programme von einem Wrapper zu umhüllen, der für sie Schnittstellenfunktionen bereitstellt. Dadurch können verteilte Applikationen auf beides in Form von Objekten und Diensten zugreifen. Das Ziel der Kapselung ist das Belassen von Daten und Programmen in ihrer bisherigen Umgebung. Wenn die Aufgabe jedoch ist, einen klassischen Host-Betrieb durch ein Client-Server-System abzulösen, ist solch ein Vorgehen keine Alternative. Des Weiteren kann auch mangelndes Wissen über das Altsystem oder eine zu geringe Wiederverwendbarkeitsrate zu Schwierigkeiten führen.

Grundsätzliche Entscheidungskriterien dafür, welcher Weg einzuschlagen ist, sind das eingeplante Kapital, der vorgesehene Zeitraum, die zur Verfügung stehenden Mitarbeiter, das Wiederverwendungspotenzial der Komponenten sowie die Qualität der Altsoftware (vgl. [3]). Bei einer systematischen Entscheidungsfindung für die jeweils angemessene Strategie kann eine Portfolio-Analyse unterstützen.