Vollständige Basis
Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.
CloudMent AI-Powered Cloud Advisor
CloudMent
Discovery
Discovery überführt frühe Mengenbaselines in eine entscheidungsreife Sicht auf Anwendungen, Abhängigkeiten und organisatorische Bereitschaft.
Überblick: Discovery
Abschnitt betitelt „Überblick: Discovery“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
Abschnitt betitelt „Zentrale Ziele“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
Abschnitt betitelt „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
Abschnitt betitelt „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.
Zwei Evidence-Streams: technisch vs. human-driven
Abschnitt betitelt „Zwei Evidence-Streams: technisch vs. human-driven“Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:
- Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.
Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.
Discovery-Prozess auf einen Blick
Abschnitt betitelt „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
Abschnitt betitelt „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 technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“- Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
- Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
- Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
- Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
- Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
- Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.
Warum Discovery kritisch ist
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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.