Zum Hauptinhalt springen

Case Study: Strangler-Pattern in der Praxis für risikoarme Modernisierung

Kontrollierte Ablösung einer SOAP-Schnittstelle durch REST in einem B2B-Portal​

Diese Case Study zeigt, wie sich eine bestehende SOAP-Integration in einem B2B-Portal mit dem Strangler-Pattern kontrolliert und ohne Downtime auf REST umstellen ließ.

Das Strangler-Pattern ist dabei keine theoretische Architekturidee, sondern eine praktische Vorgehensweise: Neue Funktionalität wird parallel aufgebaut, alte bleibt bestehen. Umschalten erfolgt erst, wenn die neue Variante fachlich und technisch stabil ist.

Im Folgenden beschreibe ich ein konkretes Szenario aus einem B2B-Portal eines Maschinenbaukonzerns.

Ausgangssituation​

In einem B2B-Portal für das Onboarding neuer Mitarbeiter war ein externer SOAP-Endpunkt (A) angebunden. Der externe Anbieter stellte zusätzlich einen neuen REST-Endpunkt (B) bereit, der perspektivisch den SOAP-Service ablösen sollte.

Rahmenbedingungen:

  • Externe Vertragsschnittstelle durfte nicht unterbrochen werden.
  • Keine Downtime.
  • Fachlich identische Ergebnisse erforderlich.
  • Hohe Sensibilität, da Onboarding-Prozesse produktiv genutzt wurden.

Eine direkte Umschaltung von SOAP auf REST kam daher nicht in Frage.

Umsetzung des Strangler-Patterns​

1. Parallele Implementierung​

Zunächst wurde ein REST-Client für Endpunkt B implementiert.

Wichtig dabei:

  • Keine Änderung an der bestehenden öffentlichen Schnittstelle.
  • Beide Clients (SOAP und REST) wurden unter derselben internen Abstraktion bereitgestellt.
  • Die bestehende Integrationslogik blieb unangetastet.

Das System konnte somit weiterhin wie bisher mit „Implementierung A“ arbeiten.

2. Routing zwischen Implementierung A und B​

Ein internes Routing entschied, welche Implementierung aktiv genutzt wird:

  • A → SOAP-Client
  • B → REST-Client

Dieses Routing war konfigurierbar und zur Laufzeit steuerbar. Dadurch war ein kontrolliertes Umschalten möglich – ohne Deployment und ohne Systemneustart.

3. Paralleles Logging und Payload-Validierung​

Der entscheidende Schritt war die Messbarkeit.

Beide Implementierungen wurden parallel aufgerufen. Die Antworten wurden protokolliert und strukturell verglichen.

Konkret:

  • Speicherung der vollständigen Response-Payloads.
  • Vergleich der relevanten Felder.
  • Identifikation von Abweichungen im Datenmodell.
  • Erkennung semantischer Unterschiede (z. B. Statuswerte, Null-Felder, Default-Werte).

Diese Protokollierung erlaubte:

  • Fachliche Validierung.
  • Technische Validierung.
  • Nachweis der Gleichwertigkeit beider Varianten.

Fehler oder Abweichungen konnten isoliert analysiert werden, ohne dass das Produktivsystem beeinträchtigt wurde.

4. Umschaltung und Entfernung der Alt-Implementierung​

Nachdem der REST-Client über einen ausreichend langen Zeitraum stabil und fachlich korrekt lief, wurde das Routing dauerhaft auf Implementierung B umgestellt.

Erst danach wurde die SOAP-Implementierung deaktiviert und aus dem Code entfernt.

Zu keinem Zeitpunkt war ein externer Partner betroffen.
Zu keinem Zeitpunkt entstand Downtime.
Zu keinem Zeitpunkt wurde ein bestehender Vertrag gebrochen.

Vorteile des Strangler-Patterns in diesem Szenario​

Diese Vorgehensweise brachte mehrere konkrete Vorteile:

Keine Breaking Changes​

Die öffentliche Schnittstelle blieb unverändert.
Alle Änderungen fanden intern statt.

Vergleichbarkeit von Alt- und Neusystem​

Durch paralleles Logging und Payload-Validierung konnten Ergebnisse objektiv verglichen werden.
Die Entscheidung zur Umschaltung war datenbasiert – nicht gefühlt.

Rückfallmöglichkeit​

Solange beide Implementierungen existierten, konnte jederzeit zurückgeschaltet werden.
Das reduzierte operatives Risiko erheblich.

Technische Transparenz​

Durch strukturierte Protokollierung entstand eine klare Nachvollziehbarkeit:

  • Welche Daten liefert SOAP?
  • Welche Daten liefert REST?
  • Wo existieren Unterschiede?
  • Sind diese fachlich relevant?

Fazit​

Das Strangler-Pattern ist kein Selbstzweck.
Es ist eine pragmatische Methode, um neue Funktionen oder Schnittstellen in Enterprise-Systemen einzuführen, ohne bestehende Integrationen zu destabilisieren.

In diesem Fall bedeutete es:

  • Paralleler Aufbau einer neuen REST-Integration.
  • Messbare Validierung durch Payload-Vergleich.
  • Kontrolliertes Umschalten.
  • Entfernung der Alt-Implementierung erst nach Stabilitätsnachweis.
hinweis

Moderne Systeme entstehen in Enterprise-Umgebungen nicht durch radikale Ersetzung, sondern durch kontrolliertes Überlagern. Das Strangler-Pattern bietet dafür einen klar strukturierten, technisch sauberen Weg.