Zielbild je Anwendung
Definiert Zielarchitektur, Service-Auswahl, Integrationsansatz und Randbedingungen im STACKIT Kontext.
Spring Boot auf SKE mit PostgreSQL Flex und Gateway API
STACKIT
Design
Design überführt Discovery-Ergebnisse in umsetzbare Zielarchitekturen und Runbooks je Anwendung für die spätere Factory-Umsetzung.
Ergebnis
Abschnitt betitelt „Ergebnis“Das Modul Design erstellt für jede in Discovery erfasste Anwendung ein ausführbares Design für die Migration. Es geht nicht um ein abstraktes Papier, sondern um ein konkretes Paket, das eine Migration Factory stabil umsetzen kann.
R-Strategie-Entscheidungsnachweis
Dokumentiert die gewählte Migrationsstrategie und begründet, warum Alternativen verworfen wurden.
Factory-fähiges Migrations-Runbook
Liefert eine Schritt-für-Schritt-Anleitung mit Rückfallpfad und Validierungspunkten.
Handover-Paket
Übergibt alle benötigten Ergebnisse an Migration Factory Setup, Landing Zone und Migrationsplan.
Abgrenzung
Abschnitt betitelt „Abgrenzung“Die Module sind stark verzahnt, haben aber unterschiedliche Aufgaben:
Design (dieses Modul)
Entscheidet pro Anwendung Zielbild und Migrationsstrategie und erstellt ausführbare Runbooks.
Migration Factory Setup
Ermöglicht die Umsetzung durch Auswahl und Vorbereitung des passenden Factory-Modells, Partners und Werkzeugkastens.
Landing Zone
Liefert die Plattform-Grundlage und Governance Controls, die im Zielbild berücksichtigt werden müssen.
Migrationsplan
Überführt fertige Designs in realistische Wellen, Reihenfolgen, Abhängigkeiten und Meilensteine.
Methode
Abschnitt betitelt „Methode“Die R-Strategie-Methodik ist das zentrale Modell in diesem Modul. Für jede Anwendung muss die gewählte Strategie mit Architektur-, Business-, Risiko- und Argumenten für den Betrieb belegt werden.
Entscheidungskriterien je R-Strategie
Abschnitt betitelt „Entscheidungskriterien je R-Strategie“- Relocate: Sinnvoll, wenn eine schnelle Überführung von Virtualisierungs-Stacks möglich ist; je nach Wellenumfang tool-gestützt oder kontrolliert manuell ausführen.
- Rehost: Sinnvoll bei geringer Veränderungstoleranz und engem Zeitrahmen, wenn Geschwindigkeit vor sofortiger Modernisierung steht.
- Replatform: Sinnvoll, wenn begrenzte Anpassungen über die STACKIT Plattform klare Vorteile in Betrieb, Skalierung oder Kosten bringen.
- Repurchase: Sinnvoll für passende Angebote im STACKIT Ökosystem, in dieser Phase gezielt für Workspace by STACKIT, ServiceNow, RISE with SAP on STACKIT und STACKIT Domain Solutions.
- Refactor: Sinnvoll für strategische Anwendungen, wenn eine cloud-native Überarbeitung klaren Mehrwert in Agilität, Resilienz oder Kosten schafft.
- Retain: Retain bei zeitlichen, technischen oder Governance-Hürden in der aktuellen Welle.
- Retire: Retire bei fehlendem Geschäftswert im Verhältnis zum Betriebsaufwand.
Zentrale Schritte im Diagramm
Abschnitt betitelt „Zentrale Schritte im Diagramm“Das Diagramm ist nicht nur eine Visualisierung. Es ist der Referenzablauf für die Übergabe zwischen Modulen und für die zentralen Design-Governance-Checkpoints.
1. Discovery Input
Abschnitt betitelt „1. Discovery Input“Ausgangslage und Randbedingungen absichern: fachlicher Kontext, Workload-Inventar, Abhängigkeiten und Restriktionen für die folgenden Design-Entscheidungen.
2. Bewerten und priorisieren
Abschnitt betitelt „2. Bewerten und priorisieren“Kandidaten für das Design nach Kritikalität, Risiko, Aufwand und Eignung für Wellen priorisieren. Dieser Schritt steuert, wo Design-Kapazität zuerst eingesetzt wird.
3. Determine migration path
Abschnitt betitelt „3. Determine migration path“Die passende R-Strategie je Anwendung festlegen und in den jeweiligen Design-Pfad verzweigen (Relocate, Rehost, Replatform, Repurchase, Refactor, Retain oder Retire).
4. Validation
Abschnitt betitelt „4. Validation“Alle Design-Pfade in einem gemeinsamen Qualitäts-Gate betrachten. Annahmen zur Architektur, Security/Compliance, Runbook-Qualität und Betriebsreife validieren.
5. Transition
Abschnitt betitelt „5. Transition“Die kontrollierte Übergabe in den Migrationslauf vorbereiten: Release-Reife, Wellen-Fit, Koordinationsfenster und klare Übergabe der Verantwortung.
6. Production
Abschnitt betitelt „6. Production“Kriterien für den Produktiv-Handover und die Day-1-Betriebsbasis nach erfolgreicher Transition finalisieren. Damit ist der im Diagramm dargestellte Design-Prozess abgeschlossen.
Zielbild
Abschnitt betitelt „Zielbild“- Scope und Baseline aus Discovery bestätigen (Abhängigkeiten, Nutzung, Kritikalität, Restriktionen).
- Fachliche und technische Designziele festlegen, inklusive Verfügbarkeit, Security, Compliance und Performance.
- R-Strategie-Optionen gegen klare Kriterien bewerten und die gewählte Strategie begründet dokumentieren.
- Zielbild auf STACKIT Produkte und Plattform-Fähigkeiten abbilden, inklusive Netzwerk, Identität, Daten und Betrieb.
- Migrationsvorgehen spezifizieren (Cutover-Ansatz, Datenumzug, Integrationswechsel, Rückfallstrategie).
- Ausführbares Runbook für die Factory mit Aufgaben, Qualitätschecks und Abnahmekriterien erstellen.
- Design-Annahmen mit Architektur, Security, Plattform und Business-Ownern validieren.
- Freigegebenes Designpaket an Migration Factory Setup und Migrationsplan übergeben.
Mindestens folgende Inhalte sollten je Anwendung vorliegen:
- Zielarchitektur-Definition: Workload-Platzierung, Service-Mapping, Modell für Integrationen und nicht-funktionale Anforderungen.
- R-Strategie-Entscheidungsnachweis: Gewählte Strategie, Kriterien, geprüfte Alternativen und Haupt-Risiken.
- Migrations-Runbook: Reihenfolge der Ausführung, Checks vor dem Lauf, Rückfallpfad, Validierung und Go-live-Kriterien.
- Abhängigkeiten und Schnittstellen: Bedarf für Koordination mit vor- und nachgelagerten Systemen und Übergangsfenstern.
- Compliance- und Security-Controls: Verpflichtende Controls und Nachweise für Release-Reife.
Nutzen Sie die dedizierte Pattern-Seite, um vor Auswahl des Migrations-Runbooks ein klares Zielbild zu definieren.
Workload-Use-Case-Sicht für Migrationsvarianten
Abschnitt betitelt „Workload-Use-Case-Sicht für Migrationsvarianten“Nutzen Sie ergänzend zur R-Strategie die Workload-Sicht, um zu klassifizieren, was migriert wird, und um machbare Umsetzungsvarianten mit expliziten Rahmenbedingungen auszuwählen.
KI-gestützte Design-Assets
Abschnitt betitelt „KI-gestützte Design-Assets“KI-gestützte Design-Assets unterstützen Architekten dabei, Anwendungsanforderungen, Services aus der Ausgangslage und R-Strategie-Optionen in prüfbare Zielbildvorschläge zu überführen. Die Ergebnisse dienen als Input für Architektur-, Security-, Plattform- und Business-Validierung, bevor ein Migrationspfad freigegeben wird.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Runbook-Assets
Abschnitt betitelt „Runbook-Assets“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Wirkung
Abschnitt betitelt „Wirkung“Die Qualität der Migrationsplanung hängt direkt von der Design-Qualität ab. Reihenfolge der Wellen, Factory-Durchsatz und Liefer-Risiko werden durch die Präzision der Zielentwürfe und Ablaufpläne bestimmt. Unvollständige Designs führen in der Praxis zu instabilen Wellen und Verzögerungen.