Führung von Legacy-Modernisierung: Aufsicht für das Strangler-Fig-Muster

Das Ende des Big-Bang-Ersatzes

Warum sequentielle Phasen nicht der Realität entsprechen

Traditionelles Projektdenken stellt sich Modernisierung als Sequenz vor: erst das Altsystem verstehen, dann entscheiden, was gebaut werden soll, dann bauen, dann migrieren. Jede Phase wird abgeschlossen, bevor die nächste beginnt. Führungskontrollpunkte markieren die Übergänge.

Dieses Denkmodell war sinnvoll, als Systeme in Big-Bang-Umstellungen ersetzt wurden — an einem Wochenende wird alles umgeschaltet. Aber Big-Bang-Ersetzungen werden immer seltener, und das aus gutem Grund. Sie konzentrieren Risiko auf einen einzigen Moment. Sie erfordern, das gesamte Altsystem zu verstehen, bevor irgendetwas davon ersetzt wird. Sie verlangen, dass das neue System vollständig ist, bevor jemand es nutzt.

Das Strangler-Fig-Muster funktioniert anders. Man identifiziert einen Funktionsbereich, versteht diesen Bereich, baut seinen Ersatz, migriert seine Nutzer und stellt dieses Stück des Altsystems ab — während der Rest weiterläuft. Dann wiederholt man das mit einem anderen Bereich.

Das bedeutet, dass zu jedem Zeitpunkt verschiedene Bereiche in verschiedenen Stadien sind. Man entdeckt noch einige Teile des Altsystems, während man bereits Nutzer von anderen Teilen migriert. Führung, die sequentielle Phasen annimmt, kann das nicht klar sehen.

Vier parallele Arbeitsstränge

Statt Phasen denken Sie an Modernisierung als vier Arten von Arbeit, die gleichzeitig stattfinden, wobei jede zu jedem Zeitpunkt für verschiedene Bereiche des Systems gilt.

Entdeckungsarbeit

Verstehen, was das Altsystem tatsächlich tut. Das ist

Handwerk: Untersuchung, Hypothese, Verifikation. Altsysteme akkumulieren Verhalten über Jahrzehnte. Dokumentation beschreibt Absicht, nicht Realität. Die Entwickler, die die Eigenheiten verstanden, sind weitergezogen.

Entdeckung geschieht während des gesamten Projekts, nicht nur am Anfang. Wenn man beginnt, an einem neuen Bereich zu arbeiten, entdeckt man Dinge über diesen Bereich. Wenn die Migration unerwartetes Verhalten offenbart, macht man Entdeckung. Wenn Nutzer berichten, dass das neue System etwas anders handhabt, erklärt Entdeckung warum.

Führungsfragen für Entdeckungsarbeit:

• Welche Bereiche untersuchen wir gerade?
• Was haben wir gelernt, das uns überrascht hat?
• Sprechen wir mit den Menschen, die jeden Bereich tatsächlich nutzen?
• Wird entdecktes Verhalten für künftige Bereiche dokumentiert?
• Finden wir Dinge, die Bereiche betreffen, von denen wir dachten, wir verstünden sie?

Entscheidungsarbeit

Entscheiden, was der Ersatz tun soll. Nicht jedes Legacy-Verhalten verdient Replikation. Einige Verhaltensweisen sind wesentliche Geschäftslogik; andere sind zufällige Komplexität aus alten Randbedingungen; andere sind Fehler, die Nutzer so lange umgangen haben, dass sie zu Erwartungen geworden sind.

Entscheidungsarbeit geschieht für jeden Bereich, wenn man sich darauf vorbereitet, seinen Ersatz zu bauen. Sie kann auch geschehen, wenn der Bau offenbart, dass frühere Entscheidungen falsch waren, oder wenn die Migration Verhaltensweisen aufdeckt, die niemand antizipiert hatte.

Führungsfragen für Entscheidungsarbeit:

• Welche Bereiche haben offene Entscheidungen?
• Wer ist an diesen Entscheidungen beteiligt? Ist das Geschäft vertreten?
• Welche Kompromisse gehen wir ein, und sind sie explizit?
• Unterscheiden wir zwischen „wie es funktioniert” und „wie es funktionieren sollte”?
• Werden Entscheidungen dokumentiert, damit künftige Bereiche davon lernen können?

Bauarbeit

Die Ersatzkomponenten bauen. Sobald man einen Bereich versteht und entschieden hat, was sein Ersatz tun soll, folgt der Bau oft Gewerbemustern — etablierte Ansätze, Standardrahmenwerke, vertraute Architekturen. Die Neuartigkeit lag in Entdeckung und Entscheidung; das Bauen ist Ausführung.

Mehrere Bereiche können gleichzeitig im Bau sein. Einige sind vielleicht fast fertig; andere fangen gerade an. Führung muss jeden verfolgen, ohne anzunehmen, dass alle im gleichen Stadium sind.

Führungsfragen für Bauarbeit:

• Welche Bereiche sind im Bau?
• Kann das Team für jeden die verbleibende Arbeit zuversichtlich schätzen?
• Werden Bereiche so gebaut, dass inkrementelle Migration ermöglicht wird?
• Validieren Integrationstests das Verhalten gegen echte Legacy-Daten?
• Offenbart der Bau Lücken in früherer Entdeckung oder Entscheidungen?

Migrationsarbeit

Nutzer und Daten vom Legacy-Bereich zu seinem Ersatz bewegen. Das ist oft die schwierigste Arbeit — nicht technisch, sondern operativ. Systeme parallel betreiben, Daten synchronisieren, Verkehr schrittweise verlagern, Randfälle behandeln, wo alt und neu sich unterschiedlich verhalten.

Migrationsarbeit kann Probleme aufdecken, die Sie zurück zur Entdeckung, Entscheidung oder zum Bau schicken. Ein Bereich, den Sie für fertig hielten, behandelt einen Fall, von dem Sie nichts wussten. Nutzer berichten Verhalten, auf das sie sich verließen, das der Ersatz nicht bietet. Die Integration zwischen dem neuen Bereich und verbleibenden Legacy-Komponenten funktioniert nicht wie erwartet.

Führungsfragen für Migrationsarbeit:

• Welche Bereiche sind in Migration?
• Welcher Prozentsatz des Verkehrs/der Nutzer ist zu jedem neuen Bereich gewechselt?
• Welche Probleme sind aufgetaucht, und wie werden sie angegangen?
• Sind wir auf Kurs, das Legacy-Stück abzustellen?
• Was blockiert die vollständige Migration für jeden Bereich?

Das Portfolio von Bereichen führen

Effektive Modernisierungsführung verfolgt ein Portfolio von Bereichen, von denen jeder in seinem eigenen Stadium ist. Das sieht weniger nach traditioneller Projektaufsicht aus und mehr nach Portfoliomanagement.

Eine nützliche Führungsansicht zeigt:

Bereich	Entdeckung	Entscheidungen	Bau	Migration	Blockierende Themen
Abrechnung	Fertig	Fertig	Fertig	60% migriert	Datensynchronisationslatenz
Nutzerauthentifizierung	Fertig	In Arbeit	Nicht begonnen	—	Wartet auf Sicherheitsprüfung
Berichtswesen	In Arbeit	—	—	—	Schlüsselnutzer im Urlaub
Inventar	Nicht begonnen	—	—	—	Abhängig von Abrechnung

Diese Ansicht offenbart mehrere Dinge, die traditionelle Projektverfolgung übersieht:

Abhängigkeiten zwischen Bereichen. Einige Bereiche können nicht starten, bis andere fertig sind. Einige teilen Komponenten. Führung kann diese Beziehungen sehen.

Wo Arbeit feststeckt. Ein Bereich, der seit Monaten „in Arbeit” bei Entscheidungen ist, braucht Aufmerksamkeit. Ein Bereich, der bei 40% Migration steht und sich seit Wochen nicht bewegt hat, hat ein Problem.

Ressourcenallokation. Wenn zu viele Bereiche im Bau sind und nichts migriert, vermeiden Teams möglicherweise die schwere operative Arbeit. Wenn alles in Entdeckung ist und nichts gebaut wird, ist Untersuchung vielleicht zur Ausrede für Untätigkeit geworden.

Tatsächlicher Fortschritt. Migrierte Bereiche mit abgestellten Legacy-Teilen repräsentieren echten Fortschritt. Alles andere ist laufende Arbeit.

Wenn Arbeitsstränge interagieren

Die parallele Natur der Strangler-Fig-Modernisierung bedeutet, dass Entdeckungen in einem Strang die Arbeit in anderen beeinflussen.

Entdeckung offenbart, dass eine Entscheidung falsch war. Ein Bereich im Bau braucht Fähigkeiten, die Sie entschieden hatten nicht einzuschließen. Überarbeiten Sie die Entscheidung, erweitern den Bereich, oder akzeptieren eine Lücke?

Der Bau enthüllt unvollständige Entdeckung. Das Bauen des Ersatzes bringt Legacy-Verhaltensweisen ans Licht, von denen niemand wusste. Pausieren Sie den Bau, dokumentieren und entscheiden schnell, oder bauen was Sie wissen und behandeln den Rest später?

Migration erweist den Ersatz als unzureichend. Nutzer in Produktion finden Probleme, die Tests übersehen haben. Rollen Sie zurück, reparieren vorwärts, oder betreiben beide Systeme länger?

Führung, die jede Rückwärtsbewegung als Versagen behandelt, schafft Anreize, Probleme zu verstecken. Führung, die Iteration akzeptiert, während sie echte Stillstände beobachtet, ermöglicht Teams, auf die Realität zu reagieren.

Signale über Arbeitsstränge hinweg

Statt Prozent-Fertigstellung zu verfolgen, beobachtet effektive Führung Signale, die den tatsächlichen Zustand offenbaren.

Gesunde Signale

• Bereiche bewegen sich in vernünftigem Tempo durch die Stadien — nicht unbegrenzt in irgendeinem Stadium steckengeblieben.
• Entdeckte Überraschungen führen zu expliziten Entscheidungen, nicht zu stillem Umfangswachstum.
• Die Baugeschwindigkeit ist einigermaßen konsistent, sobald Bereiche dieses Stadium erreichen.
• Migrationsprozentsätze steigen im Laufe der Zeit; Bereiche erreichen schließlich 100% und Legacy-Teile werden abgeschaltet.
• Probleme tauchen früh auf und werden angegangen; sie akkumulieren sich nicht still.

Warnsignale

• Mehrere Bereiche stecken in Entdeckung fest, ohne dass Entscheidungen getroffen werden.
• Entscheidungen werden ohne Geschäftsbeteiligung getroffen.
• Bau findet statt, aber keine Bereiche erreichen Migration.
• Migration stagniert bei Teilprozentsätzen — Parallelbetrieb wird permanent.
• Teams berichten grünen Status, während nichts tatsächlich in Produktion geht.
• Entdeckungsarbeit erweitert sich auf noch nicht geplante Bereiche, was Vermeidung schwieriger Bereiche andeutet.

Die Budgetfrage

„Wie viel wird das kosten?” ist schwer zu beantworten für Strangler-Fig-Modernisierung, weil Sie nicht eine einzelne Sache bauen — Sie ersetzen ein System Stück für Stück.

Ansätze, die funktionieren:

• Bereichsweise Budgetierung. Schätzen und finanzieren Sie jeden Bereich separat. Frühe Bereiche informieren Schätzungen für spätere ähnliche Bereiche. Variation mittelt sich über das Portfolio aus.

• Verbrauchsrate über Zeit. Statt „wie viel insgesamt” zu fragen, fragen Sie „wie viel pro Monat” und „wie lange.” Verfolgen Sie, ob die Verbrauchsrate proportionalen Migrationsfortschritt produziert.

• Wertbasierte Priorisierung. Nicht alle Bereiche sind gleich wertvoll. Priorisieren Sie Bereiche, die die meisten Schmerzen lindern, das meiste Risiko reduzieren oder die meisten Chancen ermöglichen. Hören Sie auf, wenn die verbleibenden Legacy-Teile den Ersatz nicht wert sind.

Ansätze, die scheitern:

• Gesamtkosten im Voraus zu verlangen. Sie wissen nicht, wie viele Bereiche existieren, bis Sie anfangen. Sie wissen nicht, wie schwer jeder Bereich ist, bis Sie daran arbeiten. Frühzeitige Gesamtschätzungen werden falsch sein.

• Alle Bereiche als gleichwertig zu behandeln. Einige Bereiche sind einfach; andere sind tief verflochten. Führung, die einheitlichen Aufwand annimmt, versteht die Arbeit falsch.

• Zu warten, bis alles „fertig” ist. Mit Strangler-Fig können Sie aufhören, wenn verbleibende Bereiche den Aufwand nicht wert sind. Führung sollte fragen „ist dieser Bereich es wert?” nicht nur „ist er fertig?”

Management-Rahmenwerke bieten nichts für die eigentliche Arbeit

Organisationen greifen bei der Führung von Modernisierung oft zu bekannten Management-Rahmenwerken. Das ist verständlich — Führungskräfte wollen Strukturen, die sie kennen. Aber hier ist eine unbequeme Wahrheit: Management-Rahmenwerke haben nichts zu bieten für die eigentliche Software-Entwicklungsarbeit. Sie helfen Entwicklern nicht, Legacy-Code zu verstehen, Architekturentscheidungen zu treffen, bessere Tests zu schreiben oder Nutzer sicher zu migrieren.

SAFe, LeSS, PMI, PRINCE2 und ähnliche Rahmenwerke befassen sich mit organisatorischer Koordination, Ressourcenallokation, Berichtsstrukturen und Stakeholder-Kommunikation. Das sind legitime Anliegen — aber sie sind vollständig getrennt von Software-Entwicklung. Kein Management-Rahmenwerk lehrt Sie, wie man eine Legacy-Codebasis refaktoriert, eine Strangler-Fassade entwirft, Verhaltensäquivalenz validiert oder Datenmigration handhabt. Keine Planungszeremonie produziert besseren Code. Keine Projektcharta verbessert Ihre Testabdeckung.

Das ist wichtig für Legacy-Modernisierung, weil die eigentliche Schwierigkeit vollständig in der technischen Arbeit liegt: verstehen, was das Altsystem wirklich tut, entscheiden, welches Verhalten bewahrt werden soll, Ersatz bauen, der korrekt funktioniert, und migrieren, ohne Nutzer zu stören. Management-Rahmenwerke schweigen zu all dem.

Was Management-Rahmenwerke adressieren:

• Wie man Stakeholdern Fortschritt berichtet
• Wie man mehrere Teams koordiniert
• Wie man Budgets über Initiativen verteilt
• Wie man Führungsausschüsse strukturiert
• Wie man Entscheidungen eskaliert

Was Management-Rahmenwerke nicht adressieren — und nicht können:

• Wie man undokumentiertes Legacy-Verhalten untersucht
• Wie man Ersatz entwirft, der parallel zu Altsystemen laufen kann
• Wie man testet, dass alt und neu äquivalente Ergebnisse produzieren
• Wie man Nutzer inkrementell ohne Datenverlust migriert
• Wie man Randfälle behandelt, die erst in Produktion auftauchen

Ansätze, die der Arbeit tatsächlich helfen:

Kanban-artige Visualisierung funktioniert für die Verfolgung von Bereichen über Stadien — aber das ist eine Visualisierungstechnik, kein Management-Rahmenwerk. Teams profitieren davon, Arbeitseinheiten durch Spalten mit WIP-Limits wandern zu sehen. Das Board sagt Ihnen nicht, wie Sie die Arbeit tun sollen; es hilft Ihnen zu sehen, wo Arbeit feststeckt.

Cynefin (Dave Snowden) hilft der Führung zu verstehen, warum verschiedene Arbeitsstränge unterschiedliche Ansätze brauchen — Entdeckungsarbeit lebt in der komplexen Domäne; Bauarbeit ist kompliziert. Aber auch das ist ein Sensemaking-Werkzeug zur Auswahl von Ansätzen, keine Vorschrift für deren Ausführung.

Realoptionen-Denken behandelt jeden Bereich als Option — in Entdeckung zu investieren kauft die Option zu bauen. Das hilft bei Priorisierungsentscheidungen, nicht beim eigentlichen Bauen.

Das Muster ist klar: Nützliche Ansätze helfen Ihnen zu sehen, zu entscheiden oder zu priorisieren. Keiner von ihnen hilft Ihnen, die technische Arbeit tatsächlich zu tun. Das erfordert Engineering-Kompetenz, Domänenwissen und praktische Erfahrung — nichts davon kommt aus Management-Rahmenwerken.

Die Gefahr:

Wenn Organisationen stark in die Einführung von Management-Rahmenwerken investieren, glauben sie oft, sie hätten die Modernisierungsherausforderung angegangen. Das haben sie nicht. Sie haben die Koordinations- und Berichtsherausforderung angegangen — die real, aber viel kleiner ist als die technische Herausforderung. Ein perfekt geführtes Projekt mit unzureichender technischer Fähigkeit wird trotzdem scheitern. Ein ungeführtes Projekt mit exzellenter technischer Ausführung könnte trotz des Chaos Erfolg haben.

Die Geduld für inkrementellen Fortschritt

Strangler-Fig-Modernisierung produziert inkrementellen Wert — jeder migrierte Bereich ist ein Stück Altsystem, das keine Wartung mehr braucht, ein Stück technische Schuld, das getilgt ist, eine Gruppe von Nutzern auf einem besseren System. Aber sie produziert keine dramatischen Meilensteine.

Führungskräfte, die an große Projektstarts gewöhnt sind, finden das möglicherweise unbefriedigend. Es gibt keinen Moment des Durchschneidens eines Bandes — nur das allmähliche Verlöschen der Lichter des Altsystems. Führung, die sichtbare Meilensteine verlangt, kann Druck erzeugen, Arbeit künstlich zu bündeln, wodurch die Risikoreduktion verloren geht, die inkrementelle Migration bietet.

Die Organisationen, die erfolgreich modernisieren, sind jene, in denen die Führung nachhaltigen Fortschritt über theatralische Meilensteine stellt. Sie feiern jedes abgestellte Legacy-Teil. Sie vertrauen darauf, dass das System besser wird, auch wenn es keinen einzelnen Moment gibt, auf den man zeigen kann. Sie verstehen, dass Software-Entwicklung erhebliche Designarbeit beinhaltet — und dass Designarbeit, die Bereich für Bereich angewandt wird, mit Lernen zwischen den Bereichen, bessere Ergebnisse produziert als der Versuch, alles im Voraus zu entwerfen.

Das Altsystem hat Jahre gebraucht, um gebaut zu werden, und Jahrzehnte, um sich zu entwickeln. Die Würgefeige wird auch Zeit brauchen — aber sie wird unterwegs Wert produzieren, nicht nur am Ende.