^{EXPERTEN-INSIGHTS}

Das Strangler Fig Pattern ist ein Architekturmuster, mit dem ein bestehendes Softwaresystem schrittweise durch ein neues ersetzt wird, ohne es auf einen Schlag abzuschalten. Zwischen der Legacy Applikation und den Konsumenten dieser wird zuerst eine Zwischenschicht eingeführt, die weiterhin die Sprache der alten Applikation spricht. Nach und nach werden Teile aus der Legacy Applikation modernisiert und in eine neuen Applikation verfrachtet. Die zuvor eingeführte Zwischensicht kann transparent zwischen alter Welt und neuer Welt übersetzen und routet Anfragen die bereits von der neuen Applikation verarbeitet werden können zu dieser. Sobald alle Funktionen übersiedelt wurden kann die Legacy Applikation stillgelegt werden und die Zwischenschicht entfernt werden.

• Der Begriff geht auf den Softwareentwickler Martin Fowler zurück, der das Muster 2004 beschrieb, ursprünglich als „Strangler Application“.

• Kernstück ist eine Fassade (etwa ein Reverse Proxy oder API-Gateway), die jede Anfrage an das alte oder das neue System weiterleitet.

• Das Muster verringert das Risiko einer Ablösung, weil jeder Schritt klein, überprüfbar und umkehrbar ist.

• Es verursacht zusätzlichen Aufwand: Beide Systeme laufen parallel. Gemeinsam genutzte Daten müssen synchron gehalten werden.

• Nicht immer gelingt es die alten und neuen Systeme strikt voneinander zu trennen. Oftmals müssen Legacy Applikation und moderne Applikation miteinander kommunizieren können

• Es eignet sich nicht, wenn sich Anfragen an das Altsystem nicht abfangen lassen oder das System so klein ist, dass ein vollständiger Austausch einfacher wäre.

• Bei der Entwicklung des neuen Systems muss darauf geachtet werden dass keine legacy Datenmodelle aus dem Altsystem in das neue “leaken”. Dies kann oft dazu führen dass alte Probleme auch wieder im neuen System auftauchen.

Viele Unternehmen betreiben Software, die über Jahre oder Jahrzehnte gewachsen ist. Solche Legacy-Systeme sind oft geschäftskritisch, basieren aber auf veralteten Technologien, sind schwer zu warten oder hängen vom Wissen weniger Personen ab.

Für die Ablösung gibt es grundsätzlich zwei Wege:

• Vollständige Neuentwicklung mit Stichtag („Big Bang“): Das neue System wird parallel entwickelt und an einem bestimmten Tag scharfgeschaltet.

• Schrittweise Ablösung: Das neue System übernimmt Stück für Stück, während das alte weiterläuft.

Der Big Bang wirkt auf den ersten Blick einfacher, birgt aber erhebliche Risiken. Über Jahre entwickelte Geschäftslogik ist selten vollständig dokumentiert, Anforderungen ändern sich während der Neuentwicklung, und der Nutzen zeigt sich erst am Ende. Load-Patterns unter Produktionslast in der neuen Applikation sind oft schwierig abzuschätzen und damit ist die Performance des neuen Systems unter “echten” Bedingungen oft nicht hundertprozentig vorhersebar. Scheitert die Umstellung am Stichtag, trifft das den gesamten Betrieb.

Das Strangler Fig Pattern ist die bekannteste Umsetzung des zweiten Wegs. Es macht eine Ablösung beherrschbar, indem alles in kleinen Schritten abgelöst wird. Das verringert Feedback-Zyklen, gibt dem Entwicklungsteam bereits frühzeitig die Möglichkeit das neue System unter echten Bedingungen zu testen und der Betrieb des Altsystems bleibt während der gesamten Migration gesichert. Das Risiko verteilt sich also auf viele kleine, jederzeit rücksetzbare Schritte, statt sich an einem einzigen Stichtag zu konzentrieren.

1. Fassade einziehen
   Zwischen Nutzer (oder aufrufende Systeme) und dem Altsystem wird eine Vermittlungsschicht gesetzt, die sogenannte Fassade. Technisch ist das oft ein Reverse Proxy oder ein API-Gateway. Zu Beginn leitet sie alle Anfragen unverändert an das Altsystem weiter. Für die Nutzer ändert sich nichts.
    

2. Ersten Funktionsbereich auswählen
   Man bestimmt einen fachlich abgegrenzten Bereich, der zuerst erneuert wird. Dabei hilft der Ansatz des Domain-Driven Design, das ein System entlang fachlicher Zuständigkeiten gliedert, etwa „Rechnungsstellung“, „Kundenverwaltung“ oder „Lagerbestand“.
    

3. Funktion neu umsetzen
   Der ausgewählte Bereich wird als eigenständige, moderne Komponente neu gebaut. Das Altsystem bleibt dabei unverändert in Betrieb.
   Oft benötigt die neue Applikation Daten aus der Legacy-Welt. Um die Datenmodelle der neuen Welt nicht zu sehr am Legacy-System orientieren zu müssen, können Patterns wie Anti-Corruption-Layer (ACL), Change Data Capture (CDC) oder ETL eingesetzt werden, um eine konsistente Sicht auf Business-Daten in der alten und der neuen Applikation zu gewährleisten.
    

4. Anfragen umleiten
   Nachdem das neue System deployed wurde, leitet die Fassade alle Anfragen für den ausgewählten Bereich an die neue Komponente weiter, alle übrigen weiterhin an das Altsystem. Die Umstellung lässt sich oft schrittweise vornehmen, etwa zunächst nur für einen Teil der Nutzer, und im Fehlerfall rasch zurücknehmen. Die Fassade nimmt Anfragen weiterhin im Format des Altsystems an und übersetzt diese u.U. in ein für die neue Applikation verständliches Format. Client Apps die keine Funktionalitäten der Legacy Application benötigen können die legacy API umgehen und direkt mit der modernen Applikation kommunizieren. Dies ermöglicht es neue Features die nur in der modernen Applikation angeboten werden können bereits zu konsumieren.
    

5. Wiederholen
   Dieser Zyklus wiederholt sich Bereich für Bereich. Mit jedem Durchgang übernimmt das neue System mehr Aufgaben.
    

6. Altsystem stilllegen
   Sobald keine Anfrage mehr beim Altsystem ankommt, kann es abgeschaltet werden. Die Fassade wird danach entweder entfernt oder bleibt als Übersetzungsschicht für ältere Anwendungen bestehen, die weiterhin die alte Schnittstelle nutzen wollen.

1. Früher, sichtbarer Nutzen
   Erfolgreiche Projekte liefern innerhalb weniger Wochen oder Monate den ersten produktiv genutzten Baustein. Das schafft Vertrauen bei Stakeholdern und verhindert, dass die Migration zum Dauerprojekt ohne erkennbaren Fortschritt wird. Der erste Schnitt wird deshalb bewusst klein, risikoarm und mit wenigen Abhängigkeiten gewählt.
    
2. Sauberer fachlicher Schnitt
   Die Bereiche werden entlang fachlicher Grenzen (Bounded Contexts) geschnitten, nicht entlang technischer Schichten. Wer zuerst "das Frontend" oder "die Datenbank" ablöst, erzeugt Abhängigkeiten, die den Vorteil der schrittweisen Ablösung wieder auffressen.
    
3. Klare Datenstrategie von Anfang an
   Das ist meist der härteste Teil. Erfolgreiche Teams klären früh, welches System für welche Daten führend ist, wie synchronisiert wird (CDC, Events, ETL) und wie lange Dual-Betrieb akzeptabel ist. Gemeinsam genutzte Datenbanken zwischen Alt und Neu ohne Übersetzerschicht sind ein häufiger Fehlerherd, weil sie das Altschema faktisch auch in der neuen Applikation einzementieren.
    
4. Absicherung beim Umschalten
   Dazu gehören schrittweises Ausrollen (Canary, Feature Flags, Umschaltung pro Nutzergruppe), schneller Rollback und oft ein Parallelbetrieb mit Ergebnisvergleich (Shadow Traffic, Parallel Run). So wird das neue System unter realer Last validiert, bevor es verbindlich wird.
    
5. Konsequentes Abschalten
   Der Punkt, an dem viele scheitern: Das Altsystem wird nie wirklich stillgelegt, und man betreibt am Ende zwei Systeme dauerhaft. Erfolgreiche Projekte planen die Stilllegung von Beginn an mit, messen den Anteil migrierter Funktionen und Traffic und setzen verbindliche Abschaltziele.
    
6. Das Altsystem wird nicht "nebenbei" weiterentwickelt
   Neue Features landen idealerweise nur noch im neuen System. Wird im Altsystem weiter intensiv ausgebaut, läuft die Migration einem beweglichen Ziel hinterher.

Ein Handelsunternehmen betreibt ein über 15 Jahre gewachsenes Warenwirtschaftssystem. Statt es komplett neu zu entwickeln, zieht das Team eine Fassade ein und beginnt mit der Rechnungsstellung, weil sie fachlich klar abgegrenzt ist und häufig geändert werden muss. Nach deren Umstellung folgen die Kundenverwaltung und später der Lagerbestand. Das Altsystem verliert mit jedem Schritt Aufgaben, bis es schließlich nicht mehr gebraucht wird. Zu keinem Zeitpunkt steht der Betrieb still.

(Das Beispiel ist bewusst vereinfacht und dient der Veranschaulichung.)

In der Praxis liegt die eigentliche Schwierigkeit selten in der Fassade, sondern in den Daten. Altsystem und neue Komponenten greifen während der Übergangszeit oft auf dieselben Informationen zu. Dafür gibt es mehrere Lösungswege:

• Die neue Komponente liest und schreibt vorerst in die bestehende Datenbank. Das ist einfach, bindet das neue System aber weiter an die alte Datenstruktur.

• Die neue Komponente erhält eine eigene Datenbank, die mit der alten synchron gehalten wird. Ein verbreitetes Verfahren ist Change Data Capture, bei dem Änderungen in der einen Datenbank automatisch erkannt und über Message Queues oder spezialisiertes Tooling in eine andere Datenbank übertragen werden.

• Die neue Komponente schreibt Änderungen zurück ins Altsystem. Oft muss das Altsystem noch auf denselben Daten arbeiten wie die neue Komponente, daher müssen deren Änderungen dorthin synchronisiert werden. Das ist deutlich aufwendiger als der Abgleich in nur eine Richtung: Es braucht eine klare Datenhoheit pro Datenbereich oder eine Konfliktbehandlung, und es muss verhindert werden, dass Änderungen Endlosschleifen auslösen. Außerdem sollte die bidirektionale Synchronisation so rasch wie möglich aufgelöst werden, sodass die Daten nur noch im neuen System gepflegt werden.

• Eine Übersetzungsschicht (im Fachjargon Anti-Corruption Layer) sorgt dafür, dass das neue System nicht die Begriffe und Strukturen des alten übernehmen muss.

Welcher Weg passt, hängt davon ab, wie eng die Daten verflochten sind und wie lange der Parallelbetrieb dauern wird. Diese Entscheidung sollte vor dem ersten Schritt fallen, nicht währenddessen.

Das Muster eignet sich, wenn:

• ein System zu groß oder zu kritisch ist, um es an einem Stichtag zu ersetzen,

• sich das System in fachliche Bereiche gliedern lässt,

• Anfragen an das System an einer zentralen Stelle abgefangen werden können und

• der Betrieb während der Modernisierung weiterlaufen muss.

Das Muster eignet sich eher nicht, wenn

• sich Anfragen an das Altsystem nicht abfangen lassen, weil es keine Stelle gibt, an der eine Fassade ansetzen könnte,

• das System so klein oder überschaubar ist, dass ein vollständiger Austausch weniger Aufwand bedeutet,

• die Bestandteile so eng verflochten sind, dass sich keine eigenständigen Bereiche herauslösen lassen, oder

• das Altsystem kurz vor dem Ausfall steht und keine Zeit für eine schrittweise Ablösung bleibt. Dann geht Stabilisierung vor Modernisierung.

1. Die Fassade wird zum Engpass. Weil alle Anfragen durch die Fassade laufen, darf sie weder zum einzigen Ausfallpunkt noch zur Leistungsbremse werden. Sie muss entsprechend robust und überwacht betrieben werden.
    
2. Die Ablösung bleibt auf halbem Weg stehen. Die ersten, klar abgegrenzten Bereiche lassen sich meist gut umstellen. Schwierig wird es bei den eng verflochtenen Kernfunktionen. Bleibt das Vorhaben dort stecken, betreibt ein Unternehmen dauerhaft zwei Systeme statt einem. Ein klares Zielbild mit Abschaltdatum für das Altsystem beugt dem vor.
    
3. Der Parallelbetrieb wird unterschätzt. Während der Übergangszeit fallen Betriebs- und Wartungskosten für beide Systeme an. Das gehört von Anfang an in die Planung.
    
4. Die falsche Reihenfolge. Wer mit dem komplexesten Bereich beginnt, riskiert frühe Rückschläge. Bewährt hat sich, mit einem fachlich klar abgegrenzten Bereich zu starten, der spürbaren Nutzen bringt, aber überschaubares Risiko birgt.

• Branch by Abstraction: Ähnliches Prinzip, jedoch innerhalb des Programmcodes. Eine Abstraktionsschicht ermöglicht es, eine Komponente im Code schrittweise auszutauschen. Das ist hilfreich, wenn es keine äußere Schnittstelle gibt, an der eine Fassade ansetzen könnte.

• Anti-Corruption Layer: Eine Übersetzungsschicht zwischen altem und neuem System, damit das neue Modell sauber bleibt. Oft in Kombination mit dem Strangler Fig Pattern eingesetzt.

• Patterns of Legacy Displacement: Eine auf martinfowler.com veröffentlichte Sammlung von Mustern für die Ablösung von Altsystemen, die das Strangler Fig Pattern um weitere Techniken ergänzt, etwa das Abfangen von Ereignissen oder die schrittweise Übernahme einzelner Datenbestände.

Das Strangler Fig Pattern ist kein Allheilmittel, aber für große, geschäftskritische Altsysteme oft der sicherste Weg zur Modernisierung. Es tauscht das Risiko eines einzigen großen Umstiegs gegen viele kleine, beherrschbare Schritte und nimmt dafür einen längeren Parallelbetrieb in Kauf. Entscheidend für den Erfolg sind eine saubere fachliche Gliederung, ein durchdachter Umgang mit gemeinsam genutzten Daten und das konsequente Ziel, das Altsystem am Ende tatsächlich abzuschalten.

TIMETOACT GROUP Österreich modernisiert gewachsene Systeme schrittweise, häufig nach dem Strangler-Fig-Muster. Welcher Einstieg zu Ihrer Situation passt, zeigt unsere Übersicht zur Software-Modernisierung. Wenn der Betrieb eines Altsystems gesichert und parallel modernisiert werden soll, ist Legacy Takeover & Modernisierung der passende Service.

Quellen und weiterführende Literatur

• Martin Fowler: Strangler Fig Application, martinfowler.com
• Microsoft: Strangler Fig pattern, Azure Architecture Center (auch auf Deutsch als „Strangler-Muster“)
• AWS: Strangler fig pattern, AWS Prescriptive Guidance
• Sam Newman: Monolith to Microservices, O'Reilly