Was spricht für die automatisierte Transformation?

• Sie bestimmen Umfang und Zeitpunkt
  Sie entscheiden, wann und in welchem Umfang die automatisch transformierten (Teil-)Anwendungen produktiv gesetzt werden.
• Ohne Einfluss auf die Wartung, beliebig wiederholbar
  Die in der Wartung geänderten Komponenten können laufend in den Transformations- und Test-Zyklus einbezogen werden.
• Geringere Kosten
  Abhängig von der Komplexität und der Anzahl der involvierten Entwicklungssprachen kostet die Transformation einer LOC zwischen einem und vier Dollar.
• Kürzere Projektdauer
  Die Projektdauer von automatisierten Projekten liegen in der Regel zwischen einem und zwei Jahren.

Lerneffekt

• Bei lernenden Automaten wird jeder erkannte Fehler vollständig beseitigt und tritt nicht wieder auf. Automaten machen keine Flüchtigkeitsfehler.
• Bei Menschen ist der Lerneffekt geringer, je grösser das Team ist.
• Flüchtigkeitsfehler und ähnliches verringern sich nicht.

Automatisierte vs. manuelle Prozesse

• Automatische Prozesse sind beliebig oft, mit wenig Aufwand und schnell wiederholbar.
• Tests der automatischen Änderungen können beliebig vorgezogen werden, ohne Einfluss auf laufende Entwicklungen oder Produktion.
• Eine Fehlerrate von (nahezu) Null ist so erreichbar – bevor die eigentlichen Änderungen beginnen
• Sie entscheiden, wann und in welchem Umfang die automatisch transformierten (Teil-)Anwendungen produktiv gesetzt werden.

Qualitätsaspekte

• Änderungen pro Komponente hundertfach beschleunigt
  • in Minuten, statt in Tagen bei manuellem Prozess
• Änderungen sind jederzeit 1:1 reproduzierbar
• Änderungen sind absolut gleichförmig
  
  • Keine Tagesform, kein persönlicher Stil, keine Flüchtigkeitsfehler
• Änderungen werden automatisch dokumentiert
• Teilprozesse können (zeitlich) getrennt werden
  • Erfassen, Analysieren und Ändern

Ohne Einfluss auf die Entwicklung

• (Teil)Systeme werden vollständig erfasst und im Zusammenhang analysiert und automatisch transformiert
• Ausschnitte davon werden getestet und ausgewertet
• Mit neuen Erkenntnissen aus Analyse und Test wird die Factory optimiert und der Zyklus bei Bedarf wiederholt

Deployment - ohne (direkten) Einfluss auf die Produktion

• Aus der optimierten Factory werden Pakete beliebiger Größe auf Abruf bereitgestellt, falls notwendig auch neu analysiert
• Aufwand und Dauer jeweils in Minuten und Stunden (pro Paket!)
• Nur wenige Mitarbeiter werden benötigt
• Skalierung via Hardware

Manuelle Migration - Nachteile

Manueller Änderungsprozess - arbeitsintensiv, langwierig, unsicher

• Software-Komponenten oder (Teil-)Anwendungen, die massiv geändert werden müssen, sind für die Wartung praktisch eingefroren («freezed»).
• In Komponenten, an denen dringende Wartungsaufgaben durchgeführt worden sind, müssen sämtliche Änderungen wieder neu eingebaut und getestet werden.
• Wie die Erfahrung lehrt, ist der Zeitpunkt der produktiven Einführung kaum voraussehbar.

• Beim manuellen Änderungsprozess
  • wird Komponente für Komponente wird erfasst, analysiert und geändert,
  • liegen Aufwand und Dauer jeweils bei Stunden und Tagen,
  • kann ein Mitarbeiter immer nur eine kleine Zahl von Komponenten gleichzeitig bearbeiten,
  • erfolgt die Skalierung via Manpower,
  • sind Fehler und Flüchtigkeitsfehler an der Tagesordnung.

Legacy-Systeme«'Legacy code' often differs from its suggested alternative by actually working and scaling.» — Bjarne Stroustrup wurden manuell entwickelt. Eine Vielzahl von Entwicklern denkt und arbeitet auch heute mit manuellen Entwicklungsmethoden. Entsprechend verblüfft es nicht, dass häufig auch eine manuelle Migration als normaler Weg für eine Legacy Modernisierung angedacht wird.
Diese Vorgehen erbringt aber häufig keine befriedigenden Ergebnisse, aus einer Reihe von Faktoren:

• Kosten
  Gemäss einer Studie der Gartner Group (Gartner Group study «Forecasting the Worldwide IT Services Industry: 1999/1») liegen die Kosten für ein manuelles Umschreiben einer Zeile Software Code zwischen 6 und 26 Dollar. Diese Kosten dürften zwischenzeitlich eher noch gestiegen sein. Die Conversion-Rate liegt bei ca. 160 LOC (Lines of Code) am Tag.
  Dieser Annahme lag zu Grunde, dass eine Migration von zwei relativ ähnlichen Sprachen vorliegt und kein Paradigmen-Wechsel zwischen z.B. einer objektorientierten Sprache (z.B. Java) und einer prozedural entwickelte Sprache (z.B. Cobol) vorliegt.

• Zeit
  Gemäss Gartner dauert die Migration von einer Million LOCs ca. 28+ Personenjahre Arbeitszeit; für ein Team von 10 Entwicklern dauert dies rund 3 Jahre. Im Falle von umfangreicheren Legacy Systemen bedürfte es grösseren Teams, um die Gesamtprojektdauer nicht weiter zu verlängern.
  Grössere Teams bedeuten jedoch mehr Aufwand, welches die Conversion Rate weiter verlangsamt. Daher muss das Neu-Schreiben von bereits 10 Mio LOC schlicht als nicht praktikabel angesehen werden – alleine bereits aus Sicht des Projektführung und des Zeitfaktors.

• Verändernde Anforderungen
  Aufgrund des Umstandes, dass umfangreiche Migrationen langwierig und kostspielig sind, ist es schwierig bis unmöglich im Laufe eines Projektes zusätzliche Anforderungen in das Projekt oder gar Funktionalitäten in das neue Zielsystem zu bringen. Neben einer verlängerten Projektdauer, einem höheren Risiko wird zusätzlich das Testen der Ergebnisse hinsichtlich z.B. Vollständigkeit erschwert, da das Ursprungssystem nicht mehr den identischen Output wie das neue Zielsystem erbringt.

• Gegenläufige Ziele
  Während das Migrations-Team mit dem Aufbau einer neuen Ziel-Plattform beschäftigt ist, müssen die bisherigen Legacy-Applikationen nach wie vor fehlerfrei ihren Dienst tun. Dafür müssen sie laufend den sich ändernden Anforderungen der Unternehmung angepasst werden. Jede Änderung bedeutet jedoch für das Migrations-Team einen grossen Aufwand, welcher die Migrationstätigkeit einschränkt oder sogar zurückwirft und dazu führen kann, dass bereits migrierter Software Code neu geschrieben werden muss.
  Dies führt zu einer «Rivalität» zwischen einem optimal funktionierenden Produktiv-System und dem Ziel der Migration.

• Unmöglichkeit von wichtigen Änderungen
  Keine Planung ist für die Ewigkeit. Während der Migrationsphase wird es daher zwangsläufig zu Zielanpassungen kommen. Dies können Unternehmensziele sein, Verbesserungen bei den Migrationstechniken, Behebung von Migrationsfehlern.
  Das Problem bei manuell konvertiertem Code liegt darin, dass funktionierende Software-Teile nur ungern angepasst werden und ein nachträgliches Anpassen dieses Codes bei der manuellen Anpassung eher vermieden wird. Derart wird entweder verhindert, dass der migrierte Code nicht der neuen Zielsetzung angepasst wird oder die Qualität des migrierten Codes leidet, da bereits gelöste Probleme nicht an allen Stellen behoben werden.

• Ungleiche Entwicklungsqualität
  Das Ergebnis einer manuellen Migration ist zwangsläufig abhängig von der Qualität der einzelnen Entwickler im Migrations-Team. Da das Know-how und die Erfahrung der einzelnen Teammitglieder unterschiedlich ist, variiert auch der entwickelte Software-Code und verursacht steigende Unterhaltskosten beim neuen Zielsystem.