A
Experience-Welt
Versicherer A
- Individuelle Customer Experience
- Portal, Identity Provider & Middleware
- Syrius als bisheriges Kernsystem
- Hohe Frontend- und Prozessflexibilität
Enterprise Transformation · Reference Architecture
Edition 01 · Zielbild & Übergang
Interaktives Architektur-Playbook
Fusion Architecture Almanac
Vom parallelen Versicherungsbetrieb zur gemeinsamen digitalen Plattform
Ein interaktiver Architektur-Almanach zur Zusammenführung von Kundenbeständen, Identitäten, Portalen, Kernsystemen und digitalen Prozessen.
Fusion
Transformation
mit klarer Grenze
mit klarer Grenze
B
Plattform-Welt
Versicherer B
- Integrierter Plattform-Stack
- Keycloak, Portal & Self Services
- Service- und Prozessschicht
- Zukünftiger SaaS-Anbieter
Strategischer Nordstern
A bleibt Versicherer und Kundenmarke. B wird SaaS-Plattformanbieter.
Architektur erkunden01
Context map
Kontext
Zwei Betriebsmodelle werden nicht nur technisch verbunden. Rollen, Verantwortungen und Kundenerlebnis werden neu geordnet.
Azukünftig: Versicherer
Marke, Vertrieb & Experience
- übernimmt alle Kunden und bleibt allein sichtbar
- verantwortet Portal, Kanäle und Kommunikation
- entwickelt Frontend, BFF und Middleware weiter
- kapselt heute Syrius und ermöglicht Innovation
Zentrale Herausforderung
Fachlichkeit nutzen.
Experience bewahren.
Standardisierung
SaaS-Nutzung
Individualisierung
Plattformkontrolle
schnelle Migration
langfristige Entkopplung
Experience bewahren.
Bzukünftig: SaaS
Fachlichkeit, Prozesse & Betrieb
- beendet die eigene Rolle als Versicherer
- stellt den integrierten Plattform-Stack bereit
- betreibt Kernsystem und fachliche Services
- bringt Keycloak, Prozesse und Self Services mit
Die Fachlichkeit und die Prozesse von B sollen genutzt werden, ohne die individuelle Customer Experience und Integrationsfähigkeit von A aufzugeben.
Rollenmodell und Verantwortungsgrenzen müssen vor der technischen Integration verbindlich sein.
Welche fachlichen Services garantiert B als stabile SaaS-Verträge – unabhängig vom eigenen Portal?
Ohne klare Grenze entsteht ein hybrider Gesamtstack mit doppelter Produkt- und Betriebsverantwortung.
02
Baseline architectures
Ausgangsarchitekturen
A optimiert auf Entkopplung und Differenzierung. B optimiert auf Integration und standardisierte Fachprozesse.
Welt A
Experience-getrieben
AkteurKunde
ExperiencePortal A
Channel APIBFF / Middleware A
KompositionOrchestrierung
BestandSyrius & Umsysteme
starke Entkopplungeigenes Datenmodelleigene Prozesslogikhohe InnovationsgeschwindigkeitCX-Kontrolle
Welt B
Plattform-getrieben
AkteurKunde
ExperiencePortal B
CapabilitiesServices & Self Services
FachprozesseProzessschicht
BestandKernsystem B
integrierter Stackabgestimmte KomponentenStandardprozessegeringe BinnenkomplexitätPlattformabhängigkeit
| Kategorie | Welt A | Welt B | Fusionsimplikation |
|---|---|---|---|
| Identity | eigener IdP | Keycloak | Identitäten verbinden, Ziel-IAM definieren |
| Frontend | individuell | Plattformportal | Portal A als einziger Experience Layer |
| Prozesslogik | teilweise orchestriert | integrierte Prozessservices | Fachlogik nach B, Komposition bei A |
| Integration | Middleware-zentriert | plattformintern | stabile Servicegrenze etablieren |
| Datenmodell | kanonisch / individuell | plattformnah | Mapping explizit versionieren |
| Release-Zyklen | kanalorientiert | plattformorientiert | entkoppelte Verträge und Kompatibilität |
| Innovation | hoch im Experience Layer | stark innerhalb des Stacks | Differenzierung oberhalb der Fachservices |
| Abhängigkeit | verteilt | hoch zur Plattform | Exit-, Export- und API-Governance |
Die Fusion kombiniert zwei Optimierungsmodelle; sie sollte keines davon unreflektiert kopieren.
Welche heutige Logik in A ist Differenzierung – und welche nur historisch gewachsene Kernsystemkapselung?
03
Architecture principles
Strategische Leitplanken
Sechs Regeln halten Übergangsentscheidungen auf Kurs und verhindern, dass temporäre Kopplung zum Zielbild wird.
Eine sichtbare Kundenmarke
Alle Kontaktpunkte erscheinen im Branding von A – Portal, Login, Passwort-Reset, MFA, E-Mail, SMS, Dokumente, Self Services, Fehler, Deep Links und Wartungsseiten.
PortalE-MailSMSDeep Links
Portal A bleibt Experience Layer
Der zentrale Einstieg hängt weder von Kundenherkunft noch vom führenden Vertragssystem ab.
Kernsystem B wird Zielsystem
Neue Produkte, neue Verträge und migrierte Bestände werden langfristig vollständig in B geführt.
Middleware A bleibt Entkopplung
Sie entwickelt sich vom Syrius-Wrapper zur strategischen Experience- und Orchestrierungsschicht.
Übergangslogik ist temporär
Dual Routing, Synchronisation und Legacy-Adapter erhalten Owner, Messgrößen und Abschaltkriterien.
Keine Kernsystemlogik im Frontend
Das Frontend kennt Fähigkeiten und kanonische Modelle – niemals System-A/B-Verzweigungen.
Leitplanken werden als Architecture Decision Records operationalisiert und bei jeder Migrationswelle geprüft.
Ausnahmen ohne Ablaufdatum verwässern das Zielbild und erzeugen dauerhafte Doppelarchitektur.
04
Target operating architecture
Zielbild
A kontrolliert das Kundenerlebnis. B liefert eine belastbare SaaS-Fachplattform hinter einer expliziten Servicegrenze.
Verantwortung A
Verantwortung B
Querschnitt
Keycloak / Ziel-IAMAPI GatewayEvent BusObservabilityAuditConsentIdentity MappingDokumenteNotifications
ZugängeKunden & Vertriebskanäle
ExperiencePortal & Apps A
Channel ContractExperience API / BFF
IntegrationMiddleware & Orchestrierung A
- Customer Experience
- kanalübergreifende Komposition
- digitale Innovation
- Kundenkommunikation
SaaS-Serviceplattform BSLA
FachservicesProzessservicesDokumentenservicesPartner & VertragSelf ServicesService Events
System of RecordKernsystem B
- SaaS-Betrieb
- fachliche Wahrheit
- Plattformverfügbarkeit
- API-Stabilität & Releases
01
VertragVersionierte APIs, Events und Fehlersemantik
02
BetriebSLA, Observability und Incident-Handover
03
ExitExportfähigkeit und kontrollierte Entkopplung
Fachliche Wahrheit verbleibt in B; A besitzt Modelle für Kanalbedürfnisse, nicht eine zweite Vertragslogik.
Welche Verfügbarkeits- und Konsistenzgarantien gelten je Service und Prozessklasse?
05
State transition
Übergangsarchitektur
Der Parallelbetrieb ist ein kontrollierter Zustand mit Routing, Identitätsverknüpfung und messbarem Rückbau – kein unscharfes Zwischenbild.
01
Ausgangslage
Vier getrennte Silos
Portale, Kundenbestände, Identitäten und Kernsysteme existieren nebeneinander.
Welt APortal AIdP ASyrius
keine gemeinsame Sicht
Welt BPortal BKeycloakKernsystem B
getrennte Loginsgetrennte Beständegetrennte Journeys
02
Kontrollierter Übergang
Eine Experience, zwei Kernsysteme
Portal A konsolidiert den Zugang; Middleware und Mapping beherrschen die Herkunft.
Kunde
Portal A
BFF A
EntscheidungRouting & Orchestrierung
LegacySyrius
SaaSPlattform B
UmsystemDokumente / CRM
IdentityIAM / Mapping
Portal A als EinstiegMischkunden möglichwellenweise Migrationbeide Kernsysteme aktiv
03
Konsolidierter Zustand
Ein Bestand, eine Identität, eine Experience
Legacy und Übergangsadapter sind entfernt; die SaaS-Grenze ist stabil.
Kunde↓Portal A↓BFF & Middleware A↓SaaS-Plattform B↓Kernsystem B
Portal B ausSyrius ArchivZiel-IAM führendAdapter entfernt
Aktiv messen
Routingquote, Fehlerrate, Mappingqualität und verbleibende Legacy-Nutzung.
Explizit verantworten
Owner, Laufzeit, Datenhoheit und Rückfallverhalten je Übergangskomponente.
Exit beweisen
Abschaltkriterium, letzte Nutzung, Archivzugriff und kontrollierte Entfernung.
Migrationsstatus wird als explizites Fachobjekt behandelt, nicht aus zufälligen Datenmerkmalen abgeleitet.
Unbeobachtete Übergangspfade können unbemerkt zu dauerhaften Produktionsabhängigkeiten werden.
06
Identity is not an account
Identität & Kundenmigration
Eine Person kann mehrere fachliche Rollen, technische Benutzer und Vertragsbeziehungen besitzen. Migration beginnt deshalb mit Semantik, nicht mit Login-Daten.
KlammerGlobale
Kunden-IDstabil · systemneutral
Kunden-IDstabil · systemneutral
System AKunden-ID
System BPartner-ID
IdP ABenutzer-ID
KeycloakBenutzer-ID
VertragNehmer-ID
KontextRollen & Haushalt
Eine Kundenidentität kann gleichzeitig sein:
natürliche PersonPartnerVersicherungsnehmerversicherte PersonPortalbenutzerFirmenkundeBevollmächtigterVermittler
Zehn erste Schritte
- 01
Identitäten analysierenKunden und Benutzer getrennt betrachten
- 02
Globale Kunden-ID definierenstabil, systemneutral, nicht sprechend
- 03
Mapping-Repository einführennachvollziehbar und versioniert
- 04
Dublettenregeln festlegenMatch, Merge, Review und Rollback
- 05
Keycloak-Zielbild definierenRealm-, Client- und Rollenmodell
- 06
Konten verknüpfenmit beweisbarer Zuordnung
- 07
Passwort & MFA klärenMigration, Reset oder Re-Enrolment
- 08
Partner in B anlegenminimale, valide Partnerdaten
- 09
Rechte übertragenVerträge, Rollen und Vollmachten
- 10
Login vereinheitlichenA-Branding über jeden Pfad
Afrüher Schnitt
Sofortige Migration
+ schneller Zielzustand, weniger Föderation
– frühes Risiko, Passwort/MFA, Datenqualität
Bkontrollierte Brücke
Föderierter Übergang
+ schrittweise Umstellung, geringeres Migrationsrisiko
– Token-, Session- und Doppelstruktur-Komplexität
Cnutzungsgetrieben
Just-in-Time
+ aktive Kunden zuerst, verteilte Last
– komplexe Fehlerfälle, langer Altbestand
Ein möglicher Ansatz: Föderation mit Just-in-Time-Verknüpfung kombiniert frühe Risikoreduktion mit einem klaren Migrationspfad. Die konkrete Ausgestaltung hängt von Passwortformaten, MFA-Verfahren, Datenqualität und regulatorischen Vorgaben ab.
Globale Kunden-ID, Mapping-Lebenszyklus und Nachweis der Kontenverknüpfung vor der ersten Bestandswelle festlegen.
Ein erfolgreiches Login beweist weder die fachliche Person noch deren Berechtigung auf einen Vertrag.
07
One front door
Portalstrategie
Portal A wird schrittweise zum einzigen digitalen Einstieg – zuerst für Sicht, dann für Handlung, schließlich für vollständige Prozessabdeckung.
Orientieren
BasisEinheitlicher Einstieg
A-Branding, Login, Kunden- und Vertragsübersicht, Dokumente, Kontakt.
Handeln
AusbauKern-Self-Services
Adresse, Bankdaten, Präferenzen, Schaden, Upload und Status.
Fortsetzen
MigrationKomplexe Prozesse
Vertragsänderung, Produktwechsel, Kündigung, Leistungsantrag, Signatur, Prozessfortsetzung, Postfach und Historie.
Konsolidieren
ZielPortal B ablösen
Keine B-Links, Zugangsdaten oder sichtbaren Medienbrüche mehr.
Capability coverage
Funktionsabdeckung entscheidet über Ablösung
| Funktion | System A | System B | Portal A integriert | Ablösung möglich |
|---|---|---|---|---|
| Vertragsübersicht | ja | ja | konsolidiert | ja |
| Dokumentenzugriff | ja | ja | teilweise | noch nicht |
| Adressänderung | ja | ja | orchestriert | ja |
| Schadenmeldung | ja | ja | in Ausbau | noch nicht |
| Vertragsänderung | begrenzt | ja | offen | nein |
| Postfach & Historie | teilweise | ja | offen | nein |
Die Einträge illustrieren den Steuerungsmechanismus; reale Reifegrade müssen im Programm erhoben werden.
Experience-Regel
Ein Kunde sieht Fähigkeiten – nicht die technische Herkunft seines Vertrags.
Portal B kann erst entfallen, wenn kritische Journeys in A funktional, betrieblich und barrierefrei abgedeckt sind.
Welche B-UIs sind temporär einbettbar, ohne Login-, Branding- oder Accessibility-Brüche zu erzeugen?
08
Separation of concerns
BFF- & Middleware-Strategie
Kanalaggregation, Integrationsorchestrierung und fachliche Wahrheit benötigen eigenständige, bewusst begrenzte Verantwortungen.
Frontend
Darstellung & Interaktion
Navigation, Eingabe, Accessibility, Zustandsdarstellung
ABFF
Kanalspezifische Aggregation
UI-Modelle, Roundtrips, Session-Kontext, Fehlerübersetzung
AMiddleware
Integration & Orchestrierung
Routing, Mapping, Resilienz, Events, Audit und Tracing
ASaaS-Services B
Fachliche Services
Partner, Vertrag, Dokumente, Prozesse und Self Services
BKernsystem B
Führende Bestandslogik
Verträge, Produkte, fachliche Regeln und Transaktionen
Bchannel optimized
Nahe am Nutzungskontext
- Backend-Antworten aggregieren
- kanalspezifische Datenmodelle
- Roundtrips reduzieren
- UI-nahe Validierung
- Feature-Verfügbarkeit
- technische Fehler übersetzen
- Session-Kontext
- konsolidierte Kundensicht
system independent
Nahe an der Integrationsgrenze
- SaaS und Legacy kapseln
- Kunden und Verträge routen
- Prozesse komponieren
- kanonische Modelle & Mapping
- Resilienz und Event-Verarbeitung
- Idempotenz und Retry
- Audit und verteiltes Tracing
- Reconciliation unterstützen
Architecture fitness rule
Der BFF darf nicht zum zweiten Kernsystem werden. Die Middleware darf nicht dauerhaft jede fachliche Funktion duplizieren.
Begriffe im Kontext:
Logik gehört nur dann in den BFF, wenn sie kanalspezifisch ist und keine fachliche Wahrheit erzeugt.
Welche Orchestrierungen sind temporär migrationsbedingt und welche dauerhaft kanalübergreifend?
09
Runtime decisioning
Mischkunden & Routing
Ein Mischkunde bündelt Verträge, Identitäten, Dokumente und Prozesse aus mehreren technischen Welten – die Experience bleibt dennoch konsistent.
Globale Kunden-ID
Kunde 4711
HaftpflichtvertragSystem A
HausratvertragSystem B
DokumenteA + B
LoginIdP A ↔ Keycloak
Stammdatenänderungorchestriert in beide
Routing ist eine nachvollziehbare Entscheidungskette
- 01
Anfrage empfangen
- 02
Kunde identifizieren
- 03
Vertrag bestimmen
- 04
Migrationsstatus prüfen
- 05
führendes System ermitteln
- 06
Servicefähigkeit prüfen
- 07
routen oder orchestrieren
- 08
kanonisch antworten
Local rule engine
lokal · regelbasiert
Routing-Simulator
Parameter wählen und den daraus abgeleiteten Laufzeitpfad prüfen.
OrchestrierungRULE · MIX-LEGACY-01
Vertrag nach System A routen
Der nicht migrierte Vertrag bleibt in Syrius führend; die Kundensicht wird mit Daten aus B konsolidiert.
- Führendes System
- System A / Syrius
- Orchestrierung
- Ja · Kundensicht
- Fallback
- B-Anteil aus Cache, A transaktional
globale Kunden-IDPartner-IDVertrags-IDProdukttypMigrationsstatusführendes SystemProzessfähigkeitFeature-VerfügbarkeitBerechtigungenSystemzustand
Routingregeln werden zentral versioniert, beobachtet und ohne Systemwissen im Frontend angewendet.
Ein technischer Fallback darf bei schreibenden Prozessen keine unklare fachliche Wahrheit erzeugen.
10
Transformation sequence
Integrations-Roadmap
Zugang sichern, Bestände migrieren, Doppelstrukturen nachweisbar entfernen. Abhängigkeiten bestimmen die Reihenfolge – nicht der Kalender allein.
Kurzfristig
Zugang & Parallelbetrieb
Eine gemeinsame Eingangstür und die minimalen Steuerungsfähigkeiten schaffen.
- Portal A als zentraler Einstieg
- A-Branding über Kontaktpunkte
- globale Kunden-ID & Mapping
- Routing-Service & Partneranlage B
- minimale Partnerdaten & Übergangs-APIs
- erste Self Services
- Monitoring & Audit
- Keycloak anbinden
- konsolidierte Vertragsübersicht
Gate 1
Identität und Route sind für jeden Pilotkunden erklärbar.
Mittelfristig
Migration & Funktionsausbau
Bestände in Wellen bewegen und Portal A zur vollständigen Handlungsschicht ausbauen.
- Kunden- & Vertragsmigration in Wellen
- Mischkunden beherrschen
- Datenhoheit je Objekt
- Portal A funktional ausbauen
- Dokumente & Kommunikation
- Neugeschäft ausschließlich in B
- Reconciliation & Dubletten
- Migrationsstatus als Fachobjekt
- Prozessmigration & Self-Service-Abdeckung
- Support- & Diagnosewerkzeuge
Gate 2
Jede Welle ist reconciled, supportbar und rückbaubar.
Langfristig
Konsolidierung & Abschaltung
Aktive Bestände und Prozesse konsolidieren, temporäre Komponenten vollständig entfernen.
- vollständiger Bestand in B
- Portal B abschalten
- Syrius archivieren / abschalten
- IdP A abschalten
- Routing & Sync entfernen
- SaaS-SLA und API Governance
- Archiv & Datenlöschung
- Exit- und Exportfähigkeit
Gate 3
Keine aktive Journey benötigt eine Legacy-Komponente.
Identity Mapping→Partneranlage→Vertragsmigration→Servicefähigkeit→Portalablösung→Altsystem aus
Wellen werden nach Capability, Datenqualität und Betriebsreife geschnitten – nicht nur nach Produktbestand.
Welche Exit-Kriterien sind technisch messbar und wer bestätigt sie fachlich?
11
Differentiation layer
Innovation & Customer Experience
Das Kernsystem liefert belastbare Fachlichkeit. Der Experience Layer komponiert daraus verständliche, kanalübergreifende Kundenerlebnisse.
konsolidierte Vertragsübersicht
personalisierte Next-Best-Actions
kanalübergreifende Fortsetzung
proaktive Schadenkommunikation
kontextabhängige Self Services
dynamische Produktvorschläge
digitale Vertragsoptimierung
intelligente Dokumentenerkennung
assistierte Dateneingabe
transparente Prozessstatus
barrierearme Gerätenutzung
Web, App & Servicecenter
BFFstabile Experience APIsMiddleware
Fachliche WahrheitSaaS-Services & Kernsystem Bverlässlich · transaktional · auditierbar
Kernsystemliefert Fachlichkeit
Experience Layererzeugt Differenzierung
gemeinsames Ergebnisschnelle, konsistente Journeys
Innovation nicht vollständig an Kernsystem-Releases koppeln.
BFF und Middleware stellen stabile Abstraktionen bereit.
Fachliche Wahrheit verbleibt im Kernsystem.
Kundenzentrierte Komposition entsteht in der Experience-Schicht.
Innovationsideen werden gegen API-Fähigkeit, Datenverfügbarkeit und fachliche Ownership geprüft.
Eine Experience-Schicht ohne fachliche Grenzen erzeugt attraktive, aber inkonsistente Schattenprozesse.
12
Failure modes
Risiken & Anti-Patterns
Die gefährlichsten Lösungen funktionieren kurzfristig. Ihre Kosten werden erst sichtbar, wenn Rückbau, Betrieb und Datenwahrheit geprüft werden.
Systemverzweigungen wandern in jede Journey. Rückbau und Testkombinatorik werden unkontrollierbar.
hohe Kopplungschwerer RückbauUI-Komplexität
Konkurrierende Schreibpfade erzeugen widersprüchliche Stände und schwer erklärbare Konfliktlösungen.
Datenkonflikteunklare Wahrheithoher Betrieb
Konten und fachliche Personen werden falsch gleichgesetzt; Dubletten und Berechtigungsfehler folgen.
DublettenFehlzuordnungAccess Risk
Die sichtbare Farbe ändert sich, Kontrolle über Journeys, Releases und Integration verbleibt jedoch bei B.
fragmentierte JourneyAbhängigkeitMedienbrüche
Fachregeln werden dupliziert und weichen mit jedem Release weiter vom führenden System ab.
doppelte LogikInkonsistenzWartung
Adapter und Jobs werden zu unbefristeten Produktionskomponenten ohne klare Produktverantwortung.
technische SchuldBetriebskostenunklare Owner
Fehlerursachen, Datenprobleme und Betriebsrisiken treffen gleichzeitig aufeinander. Rückfallfähigkeit und Isolation sinken drastisch.
hohes Betriebsrisikogeringe Rückfallfähigkeitschwierige Isolation
Warnsignal
Wenn eine Übergangslösung keinen Owner, keine Telemetrie und kein Abschaltdatum besitzt, ist sie bereits Teil des Zielbilds geworden.
Automatisiert messen, ob Frontend-Systemwissen, Synchronisationspfade und Legacy-Nutzung tatsächlich abnehmen.
Welche heutige „temporäre“ Komponente besitzt noch kein finanziertes Rückbau-Epic?
13
Decision inventory
Entscheidungslandkarte
Zentrale Entscheidungen werden als zusammenhängendes Portfolio geführt – mit Status, Konsequenz und nachvollziehbarem Owner.
entschieden in Klärung offen kritisch
- in KlärungKeycloak als alleiniger Ziel-IdP?
- offenFöderation, Migration oder Kombination?
- kritischPasswortübernahme oder Reset; MFA-Migration?
- entschiedenGlobale Kunden-ID als Klammer
- in KlärungMaster je Kundendatenattribut und Fachobjekt
- offenSynchronisieren, migrieren oder archivieren?
- kritischDubletten-, Merge- und Rollback-Regeln
- offenReconciliation und Nachweisführung
- entschiedenPortal A ist langfristig einziger Einstieg
- in KlärungB-Funktionen über APIs integrieren
- offenTemporär zulässige eingebettete B-UIs
- kritischMessbare Abschaltkriterien für Portal B
- offenSynchron, eventbasiert oder pro Capability?
- in KlärungKanonisches Datenmodell und Ownership
- offenAPI Gateway, Versionierung und Deprecation
- kritischFehler-, Retry- und Idempotenzmodell
- in KlärungGemeinsame Observability und Trace-Kontext
- offenSaaS-SLAs und Incident-Verantwortung
- offenRelease-Koordination und Kompatibilitätsfenster
- kritischExit-, Export- und Notbetriebsfähigkeit
ADR
Kontext & KonsequenzWarum wurde entschieden und welche Alternativen entfielen?
KPI
WirksamkeitWelche Messgröße zeigt, dass die Entscheidung trägt?
REV
Review-DatumWann muss eine Übergangsentscheidung neu bewertet werden?
Glossar:
Status ist kein Reporting-Schmuck: Kritische offene Entscheidungen blockieren abhängige Migrations-Gates.
Owner, Entscheidungstermin und Review-Zyklus für jede Domain verbindlich ergänzen.
14
End state
Zielzustand & Abschaltung
Das Programm endet nicht mit dem letzten Datensatz, sondern mit eindeutiger fachlicher und betrieblicher Verankerung im Zielmodell.
01AkteurKunde
02ExperiencePortal A
03ChannelBFF A
04IntegrationMiddleware A
05ServicesSaaS-Plattform B
06RecordKernsystem B
Ziel-IAM / KeycloakObservability & AuditAPI-VerträgeArchivzugriff
Nicht mehr vorhanden
- Portal B und Kundenlogin über B
- Syrius für aktive Bestände
- Identity Provider A
- Dual Routing und Synchronisationsjobs
- Legacy- und Übergangsadapter
Dauerhaft vorhanden
- Experience Layer, BFF und Middleware A
- SaaS-Plattform und Kernsystem B
- Keycloak oder Ziel-IAM
- zentrale Observability und Archivzugriff
- klar definierte, versionierte API-Verträge
Abschaltung ist eine belegte Fähigkeit
aktiven Journeyslaufen ohne Legacy-Abhängigkeit
unbekannten Identitätenin produktiven Zuordnungen
führendes Systemje Fachobjekt und Lebenszyklus
Betriebsübergabefür SLA, Incident, Archiv und Exit
Die Werte sind Zielkriterien, keine Aussage über einen heutigen Projektstand.
AbschlussbotschaftDie Migration ist abgeschlossen, wenn nicht nur Daten übertragen wurden, sondern Kunden, Verträge, Identitäten, Prozesse und Betriebsverantwortung eindeutig im Zielmodell verankert sind.