Coexistence Architecture
Architekturmuster für das gleichzeitige Betreiben und die schrittweise Modernisierung von Legacy‑Systemen und neuen Komponenten.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Inkonsistente Datenzustände zwischen Systemen
- Versteckte Abhängigkeiten erschweren Extraktion
- Operative Kosten durch parallelen Betrieb erhöhen sich
- Automatisiertes Testing und Canary‑Releases nutzen
- Klare Integrationsverträge und Versionierung etablieren
- Observability entlang der Übergangsgrenzen sicherstellen
I/O & Ressourcen
- Inventar von Schnittstellen und Abhängigkeiten
- Betriebliche Anforderungen und SLAs
- Datenmodell‑ und Replikationsstrategie
- Definierte Integrationslayer und Übergangsarchitektur
- Reduzierter Monolith‑Funktionsumfang
- Metriken zu Konsistenz, Verfügbarkeit und Kosten
Beschreibung
Coexistence Architecture beschreibt Strategien, um bestehende Legacy‑Systeme und neue cloud‑native Komponenten gleichzeitig zu betreiben. Sie fokussiert auf Schnittstellenschichten, Entkopplung, Datenkonsistenz und schrittweise Migration, sodass Betrieb und Entwicklung koexistieren. Anwendungsfälle reichen von Strangler‑Patterns bis Hybrid‑Cloud‑Integrationen.
✔Vorteile
- Reduziert Migrationsrisiko durch inkrementelle Änderungen
- Ermöglicht parallelen Betrieb und kontinuierliche Lieferung
- Schützt Investitionen in bestehende Systeme
✖Limitationen
- Erfordert zusätzliche Integrations‑ und Betriebsaufwände
- Kann kurzfristig Komplexität und Redundanzen erzeugen
- Nicht alle Komponenten eignen sich für schrittweise Trennung
Trade-offs
Metriken
- Mean Time to Migrate (MTTM)
Durchschnittliche Zeit, um eine Funktion vom Altsystem in die neue Architektur zu überführen.
- Dateninkonsistenz‑Vorfälle
Anzahl und Schwere der Zwischenfälle mit inkonsistenten Datenzuständen.
- Betriebs‑Kosten paralleler Systeme
Monatliche Kosten für den parallelen Betrieb von Altsystem und neuen Komponenten.
Beispiele & Implementierungen
Strangler‑Pattern bei Legacy‑Webshop
Ein Onlineshop extrahiert Checkout‑Funktionen schrittweise in neue Services, während der alte Shop weiterläuft.
Hybrid‑Cloud für ERP‑Kernsystem
Kritische ERP‑Module verbleiben On‑Premise, ergänzende Analytik läuft in der Cloud mit synchronisierten Schnittstellen.
Event‑Bridge zur Datenkopplung
Ereignisbasierte Replikation stellt near‑real‑time Konsistenz zwischen Altsystem und neuen Microservices her.
Implementierungsschritte
Analyse: Schnittstelleninventar und Abhängigkeiten erstellen
Design: Integrationslayer und Migrationspfade definieren
Pilot: Kleine Domäne extrahieren und Monitoring implementieren
Iterieren: Lessons learned aufnehmen und schrittweise erweitern
⚠️ Technische Schulden & Engpässe
Tech Debt
- Temporäre Adapterschichten werden nicht entfernt
- Kurzfristige Datenkopien bleiben dauerhaft bestehen
- Unaufgeräumte Schnittstellen‑Versionen führen zu Fragmentierung
Bekannte Engpässe
Beispiele für Missbrauch
- Paralleler Betrieb wird unbegrenzt verlängert und erhöht Kosten
- Daten werden inkrementell dupliziert ohne Konfliktlösung
- Altsystem bleibt unverändert, neue Komponenten werden als Fassade geführt
Typische Fallen
- Unterschätzung versteckter Abhängigkeiten
- Fehlende Automatisierung für Tests und Deployment
- Unklare Verantwortlichkeiten zwischen Teams
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Bestehende proprietäre Schnittstellen können Migration begrenzen
- • Betriebliche SLAs während Koexistenz müssen eingehalten werden
- • Compliance‑ und Datenschutzanforderungen beeinflussen Datenflüsse