^{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. Eine vorgeschaltete Vermittlungsschicht leitet Anfragen entweder an das Altsystem oder an bereits erneuerte Komponenten weiter. Funktion für Funktion übernimmt das neue System, bis das alte keine Aufgaben mehr hat und stillgelegt werden kann.

• 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, und gemeinsam genutzte Daten müssen synchron gehalten werden.
• 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.

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:

1. Vollständige Neuentwicklung mit Stichtag („Big Bang“): Das neue System wird parallel entwickelt und an einem bestimmten Tag scharfgeschaltet.
2. 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. 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 in kleinen Schritten beherrschbar.

Die Umsetzung folgt in der Regel diesem Ablauf:

1. Fassade einziehen
   Zwischen die Nutzer (oder aufrufende Systeme) und das 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.
    
4. Anfragen umleiten
   Die Fassade leitet nun alle Anfragen für diesen 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.
    
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.

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 in die andere übertragen 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.

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.

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.

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.

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