Alltag im Leben vieler CIO’s der Banken- und Versicherungsbranche: eine heterogene Systemlandschaft, historisch gewachsene Anwendungen, Legacy-/ HOST-Systeme, Millionen Zeilen COBOL-Code.
Das alles muss koordiniert werden, verursacht hohe Betriebskosten und bremst aufgrund der geringen Produktivität in der Entwicklung die Innovationskraft – und das vor dem Hintergrund steigender regulatorischer Anforderungen und wachsenden Wettbewerbs. Und was passiert mit dem alten Code, wenn erfahrene Entwickler in Rente gehen und niemand mehr die Sprache beherrscht?Zeit, zu handeln
Altsysteme haben fachlich ihre Daseinsberechtigung – d.h. sie können nicht einfach abgeschaltet werden. Eine Neuentwicklung macht aufgrund der hohen Kosten und Risiken allerdings meistens keinen Sinn und häufig findet sich auch keine Standardlösung, welche die Anforderung hinreichend bedient. In einer solchen Situation ist ein Migrationsansatz interessant. Genau davor fürchten sich viele Entscheider – frei nach dem Sprichwort „Never change a running system“. Schließlich wird durch eine Migration eine Plattform, Middleware und/oder Sprache durch einen neuen, modernen Technologiestack ersetzt. All dies muss gerechtfertigt werden, zumal durch die Umstellung keine neuen fachlichen und damit auf den ersten Blick sichtbaren Features entstehen.
Die zentrale Frage bei Migrationsprojekten lautet also: Wie kann man die Migrationskosten und den -zeitraum überschaubar halten und gleichzeitig die Funktionalität und Performance sichern, sprich Risiken minimieren?
Projektkosten der manuellen vs. automatisierten Migration
Bei der traditionellen Methode, der manuellen Migration, richten sich die Kosten der Umstellung vor allem nach der Größe der Anwendung. Man stelle sich einen Entwickler mit zwei Bildschirmen vor: auf der einen Seite liest er den Programmcode des Altsystems (z.B. in COBOL), auf der anderen schreibt er neuen Code (z.B. in Java). Was bei kleineren Anwendungen Sinn machen kann, sorgt bei historisch gewachsenen Systemen für explodierende Aufwände. Falls sich das Altsystem während der Migration weiterentwickelt, erhöhen sich diese durch anfallende Doppelarbeiten sogar noch.
Automatische Migrationen laufen anders ab: hier legen die Entwickler nicht selbst Hand an, sondern bauen Migrations-Roboter. Diese Programme analysieren und transformieren den Code selbstständig. Der Aufwand richtet sich nicht nach der Größe des Programm-Codes, sondern nach Anzahl und Komplexität der darin vorkommenden Befehle. Dass diese Variante bei mehreren Millionen Code-Zeilen – wovon es sich bei 30 bis 50 Prozent um einfache Zuweisungen handelt – effizienter ist, liegt auf der Hand. Die Migration kann jederzeit und beliebig oft per Knopfdruck ausgeführt werden, wodurch die Weiterentwicklung der Altanwendung auch während der Migration erfolgen kann und ein späterer Frozen-Zone-Zeitpunkt im Projekt erreicht wird.
Minimiertes Risiko
Neben den Kosten spielt der Risikoaspekt bei Migrationsprojekten eine zentrale Rolle. In erster Linie muss sichergestellt werden, dass sich die migrierte Anwendung exakt so verhält wie das Original und keine Unterschiede in der Logik eingeführt werden. Das Problem des manuellen Ansatzes: Menschen machen Fehler. Jeder Entwickler kennt das – in der Hitze des Gefechts wird aus einem A = B schnell ein B = A, und schon funktioniert das Programm nicht mehr wie es soll. Selbst, wenn solche Fehler in nur 0,1 Prozent aller Zeilen vorkommen, werden daraus bei 1 Million Code-Zeilen 1.000 Probleme. Da diese nicht systematisch, sondern zufällig auftreten, besteht ein erhöhtes Risiko von versteckten und schwer erkennbaren Bugs.
Solche Fehler passieren Migrations-Robotern nicht. Zwar laufen auch automatisierte Migrationen nicht grundsätzlich fehlerfrei ab, hier treten Fehler jedoch systematisch auf und können genauso systematisch behoben werden. Wird ein bestimmter Befehl von einem Migrations-Roboter falsch umgesetzt, wirkt sich das auf jedes Auftreten dieses Befehls aus und ist leicht erkennbar. Ist der Fehler gefunden, erfolgt die Korrektur an zentraler Stelle und wirkt sich über die gesamte Anwendung aus. Das verringert die Anzahl der Bugs enorm und minimiert das Risiko.
Mein Fazit steht fest: Die automatisierte Migration überzeugt sowohl bei den Kosten als auch beim Risiko und gewinnt damit mit einem klaren 2:0. Sie minimiert Hemmschwellen, die grundsätzlich gegen eine Migration sprechen und ebnet den Weg für moderne und produktive Systeme.
Bildquelle: Shutterstock
