Schrittweise Ablösung von 20 Jahre altem COBOL-Code
Mainframe-Code, der seit über 20 Jahren läuft, ist der Motor Ihres Unternehmens. Doch bis 2027 werden 92 % der COBOL-Entwickler in den Ruhestand gehen. Der „Big Bang“-Ansatz, bei dem das gesamte System auf einmal ausgetauscht wird, führt dazu, dass 7 von 10 Projekten scheitern. Anstatt alles auf einmal aufzureißen, sollten Sie mit den Modulen beginnen, die den höchsten geschäftlichen Mehrwert bieten.
Priorisieren Sie Module mit der höchsten Änderungsfrequenz
Unterteilen Sie alle Module mithilfe einer IRC-Matrix. Dabei werden Einfluss (Impact), Risiko (Risk) und Komplexität (Complexity) bewertet. Fassen Sie nicht den gesamten 1-Million-Zeilen-Monolithen auf einmal an. Das Ziel sind die 50.000 Zeilen der „Hotspots“, die am häufigsten geändert werden.
- Durchsuchen Sie die Git-Logs. Extrahieren Sie die Module, die im letzten Jahr am häufigsten modifiziert wurden. Wenn die Änderungsrate des Codes 25 % übersteigt, ist das ein Hotspot.
- Klassifizieren Sie jedes Modul von Tier 1 bis 4. Verschieben Sie zuerst die Tier-1-Module – das sind Funktionen, die direkt vom Kunden genutzt werden und bei denen Datenfehler nur geringe Auswirkungen haben.
- Zeichnen Sie den Datenfluss mit Mermaid-Diagrammen. Trennen Sie Module mit geringer Abhängigkeit vom bestehenden Code, indem Sie sie mit einer externen API ummanteln.
Dies spart im Vergleich zur kompletten Neuentwicklung 40 % der anfänglichen Kosten. Kleine Erfolge beseitigen die Unsicherheit innerhalb des Teams.
Erkennen Sie Datenunterschiede durch Shadow Execution
Bei der Umstellung des COMP-3-Datentyps von COBOL auf BigDecimal in Java treten häufig Fehler bei Finanzberechnungen auf. Um Betriebsstörungen zu vermeiden, ist eine „Shadow Execution“ (Schattenausführung) unerlässlich, bei der derselbe Datenverkehr gleichzeitig durch das alte und das neue System geleitet wird.
- Implementieren Sie ein Proxy-Tool wie Diffy. Replizieren Sie den operativen Datenverkehr und senden Sie ihn an das neue System.
- Vergleichen Sie die Ergebnisse des bestehenden Systems mit denen des neuen Systems in Echtzeit. Zeitstempel oder IDs, die sich ständig ändern, sollten mithilfe von Filterregeln ausgeschlossen werden.
- Binden Sie Skripte in die Pipeline ein, die VSAM-Copybook-Daten auf SQL-Schemas abbilden. Richten Sie Alarme ein, die nur bei Unstimmigkeiten ausgelöst werden.
Wenn Sie die Präzision der neuen Logik anhand tatsächlicher Transaktionen nachweisen, entfällt das Risiko von Betriebsunterbrechungen.
Verhindern Sie Legacy-Verschmutzung mit einer Anti-Corruption Layer
Sie müssen verhindern, dass schwer verständliche Legacy-Modelle in das neue System übertragen werden. Nutzen Sie dafür die Anti-Corruption Layer (ACL) des Domain-Driven Design.
- Verwenden Sie das Fassaden-Muster (Facade Pattern). Kapseln Sie komplexe Legacy-Aufrufe in einer einfachen REST-API.
- Platzieren Sie ein Routing-Gateway mithilfe des „Strangler Fig“-Musters. Leiten Sie den Datenverkehr schrittweise nur auf die Funktionen um, deren Modernisierung bereits abgeschlossen ist.
- Trennen Sie Aufrufer und Implementierung mit dem Bridge-Muster. So können Sie die interne Logik austauschen, ohne die API-Endpunkte der bestehenden Schnittstellen-Abteilungen anrühren zu müssen.
Das neue Entwicklungsteam behält einen unabhängigen Stack bei, bis das Legacy-System vollständig verschwunden ist. Sobald die Modernisierung abgeschlossen ist, muss nur noch die ACL gelöscht werden.
Sichern Sie das Budget mit einem 4-Schichten-TCO-Framework
Manager reagieren eher auf Verlustbeträge als auf technische Schulden. Modernisierung ist ein Kostensenkungsprojekt. Einem Bericht von Deloitte zufolge sind 70 bis 80 % der Wartungskosten für Altsysteme in der Regel unterschätzt.
- Summieren Sie die direkten Kosten (MIPS), indirekten Kosten (40 % der Entwicklungszeit für Legacy-Patches), Compliance-Kosten und Opportunitätskosten. Dokumentieren Sie in Ihrem Bericht die Gesamtverlustsumme, die entsteht, wenn nicht modernisiert wird.
- Fügen Sie die erwarteten Effekte nach der Umstellung der Tier-1-Module in Zahlen hinzu. Visualisieren Sie in einem Dashboard, wie sich der Release-Zyklus von 6 Monaten auf 2 Wochen verkürzt und wie stark die Zeit bis zur Wiederherstellung (MTTR) sinkt.
- Zitieren Sie das Beispiel der ING-Bank. Nehmen Sie die „Warm Standby“-Strategie für die sofortige Wiederherstellung bei Fehlern sowie einen 90-Tage-Hypercare-Plan in Ihre Roadmap auf.
Ein solcher Bericht ist kein technisches Glücksspiel. Es ist eine finanzielle Investition, die die Rendite (ROI) von 288 % auf 362 % steigern kann.
makedream