Architektur-Zielbild
Decompositionsgrenzen, Service-Interaktionen und Zuverlässigkeitsmuster festlegen.
Refactor
Zuletzt aktualisiert am
Überblick: Refactor
Abschnitt betitelt „Überblick: Refactor“Refactor gestaltet Teile der Anwendung und des Delivery-Modells cloud-native neu. Es ist der veränderungsintensivste Pfad und sollte gezielt für strategische Workloads genutzt werden.
Wann Refactor sinnvoll ist
Abschnitt betitelt „Wann Refactor sinnvoll ist“- Strategische Differenzierung benötigt schnellere Produkt- und Feature-Lieferung.
- Aktuelle Architektur begrenzt Stabilität oder Skalierung über tolerierbares Risiko hinaus.
- Technische Altlasten blockieren Innovation und verursachen wiederkehrende Betriebsprobleme.
- Langfristiger Nutzen übersteigt den zusätzlichen Aufwand in Umsetzung und Governance.
Design-Aspekte im STACKIT-Kontext
Abschnitt betitelt „Design-Aspekte im STACKIT-Kontext“Engineering- und Delivery-Modell
CI/CD, Teststrategie und Release-Governance auf die neu Architektur ausrichten.
Daten- und Integrations-Refactoring
Schema-Übergänge, Schnittstellen-Versionierung und Koexistenzstrategie planen.
Betriebsmodell
Observability, SRE-Verantwortung und Incident-Reaktion für das neu Runtime-Modell definieren.
Empfohlener Design-Ablauf
Abschnitt betitelt „Empfohlener Design-Ablauf“- Technische Altlasten und fachliche Randbedingungen baseline.
- Zielarchitektur-Schnitte und Migrationsinkremente definieren.
- Übergangszustände und Kompatibilitätsverträge entwerfen.
- Anforderungen an Stabilität, Security und Performance validieren.
- Phasen-Roadmap mit Business-Checkpoints freigeben.
Erforderliche Ergebnisse
Abschnitt betitelt „Erforderliche Ergebnisse“Gemeinsame Ergebnisse für alle Migrationspfade
Abschnitt betitelt „Gemeinsame Ergebnisse für alle Migrationspfade“- Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
- Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
- Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
- Übergabepaket für Migration Factory Setup und Wellenplanung.
Refactor-spezifische Ergebnisse
Abschnitt betitelt „Refactor-spezifische Ergebnisse“- Refactor-Entscheidungsnachweis und Nutzenhypothese.
- Zielarchitektur mit Übergangszuständen.
- Delivery-Roadmap und Engineering-Kontrollen.
- Daten- und Integrations-Transitionsdesign.
- Runbook- und Betriebsbereitschaftspaket.
Diagramm-Schrittreferenz
Abschnitt betitelt „Diagramm-Schrittreferenz“Redesign application/infrastructure architecture
Abschnitt betitelt „Redesign application/infrastructure architecture“Neues Architektur-Baseline-Modell und Grenzen für den Übergang festlegen. Domänenschnitte, Ziel-Runtime und Zwischenzustände für die Koexistenz beschreiben, damit Refactor- Pakete für die Umsetzung ohne Brüche in abhängigen Systemen umgesetzt werden können.
App code development
Abschnitt betitelt „App code development“Umfang der Implementierung und Change-Pakete für das neue Zielbild festlegen. Grenzen der Pakete für die Umsetzung, Test-Strategie und Release-Kriterien je Slice definieren, damit Codeänderungen in den Wellenplan integrierbar und sicher bereitstellbar bleiben.
Full ALM/SDLC
Abschnitt betitelt „Full ALM/SDLC“Delivery-Pipeline, Qualitäts-Gates und Release-Governance-Modell festlegen. Branching, Automatisierung und Freigabe-Gates an Security- und Compliance-Evidenzen ausrichten, bevor produktive Cutovers freigegeben werden.
Integration
Abschnitt betitelt „Integration“Übergang der Integrationen, Behandlung der Kompatibilität und finale Handover-Controls definieren. API-Vertragsversionierung, Rollback-Verhalten und teamübergreifende Cutover-Kommunikation festlegen, um Regressionen bei Integrationen zu minimieren.