Discovery

Was Discovery ist

Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.

Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.

Zentrale Ziele

Vollständige Basis

Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.

Transparente Abhängigkeiten

Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.

Business-Abgleich

Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.

Planungsreife

Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.

Was Discovery typischerweise erfasst

Inventarisierung

Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.

Abhängigkeitsanalyse

Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.

Ressourcennutzung

Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.

Betriebskontext

Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.

Input der Application Owner

Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.

Typisches Vorgehen

In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.

Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.

Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.

Discovery-Prozess auf einen Blick

Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.

Typische Analyse-Muster im Discovery-Tooling

Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:

• Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
• Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
• Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
• Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
• Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
• Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
• Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.

Diese Analysen bilden die faktische Grundlage für Architektur- und Entscheidungen in der Mobilisierung.

Methodik in der Praxis

1. Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
2. Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
3. Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
4. Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
5. Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
6. Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.

Warum Discovery kritisch ist

• Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
• Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
• Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
• Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
• Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.

Relevanz für nachgelagerte Module

Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:

Design

Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.

Security und Compliance

Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.

Landing Zone

Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.

Migrationsplan

Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.

Operating Model und Business Case

Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.

Ergebnisse aus Discovery

Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:

• Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
• Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
• Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
• Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
• Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.

Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.