Priorisierungs- und Migrationsstrategie

Ein zentrales Element der Migrationsplanung ist die Festlegung von Priorisierungskriterien. Bei dieser Übung geht es darum, die Reihenfolge zu verstehen, in der Anwendungen migriert werden. Die Strategie besteht darin, das Priorisierungsmodell iterativ und progressiv weiterzuentwickeln.

Priorisierung von Anwendungen

In dieser Bewertungsphase liegt der Schwerpunkt auf der Festlegung erster Kriterien für die Priorisierung von Workloads mit geringem Risiko und geringer Komplexität. Diese Workloads eignen sich gut für Pilotanwendungen. Die Verwendung von Workloads mit geringem Risiko und geringer Komplexität bei ersten Migrationen reduziert das Risiko und gibt Teams die Möglichkeit, Erfahrungen zu sammeln. Diese Kriterien werden in weiteren Bewertungsphasen weiterentwickelt, um die Priorisierung bei der Erstellung des Migrationswellenplans an den Geschäftsfaktoren auszurichten.

Bei den ersten Kriterien sollten Anwendungen mit einer geringen Anzahl von Abhängigkeiten, die in einer Cloud-gestützten Infrastruktur und in Umgebungen außerhalb der Produktionsumgebung ausgeführt werden, Priorität eingeräumt werden. Ein Beispiel wären Anwendungen mit 0-3 Abhängigkeiten, die bereit sind, unverändert in einer Entwicklungs- oder Testumgebung neu zu hosten. Diese Kriterien gelten für die Definition der Pilotanwendungen und möglicherweise der ersten und zweiten Migrationswelle, je nach Reifegrad und Vertrauensgrad der Cloud-Einführung.

Entscheidung, welche Ausgangskriterien verwendet werden sollen

Wählen Sie 2—10 Datenpunkte aus, die Sie für die Priorisierung Ihrer ersten Workloads verwenden möchten. Diese Datenpunkte stammen aus Ihrem anfänglichen Anwendungs- und Infrastrukturbestand (weitere Informationen finden Sie im Abschnitt Datenerfassung).

Definieren Sie als Nächstes eine Punktzahl oder Gewichtung für jeden möglichen Wert jedes Datenpunkts. Wenn beispielsweise das Umgebungsattribut ausgewählt ist und die möglichen Werte Produktion, Entwicklung und Test lauten, wird jedem Wert eine Bewertung zugewiesen, wobei eine größere Zahl für eine höhere Priorität steht. Obwohl dies optional ist, empfehlen wir, jedem Datenpunkt einen Multiplikationsfaktor für Wichtigkeit oder Relevanz zuzuweisen. Dieser optionale Schritt bietet ein übergeordnetes Unterscheidungsmerkmal, das hervorhebt, was wichtiger ist. Auf diese Weise können Sie die Kriterien bei der Zuordnung von Punktzahlen zu den Werten aufeinander abstimmen.

Basierend auf der Strategie, einfache Anwendungen mit geringem Risiko für die ersten Migrationswellen zu priorisieren, zeigt die folgende Tabelle Beispiele für die Auswahl von Attributen und deren Wertzuweisungen.

Attribut (Datenpunkt)	Mögliche Werte	Ergebnis (0-99)	Multiplikationsfaktor für Wichtigkeit oder Relevanz
Umgebung	Test	60	Hoch (1x)
	Entwicklung	40
	Produktion	20
Geschäftliche Kritikalität	Niedrig	60	Hoch (1x)
	Mittelschwer	40
	Hoch	20
Regulatorischer Rahmen oder Compliance-Rahmen	None	60	Hoch (1x)
	FedRAMP	10
Unterstützung von Betriebssystemen	Bereit für die Cloud	60	Mittelhoch (0,8x)
	In der Cloud nicht unterstützt	10
Anzahl der Recheninstanzen	1-3	60	Mittelhoch (0,8x)
	4-10	40
	11 oder mehr	20
Migrationsstrategie	Erneut hosten	70	Mittel (0,6x)
	Plattformwechsel	30
	Refaktorieren oder neu strukturieren	10

Achten Sie darauf, dass Sie Attribute auswählen, die als wichtige Unterscheidungsmerkmale zwischen Anwendungen dienen können. Andernfalls führen die Kriterien dazu, dass viele Workloads dieselbe Priorität haben. Nachdem Sie das Modell angewendet haben, empfehlen wir Ihnen, sich die oberen und unteren Rankings anzusehen, um zu sehen, ob Sie damit einverstanden sind. Wenn Sie nicht generell damit einverstanden sind, können Sie die Kriterien, die Sie zur Bewertung der Workloads verwendet haben, erneut überprüfen.

Nachdem Sie ein Ranking erstellt haben, schauen Sie sich die Verteilung der Punktzahlen über das gesamte Portfolio an. Die Punktzahlen selbst spielen keine Rolle. Es ist der Unterschied zwischen den Ergebnissen, der wichtig ist. Sie könnten beispielsweise feststellen, dass die höchste Gesamtpunktzahl 8.000 und die unterste Punktzahl 800 beträgt. Erwägen Sie, die resultierenden Punktzahlen als Histogramm darzustellen, damit Sie überprüfen können, ob Sie eine gute Verteilung haben. Die ideale Verteilung sieht aus wie eine normale Glockenkurve mit einigen Workloads mit sehr hoher Priorität und einigen Workloads mit sehr niedriger Priorität. Die meisten Anwendungen werden sich irgendwo in der Mitte befinden.

Ein weiterer wichtiger Aspekt der anfänglichen Priorisierung ist die Einbeziehung interner Teams oder Geschäftsbereiche, die Interesse daran zeigen, die Cloud als Early Adopters zu nutzen. Dies könnte ein erheblicher Hebel sein, um Unterstützung von Unternehmen für die Migration einer bestimmten Anwendung zu erhalten, insbesondere in der Anfangszeit. Wenn dies in Ihrer Organisation der Fall ist, fügen Sie das Geschäftsbereichsattribut in die obige Tabelle ein. Weisen Sie den Geschäftsbereichen, die bereit sind, ihre Bewerbungen einzureichen, eine hohe Punktzahl zu. Die Verwendung des Geschäftsbereichsattributs hilft dabei, diese Anwendungen ganz oben auf der Liste zu platzieren.

Wenn Sie mit der daraus resultierenden Rangfolge einverstanden sind, wählen Sie die fünf bis zehn besten Bewerbungen aus. Dies werden Ihre ersten Kandidaten für die Migration Ihrer Bewerbung sein. Verfeinern Sie die Liste so, dass Sie 3-5 Bewerbungen bestätigen. Dies hilft Ihnen, bei der Durchführung einer detaillierten Bewerbungsbeurteilung zielgerichtet vorzugehen. Weitere Informationen finden Sie unter Bewertung priorisierter Anwendungen.

Bestimmung des R-Typs für die Migration

Die Entscheidung über eine Migrationsstrategie für jede Anwendung und die zugehörige Infrastruktur wird Auswirkungen auf die Geschwindigkeit, die Kosten und die Höhe der Vorteile der Migration haben. Es ist wichtig, die Strategie auf der Grundlage einer ausgewogenen Kombination von Faktoren festzulegen, darunter Geschäftsfaktoren, technische Leitprinzipien, Priorisierungskriterien und Geschäftsstrategie.

Manchmal führen diese Faktoren zu widersprüchlichen Ansichten. Zum Beispiel könnten Innovation und Agilität der Haupttreiber für die Migration sein. Gleichzeitig müssen Sie möglicherweise schnell die Kosten senken. Durch die Modernisierung aller betroffenen Anwendungen werden die Kosten auf lange Sicht gesenkt, allerdings sind dafür größere Investitionen im Vorfeld erforderlich. In diesem Fall besteht ein Ansatz darin, Anwendungen mithilfe von Strategien zu migrieren, die weniger Aufwand erfordern, wie z. B. Rehost oder Replatform. Dies kann zu schnellen Effizienzsteigerungen und kurzfristigen Kostensenkungen führen. Investieren Sie die Einsparungen dann wieder in die Modernisierung der Anwendung zu einem späteren Zeitpunkt, um eine weitere Kostensenkung zu erreichen.

Wenn jedoch mit einem vollständigen Rehost aller Anwendungen begonnen wird, verzögert sich der Nutzen der Modernisierung. Der Schlüssel liegt darin, ein Gleichgewicht zwischen den Migrationsstrategien zu finden, sodass geschäftsstrategische Anwendungen bei der Modernisierung priorisiert werden, während andere Anwendungen zuerst neu gehostet oder auf eine neue Plattform umgestellt und dann modernisiert werden können.

Wie legen Sie eine Migrationsstrategie für Ihre Anwendungen fest?

In dieser Phase der Bewertung liegt der Schwerpunkt darauf, ein erstes Modell für die Auswahl der Migrationsstrategie zu integrieren. Um die Migrationsstrategie für die ersten Anwendungen zu validieren, verwenden Sie das Modell in Verbindung mit den Geschäftsfaktoren und den Priorisierungskriterien. Die Standardlogik des Entscheidungsbaums hilft Ihnen dabei, die anfängliche Behandlung für den Anwendungsbereich zu bestimmen. In der Baumstruktur sind die komplexesten Ansätze, wie Refactor oder Re-Architect, Ihren strategischen Workloads vorbehalten.

Eine anpassbare draw.io-Version dieses Diagramms ist im Abschnitt Anlagen verfügbar.

Der erste Schritt zu einem ersten Modell besteht darin, die Geschäftstreiber oben in der Baumstruktur mit den von Ihrer Organisation definierten Faktoren zu aktualisieren. Als Nächstes wenden Sie den Baum auf Anwendungskomponenten und nicht auf Anwendungen als Ganzes an. Im Fall einer dreistufigen Anwendung mit drei Komponenten (Frontend, Anwendungsebene und Datenbank) sollte jede Komponente den Baum unabhängig voneinander übertragen und ihr sollte eine bestimmte Strategie und ein bestimmtes Muster zugewiesen werden. Dies liegt daran, dass Sie in einigen Fällen möglicherweise eine bestimmte Ebene neu hosten oder auf eine andere Plattform umstellen und andere Ebenen umgestalten (neu strukturieren) möchten.

Die unabhängige Zuweisung von Komponenten führt Sie dazu, eine Migrationsstrategie für die zugehörige Infrastruktur zu definieren. Die Infrastrukturstrategie kann dieselbe Strategie sein wie die Anwendungskomponente, die sie unterstützt, oder sie kann sich unterscheiden. Beispielsweise folgt eine Anwendungskomponente, die auf eine neue virtuelle Maschine mit einem neueren Betriebssystem umgestellt wird, der Umplattformstrategie, während die aktuelle virtuelle Maschine, auf der sie gehostet wird, außer Betrieb genommen wird. Die Migrationsstrategie für die Infrastruktur wird auf der Grundlage der für die Anwendungskomponenten ausgewählten Strategie berechnet.

Bevor Sie den Entscheidungsbaum zur Festlegung von Migrationsstrategien verwenden, testen Sie die Logik mit einigen Anwendungen und prüfen Sie, ob Sie mit dem Ergebnis generell einverstanden sind. Der Entscheidungsbaum mit 6 Rs ist ein Leitfaden, der nicht die Analyse ersetzt, die zur Feststellung seiner Richtigkeit erforderlich ist. Die Baumlogik gilt möglicherweise nicht für bestimmte Fälle. Behandeln Sie diese Fälle als Ausnahmen und fahren Sie fort, die durch den Baum getroffene Entscheidung außer Kraft zu setzen, indem Sie die Gründe für die Überschreibung dokumentieren, anstatt die Baumlogik zu ändern. Dadurch werden mehrere Versionen der Entscheidungsstruktur vermieden, deren Verwaltung schwierig werden könnte. Allgemein gilt, dass der Baum für mindestens 70 bis 80 Prozent der Workloads gültig sein sollte. Für den Rest wird es Ausnahmen geben. Jegliche Anpassungen der Baumlogik in dieser Phase der Bewertung sollten sich auf die Erstellung eines ersten Modells konzentrieren. Weitere Iterationen und Verfeinerungen werden in späteren Phasen erfolgen, z. B. bei der Portfolioanalyse und der Migrationsplanung.

Anlagen

attachment.zip