Geschichte der Frage: Bei Modernisierungsinitiativen in Unternehmen stoßen Business-Analysten häufig auf Wissenverfall – ein Phänomen, bei dem kritische Geschäftslogik nur in unlesbarem Legacy-Code überlebt. Diese Frage entstand aus Mainframe-zu-Cloud-Migrationen, bei denen die ursprünglichen Architekten vor Jahrzehnten in den Ruhestand gingen und COBOL-Programme hinterließen, die perfekt funktionieren, aber schwer zu interpretieren sind. Der historische Kontext umfasst den Übergang von monolithischer Batchverarbeitung zu verteilten Mikroservices, wo das implizite Zustandsmanagement explizite API-Verträge werden muss.
Das Problem liegt in der epistemischen Opazität: Das System funktioniert, aber niemand weiß warum. Der COBOL-Code enthält stille Geschäftsregeln – Grenzfälle, regulatorische Patches und manuelle Übersteuerungen –, die nie dokumentiert wurden, weil die ursprünglichen Entwickler sie im Gedächtnis hatten. Das aktuelle Betriebspersonal kennt die Eingaben und Ausgaben, aber nicht die Entscheidungslogik. In der Zwischenzeit erfordert die neue cloud-native Architektur, dass diese Regeln entkoppelt, dokumentiert und über REST-Endpunkte für den Echtzeitverbrauch bereitgestellt werden. Die feste regulatorische Frist erlaubt keine mehrjährige archäologische Ausgrabung, doch Fehler bei der Regelextraktion könnten gegen die Datenschutzvorschriften der GDPR oder die Richtigkeit der Finanzberichterstattung verstoßen.
Die Lösung verwendet einen Ansatz der triangulierten Rückentwicklung. Zuerst werden Event Storming-Workshops mit dem Betriebspersonal durchgeführt, um beobachtbare Geschäftsverhalten zu kartieren und „Black Box“-Prozesse zu identifizieren. Zweitens werden statische Codeanalysetools verwendet, um Kontrollflussgraphen der COBOL-Programme zu erstellen, wobei variable Mutationen mit Geschäftsergebnissen abgeglichen werden. Drittens wird ein parallel laufender Schattenmodus implementiert, in dem die neuen Mikroservice-Prozesse Transaktionen gegenüber dem Legacy-System spiegeln, ohne die Produktion zu beeinträchtigen und Abweichungen zur Untersuchung zu kennzeichnen. Dies schafft einen Feedback-Loop, in dem die Codearchäologie die Erinnerungen der Stakeholder validiert und der Kontext der Stakeholder die Codeanomalien erklärt.
Ein regionales Versicherungsunternehmen musste einen arealen COBOL-Policierungsbewertungsrechner aus den 1980er Jahren durch eine Python/FastAPI-Mikroservicesuite ersetzen, um Echtzeit-Handyangebote zu ermöglichen. Die ursprüngliche Berechnungslogik beinhaltete komplexe territoriale Risikogewichtungen, saisonale Anpassungsfaktoren und Klauseln für Rückversicherungsverträge, die über vierzig Jahre hinweg gepatcht worden waren. Die drei verbleibenden COBOL-Entwickler waren in den Ruhestand gegangen, und das aktuelle IT-Personal behandelte das System als „magische Box“, die korrekte Prämien erzeugte, aber die mathematischen Ableitungen für spezifische Grenzfälle nicht erklären konnte. Die Regulierungsbehörde forderte den Abschluss der Migration innerhalb von acht Monaten, um Strafen aufgrund nicht unterstützter Infrastruktur zu vermeiden.
Mehrere Ansätze wurden evaluiert, um die Anforderungen zu erfassen. Die erste Option schlug eine Code-zu-Spezifikation-Transkription vor, bei der Entwickler jede IF-Anweisung und jede MOVE-Operation im COBOL-Quellcode manuell dokumentieren würden. Die Vorzüge umfassten theoretische Vollständigkeit und Erhaltung der genauen Logik. Die Nachteile waren erheblich: Der Codebestand umfasste über zwei Millionen Zeilen Spaghetti-Code mit undokumentierten globalen Variablen, was dies zu einem mehrjährigen Aufwand machte, der die Frist verfehlen würde und wahrscheinlich Transkriptionsfehler einführen würde.
Die zweite Option schlug eine Black-Box-Anforderungsableitung vor, indem Eingaben (Policeneigenschaften) und Ausgaben (Prämienbeträge) beobachtet wurden, um Regeln durch statistische Regression abzuleiten. Die Vorzüge waren Geschwindigkeit und Fokus auf aktuellen Geschäftswert anstelle von technischem Schulden. Die Nachteile umfassten die Unfähigkeit, inaktive Codepfade für seltene Anspruchsszenarien zu erkennen, sowie das Risiko, Bugs als Features zu kodifizieren.
Die dritte Option, Verhaltensarchäologie mit paralleler Validierung, beinhaltete die Extraktion von Beispieldaten aus fünf Jahren Produktionsprotokollen, den Aufbau von Entscheidungsbäumen aus tatsächlichen Transaktionen und die Validierung dieser gegen den COBOL-Quellcode mit automatisierten Diff-Tools.
Das Team wählte die dritte Lösung, weil sie Geschwindigkeit mit Genauigkeit ausglich und das agile Prinzip von funktionierender Software über umfassender Dokumentation achtete. Durch die Konzentration auf ausgeführte Codepfade anstelle von inaktiven Funktionen reduzierten sie den Umfang um 60%, während sie garantierten, dass aktive Geschäftsregeln korrekt erfasst wurden. Sie richteten einen Datensee ein, der anonymisierte historische Transaktionen enthielt und diese sowohl durch die alten JCL-Jobs als auch durch die neuen FastAPI-Dienste lief, wobei automatisch Prämienberechnungsfehler über 0,01% gekennzeichnet wurden. Dies offenbarte drei entscheidende undokumentierte Bedingungen: eine Selbstbeteiligungsübersteuerung für Policen in Florida, die vor 1992 ausgestellt wurden, eine spezielle Berechnung der Provision für pensionierte Agenten und einen Rundungsfehler in der vierteljährlichen Steuerberichterstattung, der über Jahrzehnte hinweg durch manuelle Tabellenkalkulationen „korrigiert“ wurde. Die Mikroservices wurden neu gestaltet, um diese Grenzfälle ausdrücklich als konfigurierbare Geschäftsregeln zu behandeln, anstatt als fest kodierte Konstanten.
Wie unterscheiden Sie bei der Rückentwicklung von Legacy-Code zwischen einer kritischen Geschäftseinschränkung und einem technischen Workaround, der während der Migration sicher beseitigt werden kann?
Kandidaten nehmen oft an, dass alle bestehenden Logiken einem aktuellen Geschäftszweck dienen, und fallen in die Sunk-Cost-Fehlannahme der Erhaltung von Legacy. Der richtige Ansatz umfasst die Analyse des zeitlichen Kontextes: Untersuchung der Zeitstempel von Codeänderungen, um diese mit bekannten regulatorischen Änderungen, Fusionen oder Technologiebeschränkungen zu korrelieren, die nicht mehr existieren. Zum Beispiel könnte eine Datenabschneidungsroutine in COBOL nur deshalb existieren, weil das ursprüngliche DB2-Schema feste Breitenfelder verwendete, während modernes PostgreSQL variabel lange Zeichenfolgen unterstützt – wodurch das Abschneidungsregel komplett entfallen könnte. BAs müssen Absicht-Verifizierungssitzungen mit Geschäftsbeteiligten durchführen und vermutete Workarounds als „Wir können dies vereinfachen, indem wir X entfernen; beeinflusst dies Ihre Compliance?“ darstellen, anstatt zu fragen: „Sollten wir X behalten?“ Dies verschiebt die Beweislast auf die Notwendigkeit statt auf die Erhaltung.
Wie verhindern Sie das Anti-Pattern "Cargo Cult", bei dem das neue System ineffiziente Batch-Verarbeitungsabläufe lediglich reproduziert, weil sie im COBOL-Monolith existieren?
Viele Kandidaten konzentrieren sich ausschließlich auf die funktionale Parität, ohne Prozessneuengeneering. Der Fehler tritt auf, wenn BAs den aktuellen Zustand dokumentieren (z. B. „Das System führt jede Nacht um 2 Uhr ein Batch aus“) als Anforderung für den zukünftigen Zustand, und dabei ignorieren, dass ereignisgesteuerte Architekturen mit Apache Kafka oder RabbitMQ Echtzeitverarbeitung ermöglichen können. Die Lösung erfordert Fähigkeitszuordnung: Trennung des „Was“ (Risikoberechnung muss stattfinden) vom „Wie“ (Batch vs. Streaming). BAs sollten Wertstromanalysen durchführen, um Wartezeiten im Batch-Zeitplan zu identifizieren, die eher der operationale Bequemlichkeit als den Geschäftsregeln dienten. Durch die Darstellung, dass REST-Endpunkte sofortiges Feedback an Underwriter bieten können – wodurch die Angebotsbindungszeit von 24 Stunden auf 30 Sekunden verkürzt wird –, rechtfertigen sie architektonische Änderungen, die ansonsten als „zu unterschiedlich vom alten System“ abgelehnt würden.
Was ist Ihre Methodik zur Quantifizierung und Kommunikation des Risikos von "unbekannten Unbekannten" – stillen Regeln, die während Ihrer Beobachtungsperiode der Beispieldaten niemals ausgelöst wurden, aber nach der Migration katastrophal zum Vorschein kommen könnten?
Kandidaten präsentieren häufig den Beteiligten ein falsches Vertrauen, basierend auf 100% Testpassraten gegen historische Daten. Die differenzierte Antwort erkennt die Stichprobenverzerrung in den Legacy-Daten an und plädiert für Stresstest gegen synthetische Szenarien. Dies beinhaltet die Generierung von verzerrten Eingabedaten, die Grenzbedingungen austesten, die in Produktionsprotokollen nicht gesehen wurden, und dann die Ausgaben von COBOL und dem neuen System zu vergleichen. Darüber hinaus müssen BAs ein Circuit-Breaker-Muster in der neuen Architektur etablieren: Wenn der Mikroservice auf eine Transaktionsstruktur stößt, die er nicht verarbeiten kann (was auf eine potenziell verpasste Regel hinweist), sollte er elegant in die Rückruffunktion des alten SOAP-Wrappers (sofern verfügbar) zurückfallen oder zur menschlichen Überprüfung flaggen, anstatt stumm zu scheitern oder auf Nullwerte zurückzugreifen. Die Kommunikationsstrategie umfasst probabilistische Risikomatrizen, die zeigen, dass während 95% der Regeln validiert wurden, eine 5%ige Restunsicherheit einen dreimonatigen Hypercare-Zeitraum mit verdoppelten manuellen Abgleichprüfungen erfordert.