Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Portfolioanalyse und Migrationsplanung Diese Bewertungsphase konzentriert sich auf den Abschluss der im Abschnitt Portfolioermittlung und Erstplanung begonnenen Untersuchung und Analyse auf [Portfolioebene](portfolio-discovery-initial-planning.md). Ziel ist es, das anfängliche Anwendungs- und Infrastrukturportfolio zu iterieren und eine Grundlage zu schaffen. Diese Grundlage umfasst die Identifizierung aller Abhängigkeiten, die Iteration von Rationalisierungsmodellen für die Migration, die Erstellung eines detaillierten Geschäftsszenarios und die Ausarbeitung eines Migrationsplans. Infolgedessen ist die erforderliche Datentreue höher. Diese Phase erfordert Zeitinvestitionen. Um die Bewertungsergebnisse zu beschleunigen, empfehlen wir, so viele programmatische Datenquellen wie z. B. Discovery-Tools wie möglich zu verwenden. Zu den wichtigsten Ergebnissen dieser Phase gehören: + Ein originalgetreues Anwendungs- und Infrastrukturinventar + Eine umfassende Migrationsstrategie für jede Anwendung + Ein äußerst zuverlässiger Plan für die Migrationswelle + Ein detaillierter Geschäftsszenario # Verständnis der vollständigen Anforderungen an die Bewertungsdaten In der folgenden Tabelle werden die Informationen beschrieben, die erforderlich sind, um einen vollständigen Überblick über das Portfolio der migrierten Anwendungen und der zugehörigen Infrastruktur zu erhalten. In den Tabellen werden die folgenden Abkürzungen verwendet: + R, für erforderlich + O, für optional + N/A, für nicht zutreffend **Anwendungen** | **Attributname** | **Beschreibung** | **Inventar und Priorisierung** | **Detaillierter Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** | | --- | --- | --- | --- | --- | | Eindeutige Kennung | Zum Beispiel Anwendungs-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventaren und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung einzigartiger IDs Produkte, wann immer diese in Ihrer Organisation nicht definiert sind. | R | R | Hoch | | Anwendungsname | Name, unter dem diese Anwendung Ihrer Organisation bekannt ist. Geben Sie gegebenenfalls den Handelsnamen off-the-shelf (COTS) und den Produktnamen an. | R | R | Hoch | | Ist COTS? | Ja oder Nein. Ob es sich um eine kommerzielle Anwendung oder eine interne Entwicklung handelt | R | R | Hoch | | COTS-Produkt und Version | Name und Version des kommerziellen Softwareprodukts | R | R | Hoch | | Description | Primäre Anwendungsfunktion und Kontext | R | R | Hoch | | Kritikalität | Zum Beispiel eine strategische oder umsatzgenerierende Anwendung oder die Unterstützung einer wichtigen Funktion | R | R | Hoch | | Typ | Zum Beispiel Datenbank, Kundenbeziehungsmanagement (CRM), Webanwendung, Multimedia, gemeinsam genutzter IT-Service | R | R | Hoch | | Umgebung | Zum Beispiel Produktion, Vorproduktion, Entwicklung, Test, Sandbox | R | R | Hoch | | Einhaltung gesetzlicher Vorschriften und Vorschriften | Für den Workload geltende Frameworks (z. B. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) und regulatorische Anforderungen | R | R | Hoch | | Abhängigkeiten | Upstream- und Downstream-Abhängigkeiten zu internen und externen Anwendungen oder Diensten. Nichttechnische Abhängigkeiten wie betriebliche Elemente (z. B. Wartungszyklen). | R | O | Hoch | | Abbildung der Infrastruktur | Zuordnung zu physischen and/or virtuellen Ressourcen, aus denen die Anwendung besteht | R | R | Hoch | | License | Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise) | R | R | Mittel-Hoch | | Cost (Kosten) | Kosten für Softwarelizenzen, Softwarebetrieb und Wartung | – | R | Mittel-Hoch | | Geschäftseinheit | Zum Beispiel Marketing, Finanzen, Vertrieb | R | R | Hoch | | Angaben zum Eigentümer | Kontaktinformationen für den Inhaber der Anwendung | R | R | Hoch | | DR-Informationen | Komponenten für die Notfallwiederherstellung | R | R | Hoch | | Migrationsstrategie | Zum Beispiel einer der 6 Rs für die Migration zu AWS | R | R | Hoch | | Support-Tickets | Daten für 12 bis 24 Monate zur Bewertung der Produktivität und der finanziellen Auswirkungen von Ausfällen, Verlangsamungen, Transaktionsdrosselung und Überschreitungen von Batchfenstern | O | R | Mittel | **Infrastruktur** | **Attributname** | **Beschreibung** | **Inventar und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** | | --- | --- | --- | --- | --- | | Eindeutige Kennung | Zum Beispiel Server-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventar- und Kontrollsystemen verfügbar. Ziehen Sie es in Betracht IDs, einzigartige Produkte zu erstellen, wann immer diese in Ihrer Organisation nicht definiert sind. | R | R | Hoch | | Name des Netzwerks | Assetname im Netzwerk (z. B. Hostname) | R | R | Hoch | | DNS-Name (vollqualifizierter Domänenname oder FQDN) | DNS-Name | R | O | Hoch | | IP-Adresse und Netzmaske | Interne and/or öffentliche IP-Adressen | R | R | Hoch | | Asset type (Objekttyp) | Zum Beispiel physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz | R | R | Hoch | | Product Name (Produktname) | Kommerzieller Anbieter und Produktname (z. B. IBM Power Systems VMware ESXi, Exadata) | R | R | Hoch | | Betriebssystem | Zum Beispiel REHL 8, Windows Server 2019, AIX 6.1 | R | R | Hoch | | Konfiguration | Zugewiesene CPU, Anzahl der Kerne, Threads pro Kern, Gesamtspeicher, Netzwerkkarten | R | R | Hoch | | Nutzung | Spitzenwert und Durchschnitt von CPU, Arbeitsspeicher und Speicher. Durchsatz der Datenbankinstanz. | R | R | Hoch | | License | Art der Warenlizenz (z. B. RHEL Standard) | R | R | Hoch | | Handelt es sich um eine gemeinsame Infrastruktur? | Ja oder Nein, um Infrastrukturdienste zu bezeichnen, die gemeinsam genutzte Dienste wie Authentifizierungsanbieter, Überwachungssysteme, Backup-Dienste und ähnliche Dienste bereitstellen | R | R | Hoch | | Zuordnung von Anwendungen | Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden | R | R | Hoch | | Cost (Kosten) | Vollständige Kosten für Bare-Metal-Server, einschließlich Hardware, Wartung, Betrieb, Speicher (SAN, NAS, Objekt), Betriebssystemlizenz, Aufteilung des Rack-Speicherplatzes und Gemeinkosten im Rechenzentrum | – | R | Mittel-Hoch | | Geschätztes Volumen der Datenübertragung (ein/aus) | Zum Beispiel pro Infrastruktur-Asset und mehr pro Tag über einen Zeitraum von 30 Tagen | O | R | Mittel | **Netzwerke** | **Attributname** | **Beschreibung** | **Bestandsaufnahme und Priorisierung** | **Geschäftsszenario** | **Empfohlene Treuestufe (mindestens)** | | --- | --- | --- | --- | --- | | Größe des Rohres (Mb/s), redundancy (Y/N) | Aktuelle WAN-Link-Spezifikationen (z. B. 1000 MB/s redundant) | R | R | Mittel-Hoch | | Link-Nutzung | Spitzen- und Durchschnittsauslastung, ausgehende Datenübertragung (GB/Monat) | R | R | Mittel-Hoch | | Latenz (ms) | Aktuelle Latenz zwischen verbundenen Standorten. | R | O | Hoch | | Cost (Kosten) | Aktuelle Kosten pro Monat | – | R | Mittel-Hoch | **Migration** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html) # Festlegung einer Grundlage für das Anwendungsportfolio Um zuverlässige Migrationspläne zu erstellen, müssen Sie eine Ausgangsbasis für das Anwendungsportfolio und die zugehörige Infrastruktur festlegen. Eine Portfolio-Baseline bietet einen umfassenden Überblick über den Migrationsumfang, einschließlich der technischen Abhängigkeiten und der Migrationsstrategie. Die Portfolio-Baseline gibt Aufschluss darüber, welche Anwendungen in den Geltungsbereich der Migration fallen, und gibt Aufschluss darüber, ob die im Abschnitt [Grundlegendes zu den Anforderungen an die vollständige Bewertung aufgeführten Daten](understanding-complete-assessment-data-requirements.md) erfasst wurden. Ebenso wird die gesamte zugehörige Infrastruktur (Rechen- und Speichernetzwerke) verstanden und den Anwendungen zugeordnet. Technische Abhängigkeiten können in vier Kategorien beschrieben werden: + **pplication-to-infrastructureA-Abhängigkeiten** stellen die Verbindung zwischen Software und physischer oder virtueller Hardware her. Beispielsweise besteht eine Abhängigkeit zwischen einer CRM-Anwendung und den virtuellen Maschinen, auf denen sie installiert ist. + Abhängigkeiten **zwischen Anwendungen und Komponenten** beschreiben, wie Komponenten, die in verschiedenen Infrastrukturressourcen ausgeführt werden, interagieren. Ein Beispiel für eine Abhängigkeit von Anwendungskomponenten ist ein Web-Frontend, das auf virtuellen Maschinen ausgeführt wird, wobei eine Anwendungsebene auf einer anderen virtuellen Maschine ausgeführt wird und eine Datenbank auf einem Datenbankcluster läuft. + **pplication-to-applicationAbhängigkeiten beziehen sich auf die Interaktion zwischen Anwendungen oder Anwendungskomponenten mit anderen Anwendungen oder deren Komponenten.** Ein Beispiel für eine application-to-application Abhängigkeit ist eine Zahlungsabwicklungsanwendung und eine Lagerverwaltungsanwendung. Diese Anwendungen sind unabhängig, interagieren jedoch ständig mithilfe definierter API-Operationen. + **Application-to-infrastructure Dienstabhängigkeiten** sind technisch gesehen application-to-application Abhängigkeiten, da der Infrastrukturdienst selbst eine Anwendung ist. Wir empfehlen jedoch, diese getrennt zu kategorisieren. Der Hauptgrund dafür ist, dass Infrastrukturdienste in der Regel von vielen Anwendungen gemeinsam genutzt werden, sodass sie eine lange Reihe von Abhängigkeiten aufweisen. Sie folgen in der Regel auch einer anderen Migrationsstrategie und einem anderen Migrationsmuster. Ein Load Balancer kann beispielsweise Balancing-Pools für mehrere Anwendungen enthalten. Entscheidend ist die Abhängigkeit vom Pool, der wahrscheinlich zusammen mit der abhängigen Anwendung einzeln migriert wird, während der Load Balancer selbst beibehalten oder außer Betrieb genommen wird. Darüber hinaus trägt die Individualisierung application-to-infrastructure von Dienstabhängigkeiten dazu bei, falsche Abhängigkeitsgruppen zu vermeiden. Eine falsche Abhängigkeitsgruppe liegt vor, wenn mehrere Geschäftsanwendungen gruppiert werden, was bedeutet, dass alle, die eine gemeinsame Abhängigkeit von einem Infrastrukturdienst haben, gleichzeitig migriert werden müssen. Beispielsweise sind Authentifizierungsdienste wie Active Directory wahrscheinlich mit großen Anwendungsgruppen verknüpft. Der Schlüssel liegt darin, diese Anwendungen individuell anzugehen und die Abhängigkeit zu beheben, indem der Dienst aktiviert wird AWS Directory Service for Microsoft Active Directory, z. B. in der Cloud-Umgebung. Wenn Sie eine Ausgangsbasis für das Portfolio festlegen, empfehlen wir Ihnen, eine Migrationsstrategie für jede Anwendungskomponente zu bestätigen. Bei der Migrationsstrategie handelt es sich um eine der 6 Rs für die Migration (siehe Abschnitt [Iteration der Migrationsstrategie mit 6 Rs](iterating-6-rs-migration-strategy-selection.md)). In der Portfolio-Baseline sollte jeder Anwendung einer der 6 Rs zugeordnet werden. Außerdem sollte jeder Infrastrukturkomponente der Anwendung eine 6R-Strategie zugeordnet werden. Verwenden Sie automatisierte Discovery-Tools, um eine Basisversion des Portfolios, einschließlich Abhängigkeiten und Migrationsstrategien, zu erstellen (siehe [Bewertung des Bedarfs an Discovery-Tools](understanding-initial-assessment-data-requirements.md#discovery-tooling)). Ergänzen Sie die Daten durch Informationen, die von wichtigen Stakeholdern wie Anwendungseigentümern und Infrastrukturteams gesammelt wurden. Sammeln Sie so lange Daten, bis Sie ein vollständiges Portfolioinventar erhalten haben, das den im [Abschnitt mit den Datenanforderungen](understanding-complete-assessment-data-requirements.md) für diese Phase beschriebenen Eigenschaften und dem Grad an Genauigkeit entspricht. Der daraus resultierende Datensatz wird maßgeblich dazu beitragen, die Migration voranzutreiben. Beachten Sie, dass diese Aktivität je nach Umfang Ihres Migrationsumfangs und den verfügbaren Tools mehrere Wochen in Anspruch nehmen kann. # Iteration der Priorisierungskriterien Bevor Sie Migrationspläne erstellen, empfehlen wir Ihnen, die Kriterien für die Priorisierung von Anwendungen zu wiederholen, um von der Auswahl der Pilotanwendungen zur langfristigen Wellenplanung überzugehen. [In früheren Abschnitten haben wir Standardpriorisierungskriterien eingeführt, mit denen einfache cloudfähige Anwendungen priorisiert werden (siehe Priorisierung von Anwendungen).](prioritization-and-migration-strategy.md#prioritizing-applications) Dies lag daran, dass wir in der Anfangsphase empfehlen, mit unkritischen Anwendungen zu beginnen, um die Migrationsprozesse zu verfeinern und die gewonnenen Erkenntnisse einfließen zu lassen. In dieser Phase und um langfristige Pläne zu erstellen, sollte die Reihenfolge, in der Anwendungen migriert werden, jedoch an den Geschäftsfaktoren ausgerichtet werden. Die Anwendung der neuen Kriterien wird zu einer neuen Rangfolge der Anträge führen, die eine wichtige Grundlage für die Wellenplanung bilden werden. Prüfen Sie die verfügbaren Datenpunkte aus dem Anwendungsportfolio und wählen Sie die Attribute aus, anhand derer die Priorisierung der Anwendungen auf der Grundlage geschäftlicher Faktoren bestimmt wird. Überprüfen Sie zunächst Ihre Geschäftstreiber (siehe [Geschäftstreiber und technische Leitprinzipien](business-drivers-technical-guiding-principles.md)). Wählen Sie anschließend auf der Grundlage Ihrer Geschäftstreiber die Attribute aus, anhand derer Sie Anwendungen für die Migration priorisieren können. Die folgende Tabelle zeigt beispielhafte Priorisierungskriterien, die auf die geschäftlichen Innovationstreiber abgestimmt sind. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html) Die folgende Tabelle zeigt beispielhafte Priorisierungskriterien, die auf die geschäftlichen Faktoren abgestimmt sind, um eine schnelle Kostensenkung zu erreichen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html) Testen Sie die Priorisierungskriterien und wiederholen Sie sie, bis Sie mit dem Ergebnis im Allgemeinen einverstanden sind. Es sind mindestens drei oder vier Iterationen erforderlich, um eine Basisversion zu erhalten. # Die Auswahl der 6 Rs-Migrationsstrategie wird wiederholt In dieser Phase empfehlen wir Ihnen, den 6-Rs-Entscheidungsbaum zu iterieren und weiterzuentwickeln. Im Abschnitt [Bestimmung des R-Typs für die Migration](prioritization-and-migration-strategy.md#migration-r-type) wurde ein Standard-Entscheidungsbaum eingeführt. Wir empfehlen, den Baum zu überarbeiten und dabei die Erfahrungen aus der Migration der ersten Pilotanwendungen zu berücksichtigen und sicherzustellen, dass er weiterhin den Geschäftsfaktoren, den Priorisierungskriterien und Ihren individuellen Umständen entspricht. Überprüfen Sie den Entscheidungsbaum anhand von Beispielanwendungen und stellen Sie sicher, dass er immer noch die erwartete Strategie liefert. Andernfalls aktualisieren Sie die Logik entsprechend. Der daraus resultierende Baum wird für die Festlegung von Basislinien für das Anwendungsportfolio und für die Zuweisung von Migrationsstrategien für jede Anwendungskomponente von entscheidender Bedeutung sein. Wie im vorherigen [Abschnitt mit den 6 Rs](prioritization-and-migration-strategy.md#migration-r-type) beschrieben, gelten die 6 Rs auch für die Infrastruktur, und es ist ebenso wichtig, sie entsprechend zuzuweisen. Für eine bestimmte Anwendungskomponente gibt es zwar eine Migrationsstrategie, aber auf Infrastrukturebene folgt jede Infrastrukturanlage einer bestimmten Migrationsstrategie, die sich von der Strategie unterscheiden kann, die für die von ihr unterstützte Anwendungskomponente festgelegt wurde. Denken Sie daran, dass der Entscheidungsbaum mit 6 Rs nur für Anwendungskomponenten gilt. Die Migrationsstrategie für die Infrastruktur leitet sich von der Strategie ab, die für die Anwendung ausgewählt wurde. Beispielsweise könnte für eine Anwendungskomponente, die auf eine neue Plattform umgestellt wird, die aktuelle Infrastruktur, auf der sie gehostet wird, ausgemustert werden. Stellen Sie sicher, dass jeder Anwendungskomponente und der zugehörigen Infrastruktur Migrationsstrategien zugewiesen werden. Diese Informationen werden ein Schlüsselfaktor bei der Schätzung des Aufwands, der erforderlichen Kapazitäten und Fähigkeiten sowie bei der Erstellung von Plänen für die Migrationswelle sein. Weitere Informationen zur Bestimmung Ihrer 6 Rs finden Sie in den [AWS Migration Hub Strategieempfehlungen](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). # Wellenplanung In der Wellenplanung ist eine Abhängigkeitsgruppe eine Sammlung von Anwendungen und Infrastrukturen mit technischen und nichttechnischen Abhängigkeiten, die nicht gelöst werden können. Aufgrund dieser Abhängigkeiten müssen die Anwendungen und die Infrastruktur in einer Abhängigkeitsgruppe gleichzeitig oder an einem bestimmten Datum migriert werden. Beispielsweise werden eine Anwendung, die auf einer virtuellen Maschine ausgeführt wird, und eine Datenbank, die auf einer separaten virtuellen Maschine ausgeführt wird, bei der geringe Latenzzeiten oder hohe Datenverkehrsmengen und komplexe Abfragen erforderlich sind, wahrscheinlich zusammen migriert, anstatt eine Komponente in der Cloud und die andere lokal zu betreiben. Ebenso werden unabhängige Anwendungen, die über eine API mit ähnlichen Anforderungen an niedrige Latenz interagieren, gleichzeitig migriert. Migrationswellen dauern in der Regel 4—8 Wochen und können ein oder mehrere Migrationsereignisse beinhalten. Abhängigkeitsgruppen werden zu Wellen zusammengefasst, sodass eine Welle eine oder mehrere Abhängigkeitsgruppen enthalten kann. Die Welle umfasst auch andere Aktivitäten, die für die Migration erforderlich sind. Dazu gehören die Einrichtung der AWS Infrastruktur (z. B. landing zone, Sicherheit und Betrieb), Migrationstools und Migrationsaktivitäten wie Datenreplikation, Umstellungsplanung, Tests und Support nach der Migration. Um den Erfolg zu messen und die Fortschritte zu verfolgen, sollten die Wellen an den Ergebnissen und Geschäftstreibern ausgerichtet werden. Dies wird sich auch auf die Dauer der Welle und die Abhängigkeitsgruppen auswirken, die eine Welle umfasst. Der Abschluss einer Welle sollte eine messbare Leistung widerspiegeln. Bei der Planung einer Welle können auch andere Faktoren, wie z. B. technische Leitprinzipien, kombiniert werden. Wellen können beispielsweise anhand der Umgebung (z. B. Entwicklung, Test, Produktion) oder anhand der Migrationsstrategie (z. B. Rehost-Welle, Replattform-Welle) definiert werden. Um effektive und zuverlässige Migrationspläne zu erstellen, müssen Sie sich einen vollständigen Überblick über das Anwendungsportfolio, die zugehörige Infrastruktur (Rechenleistung, Speicher, Netzwerke), die Zuordnung von Abhängigkeiten und die Migrationsstrategie verschaffen. Im Abschnitt zur [Festlegung einer Ausgangsbasis für das Anwendungsportfolio](baseline-application-portfolio.md) wurden vier Kategorien von technischen Abhängigkeiten beschrieben. Diese Abhängigkeiten tragen zur Entstehung von Migrationswellen und zur Definition von Abhängigkeitsgruppen bei. Abhängigkeitsgruppen werden anhand der Wichtigkeit der Abhängigkeit bestimmt. Darüber hinaus müssen nichttechnische Abhängigkeiten berücksichtigt werden. Beispielsweise beeinflussen Zeitpläne für Anwendungsveröffentlichungen, Wartungsfenster und wichtige Geschäftstermine wie die Verarbeitung am Monatsende oder Quartalsende den Wave-Plan. Stellen Sie fest, ob es sich um eine *weiche* oder eine *harte* Abhängigkeit handelt. Eine weiche Abhängigkeit ist eine Beziehung zwischen zwei oder mehr Anlagen oder von einer Anlage zu einer Beschränkung, die nicht vom Standort der Komponenten abhängt. Beispielsweise können zwei Systeme, die im selben lokalen Netzwerk (oder derselben Infrastruktur) betrieben werden, aufgeteilt werden, indem eines dieser Systeme in die Cloud verschoben wird, während das andere vor Ort verbleibt. Ein anderes Beispiel ist ein System, das während eines Wartungsfensters migriert werden kann, ohne dass die Wartungsaktivitäten beeinträchtigt werden. Eine feste Abhängigkeit ist eine Beziehung zwischen zwei oder mehr Anlagen oder von einer Anlage zu einer Beschränkung, die vom Standort abhängig ist. Beispielsweise besteht bei zwei Systemen, die im selben lokalen Netzwerk betrieben werden und die bei der Kommunikation zwischen dem Anwendungsserver und dem Datenbankserver stark von einer niedrigen Latenz abhängig sind, eine starke Abhängigkeit. Die Verlagerung nur eines dieser Systeme in die Cloud würde zu Funktions- oder Leistungsproblemen führen, die nicht gelöst werden können. Ebenso können nichttechnische Gründe, wie die Verfügbarkeit von Ressourcen (z. B. das Team, das die Migration durchführt) oder betriebliche Einschränkungen, wie z. B. Wartungsfenster, bei denen zwei Systeme nur innerhalb eines bestimmten Zeitfensters migriert werden können, zu einer starken Abhängigkeit dieser Ressourcen führen. Um einen Migrationswellenplan zu erstellen, bestimmen Sie Ihre Abhängigkeitsgruppen, indem Sie Abhängigkeiten analysieren, idealerweise aus einer vertrauenswürdigen Datenquelle wie speziellen Discovery-Tools, und diese Informationen mit den Kriterien für die Priorisierung Ihrer Anwendung und den betrieblichen Umständen kombinieren. Die Anwendungen, die in der Priorisierungsrangliste ganz oben stehen, sollten auf Ihre ersten Migrationswellen ausgerichtet sein. Ermitteln Sie die Wellenkapazität (die Anzahl der Anwendungen, die eine Welle enthalten kann) auf der Grundlage von Ressourcenverfügbarkeit, Risikobereitschaft, geschäftlichen und technischen Einschränkungen, Erfahrung und Fähigkeiten. Erwägen Sie die Zusammenarbeit mit AWS professionellen Service- oder AWS Migrationskompetenzpartnern, die Ihnen Spezialisten zur Verfügung stellen können, die Sie während des gesamten Prozesses unterstützen. Die Priorisierungskriterien sind ein erster Hinweis auf die Reihenfolge, in der Sie Ihre Anwendungen in die Cloud verlagern werden. Abhängigkeitsgruppen sind jedoch die eigentliche Determinante für die Anwendungen, die zu einem bestimmten Zeitpunkt verschoben werden. Dies liegt daran, dass Anwendungen, denen eine hohe Priorität zugewiesen wurde, starke Abhängigkeiten zu Anwendungen haben können, die sich in der Mitte oder am Ende der Rangliste befinden. Die Migrationsstrategie wird auch die Zusammensetzung einer Welle beeinflussen. Beispielsweise wird eine Anwendung mit hoher Priorität, die eine Refactoring-Strategie erfordert, die mehrere Wochen oder Monate an Analyse, Design, Tests und Vorbereitungen erfordern kann, wahrscheinlich in eine spätere Welle aufgenommen. ## Einen Wellenplan erstellen Voraussetzung für die Migration einer Welle von Anwendungen sind die Daten zum Anwendungsportfolio und die detaillierte Bewertung der Anwendungsgruppe, die in der Welle migriert werden soll. Die detaillierte Bewertung sollte die Liste der Anwendungen in der Welle, die zugehörigen Infrastrukturdetails, ein Zieldesign und eine Migrationsstrategie für jede Anwendung umfassen. Die Festlegung von Eigenverantwortung und Steuerung ist entscheidend für die Verwaltung und Nachverfolgung der Arbeit in der Welle, der Programmabhängigkeiten, des Änderungsmanagements, der Probleme und Risiken. Stellen Sie sicher, dass ein Governance-Framework für die Verwaltung des Plans vorhanden ist. Um den Wellenplan zu skizzieren, beginnen Sie mit einem Standard-Wellenkonstrukt. Was passiert innerhalb einer Welle? Nachdem die erste Eingabe definiert wurde, kann die Welle beginnen. In der Regel handelt es sich um folgende Aktivitäten: 1. Verfeinern Sie den Umstellungsplan. In dieser Aktivität sollten die Abläufe und Schritte beschrieben werden, die zum Zeitpunkt der Migration ergriffen werden müssen, einschließlich der Koordination mit anderen internen und externen Teams. 1. Verfeinern Sie den Rollback-Plan. Was muss getan werden, um die Anwendungen rückgängig zu machen, falls etwas schief geht? 1. Bereiten Sie die Zielinfrastruktur vor. Sie können beispielsweise die AWS landing zone erstellen oder erweitern (Sicherheit AWS-Konto, Netzwerk, Infrastrukturdienste, andere unterstützende Infrastruktur). 1. Testen Sie die Zielinfrastruktur. 1. Nutzen Sie die Migrationstools. Installieren Sie beispielsweise Replikationsagenten und starten Sie die Datenübertragung. 1. Führen Sie einen Umstellungsplan durch und führen Sie Testläufe durch. Gruppieren Sie alle teilnehmenden Teammitglieder und überprüfen Sie alle Schritte im Voraus. 1. Überwachen Sie Datenreplikation und Infrastrukturbereitstellungen. 1. Bestätigen Sie die Betriebsbereitschaft der Infrastruktur und der Anwendungen in AWS. 1. Bestätigen Sie die Sicherheitsbereitschaft. 1. Bestätigen Sie gegebenenfalls die Einhaltung gesetzlicher Vorschriften und behördlicher Auflagen (z. B. Workload-Validierung vor und nach der Migration). 1. Migrieren Sie die Anwendungen zu AWS und führen Sie Tests vor der Inbetriebnahme durch. 1. Bieten Sie Support nach der Migration für einen bestimmten Zeitraum, z. B. 3 Tage, an dem die Betriebsteams und die Migrationsteams uneingeschränkt zur Verfügung stehen, um Probleme zu lösen und Optimierungen vorzunehmen. 1. Führen Sie nach der Migration eine Überprüfung durch. Dokumentieren Sie die gewonnenen Erkenntnisse und integrieren Sie sie in future Wellen. 1. Schließen Sie die Welle ab, indem Sie die Betriebsübergabe und die Erstellung von Kennzahlen für die Berichterstattung bestätigen. Wie lange jede dieser Aktivitäten dauert, hängt von der Komplexität des Umfangs, der Kapazität der Welle, den beteiligten Personen und Ihren individuellen Umständen ab. Wo immer möglich, sind kleinere Wellen vorzuziehen, da dadurch die Auswirkungen von Verzögerungen oder Migrationsblockaden verringert werden. Bestimmen Sie gemeinsam mit Ihren Teams, wie lange eine Welle standardmäßig dauern soll. Fahren Sie als Nächstes mit der Analyse der Daten fort, um eine erste übergeordnete Struktur aus leeren Wellen zu erstellen (denen noch keine Anwendung zugewiesen wurde). Stellen Sie sich die folgenden Fragen: + Wie lang ist die Gesamtdauer des Migrationsprogramms? + Was sind die Fristen? + Gibt es feste Austrittstermine für Rechenzentren? + Gibt es Enddaten für Kollokationsverträge? + Was sind die Aktualisierungszyklen für Anwendungen und Infrastruktur? + Was sind die Wartungs- und Release-Zyklen für Anwendungen? + Gibt es Termine, an denen Migrationen vermieden werden sollten (z. B. Veröffentlichungs- und Wartungszyklen, Jahresende, Feiertage, Verarbeitung am Monatsende)? Ausgehend von diesen Überlegungen sollten Sie die einzelnen Phasen in einem Plan zusammenfassen. Um den Migrationsprozess zu beschleunigen, empfehlen wir, sich nach Möglichkeit zu überlappen. Der Schlüssel zu überlappenden Wellen liegt darin, zu definieren und zu berücksichtigen, was innerhalb einer Welle passiert. Typischerweise finden die Bereitstellungsaktivitäten, die Validierung der Zielinfrastruktur und die Datensynchronisierung in der ersten Hälfte einer Welle statt. In der zweiten Hälfte werden die eigentliche Migration, die Tests und die Betriebsübergabe im Mittelpunkt stehen. Das bedeutet, dass an jeder Hälfte des Prozesses unterschiedliche Teams beteiligt sind und dass Sie einige Effizienzsteigerungen erzielen können. Sobald das an der Vorbereitung der Zielinfrastruktur beteiligte Team beispielsweise seine Arbeit abgeschlossen hat, kann es mit der Arbeit an den Anforderungen der nächsten Welle beginnen. Im Allgemeinen ist es vorzuziehen, dass die meisten Wellen eine ähnliche Länge und Struktur haben, um einen fabrikähnlichen Ansatz bei Migrationen zu ermöglichen. Während des Wellenplanungsprozesses kann die Größe einer bestimmten Welle jedoch erweitert werden, um Abhängigkeiten oder betrieblichen Anforderungen gerecht zu werden. Als Nächstes wird auf der Grundlage der identifizierten Abhängigkeitsgruppen die maximale Größe einer Welle im Hinblick auf die Anzahl der Abhängigkeitsgruppen bestimmt, die sie enthalten kann. Die Wellengröße wird in der Regel von der Risikobereitschaft (z. B. wie viele parallel Veränderungen toleriert werden können) und der Ressourcenverfügbarkeit (z. B. wie viele parallel Veränderungen mit den verfügbaren Ressourcen, Fähigkeiten und dem Budget durchgeführt werden können) bestimmt. Lassen Sie sich bei der frühen Planung jedoch nicht durch den Ressourcenbedarf und die Verfügbarkeit einschränken. Wellen, die mehr als eine Abhängigkeitsgruppe enthalten, können in future Iterationen in kleinere Wellen zerlegt werden. Nachdem die Abhängigkeitsgruppen für eine bestimmte Welle bestätigt wurden, überprüfen Sie die Ressourcenanforderungen für die Migration der Welle. Erwägen Sie, die Wellengröße (die Anzahl der darin enthaltenen Abhängigkeitsgruppen) an die Ressourcenanforderungen anzupassen. Dies kann zu kleineren oder größeren Wellen führen. Iterieren Sie den Wellenplan nach Bedarf, bis alle Wellen definiert sind. ## Den Wandel managen Das Anwendungsportfolio und die zugehörige Infrastruktur werden sich während des Lebenszyklus von Migrationsprogrammen ändern. Langfristige Migrationsprogramme existieren parallel zur normalen Geschäftsentwicklung und -änderung. Anwendungen entwickeln sich ständig weiter, während sie auf ihre Migration warten. Server werden hinzugefügt oder entfernt, neue Infrastruktur wird vor Ort bereitgestellt. Es wird erwartet, dass der Umfang einer Welle oder einer Abhängigkeitsgruppe geändert werden muss. Änderungen sind insbesondere dann erforderlich, wenn kurz vor dem Migrationsdatum eine bisher unbekannte Abhängigkeit identifiziert wird oder ein neuer Server in das Inventar aufgenommen wird. Manchmal kann dies während der Migration selbst passieren. Änderungen des Umfangs wirken sich auf Abhängigkeitsgruppen und Wellen aus. Um mit Veränderungen umzugehen und die Auswirkungen so gering wie möglich zu halten, ist es wichtig, einen Mechanismus zur Kontrolle des Umfangs einzurichten. Ein Mechanismus zur Kontrolle des Geltungsbereichs erfordert die Definition einer zentralen Informationsquelle für den Geltungsbereich. Dabei kann es sich um ein Tool zur Verwaltung des Geltungsbereichs oder um eine CSV-Datei, Tabelle oder Datenbank handeln, wie sie in der Leitung des Migrationsprogramms definiert ist. Sie müssen Änderungen identifizieren, die Auswirkungen analysieren und die Änderungen den relevanten Stakeholdern mitteilen, damit diese Maßnahmen ergreifen können. Der Wellenplan wird daraufhin wiederholt. # Detaillierter Geschäftsszenario In dieser Phase empfehlen wir, den Umfang des Geschäftsszenarios zu validieren und zu erweitern, um das Transformationsprogramm mit einem höheren Detaillierungsgrad zu unterstützen. Das schnell zusammengestellte erste, richtungsweisende Geschäftsszenario soll genügend Selbstvertrauen bieten, um in die grundlegenden Schritte und die nächste Stufe der detaillierten Planung zu investieren. Die Entwicklung eines detaillierten Geschäftsszenarios unterstützt diesen Planungsprozess auf folgende Weise: + Bereitstellung von Finanzanalysen, die als Grundlage für Entscheidungen darüber dienen, was migriert und modernisiert werden sollte, welche Optionen ausgewählt werden sollten und wie die Arbeit in Phasen und Prioritäten aufgeteilt werden sollte + Validierung, Verfeinerung und Weiterentwicklung der ursprünglichen, richtungsweisenden finanziellen Argumente durch erneute eingehende Prüfung der folgenden Punkte: + Das Potenzial zur Senkung der Infrastrukturkosten + Die interne IT-Produktivität und jegliche Effizienz ausgelagerter Abläufe + Die Schätzungen für die Investitionen, die für die Einrichtung, Migration und Modernisierung des Programms erforderlich sind + Identifizierung, Schätzung des Umfangs und Einrichtung des Prozesses zur Verfolgung der weiteren Werttreiber, die die Migration mit sich bringt Im detaillierten Geschäftsszenario legen Sie Folgendes fest: + Die objektive Grundlage, auf der das Mandat und die Investitionen für die Durchführung zumindest der ersten Migrationsphase gesichert werden sollen + Die grundlegenden finanziellen Mindesterwartungen für das Programm + Klarheit über die finanzielle Grundlage, auf der die verschiedenen Entscheidungen zur Gestaltung und Priorisierung der Migration getroffen werden, sodass die neue Führung fundierte Entscheidungen treffen kann, wenn sich die Umstände und Personen im Laufe des Programms ändern. + Einblicke in inkrementelle Bereiche der Kostenoptimierung, die untersucht werden müssen, sobald die ersten Nutzungsdaten verfügbar sind, wenn Workloads migriert und in Betrieb genommen werden + Schätzungen zum Wert, den die Cloud-Transformation dem Unternehmen durch erhöhte Widerstandsfähigkeit und Agilität bringt + Die damit verbundenen KPIs Kennzahlen und Annahmen, die zur Schätzung des finanziellen Gewinns aus verbesserter Resilienz und Agilität verwendet werden, bilden dann die Grundlage für die Realisierung der wichtigsten Vorteile des Programms ## Ermitteln Sie, welche Szenarien für den Fall erforderlich sind Bei der Erstellung eines detaillierten Geschäftsszenarios müssen in der Regel mehrere Szenarien entwickelt werden, um die verschiedenen Zwecke zu unterstützen, für die der Geschäftsszenario verwendet wird. **Szenario mit minimaler Änderung** — Um die Mindesterwartung der finanziellen Leistung zu beurteilen, bereiten Sie ein Szenario vor, das von der erwarteten Mindeständerung des Status Quo ausgeht. Dieses Szenario ist im schlimmsten Fall eine nützliche Unterstützung, wenn es darum geht, das Mandat zu erhalten, in die Migration zu investieren. Dieses Szenario modelliert das erwartete Mindestmaß an Kapazitätswachstum und minimale Änderungen für andere quality-of-service Bedürfnisse, wie Verfügbarkeit und Belastbarkeit. Die geringste Änderung verursacht die niedrigsten Kosten und die geringsten Ressourcenineffizienzen für das aktuelle Betriebsmodell. **Wahrscheinlichstes Szenario** — Um fundierte Entscheidungen über die Programmstrategie und die Priorisierung zu treffen, bereiten Sie das Szenario vor, das die Erwartungen des Unternehmens widerspiegelt. Dieses Szenario sollte das wahrscheinliche Wachstum oder die Verringerung der Spitzennutzung und die Upgrade-Kosten beinhalten, um der Nachfrage des Unternehmens nach hoher Servicequalität (insbesondere Verfügbarkeit und Ausfallsicherheit) gerecht zu werden. **Andere spezifische Szenarien** — Wenn es immer noch notwendig ist, eine Annahme zu treffen, die große Auswirkungen auf das Geschäftsszenario haben könnte, sollten Sie Szenarien entwickeln, sowohl für die Fälle, in denen die Annahme zutrifft, als auch für die, in denen sie nicht zutrifft. Wir empfehlen jedoch, die Anzahl dieser alternativen Szenarien auf ein absolutes Minimum zu beschränken. Die Erstellung von insgesamt mehr als drei bis vier Szenarien verlangsamt den Fortschritt und wird teuer, verwirrend und schwierig zu verwalten. Führen Sie, wo immer möglich, Experimente durch und versuchen Sie, größere Annahmen zu entfernen. ## Validieren und verfeinern Sie das Infrastruktur- und Migrationskostenmodell Nachdem Sie die Portfolioanalyse abgeschlossen und das Design und die Größe des Ziels vorbereitet haben AWS-Services, verfeinern Sie die Schätzungen der Betriebskosten für das aktuelle Betriebsmodell (COM) und das future Betriebsmodell (FOM) AWS für jedes Szenario. In der Regel müssen die Schätzungen für Folgendes verfeinert werden: + **COM-Infrastrukturkosten für** Hardwareaktualisierungen, Installation und Wartung von Hypervisor-Hostservern, Bare-Metal-Servern, Speichern, Netzwerkgeräten und Sicherheitsgeräten. Berechnen Sie diese mit den tatsächlichen Preisen und Rabattstufen für die für das Szenario benötigte Kapazität. + **Kosten für COM-Rechenzentren und gemeinsame Einrichtungen**, einschließlich Platz, Kühlung, Strom, Racks, unterbrechungsfreier Stromversorgung (USV), Verkabelung, physische Sicherheitssysteme, die auf das Wachstum zugeschnitten und auf die Kapazität zugeschnitten sind, sowie die Hochverfügbarkeit und Notfallwiederherstellung (DR) für das Szenario. + **Kosten für COM-Netzwerkdienste**, einschließlich Kosten für WAN-Verbindungen, Content Delivery Networks und virtuelle private Netzwerke (VPNs), berechnet anhand der vertraglich vereinbarten Preise für die Konnektivitäts-, Bandbreiten-, Durchsatz- und Latenzanforderungen für das Szenario. + Die **Kosten für COM-Anwendungen und Infrastruktursoftware** basieren auf bestehenden Verträgen zur Erhöhung oder Reduzierung der Nutzung für das Szenario. + Die ** AWS Betriebskosten von FOM**, einschließlich technischem Support und Managed Services, je nach Bedarf, basieren auf der verfeinerten Servicearchitektur, der Instanzgröße, dem bevorzugten Preismodell, der erwarteten Nutzung und der Nutzungsvolatilität. + Die **Lizenzierung von** FOM-Anwendungen basiert auf dem endgültigen Anwendungsdesign, der Konfiguration der Infrastruktur, auf der die Anwendungen ausgeführt werden, dem Wachstum im Laufe der Zeit und den Regeln für die Übertragbarkeit von Lizenzen. + **Kostenschätzungen für die FOM-Migration und -Modernisierung**, verfeinert, um den Basisplan für die Migrationswelle für das Szenario widerzuspiegeln, und detailliert, um die Kosten für jeden Workload anzugeben, insbesondere für diejenigen, die neu auf die Plattform gebracht, zurückgekauft oder umgestaltet werden müssen. + Die **Kosten für die Außerbetriebnahme von FOM**, einschließlich Schätzungen der Kosten für die Abschreibung von Anlagen und die vorzeitige Kündigung von Verträgen, wurden überarbeitet, um den Zeitplan für die Stilllegung im Basisplan für die Migrationswelle widerzuspiegeln, die Überprüfung, welche Vermögenswerte wiederverwendet werden können und welche Anlagen ausgetauscht werden können, um Abschreibungen zu minimieren, sowie die Kosten für die Entsorgung der Sachanlagen und Medien. + Die **Kosten für den parallel Betrieb der Migration** wurden so angepasst, dass sie dem Zeitpunkt jeder Umstellung und jeder Außerbetriebnahme vorhandener Dienste Rechnung tragen. ## Verfeinern Sie das Wertmodell für IT-Produktivität und IT-Betrieb und unterstützen Sie die Effizienz Wie beim direktionalen Geschäftsszenario gibt es zwei Hauptansätze zur Verfeinerung und Weiterentwicklung des Wertmodells rund um IT-Betrieb und Support. Für welchen Ansatz Sie sich entscheiden, hängt davon ab, ob das COM intern oder mit externen Auftragnehmern oder mit ausgelagerten Diensten verwaltet wird: *Verbesserung der internen Teamproduktivität* Wenn der IT-Betrieb und der Support intern verwaltet werden, liegt der Schwerpunkt des Geschäftsszenarios auf folgenden Aspekten: + Identifizierung und Quantifizierung der Produktivitätssteigerungen durch die Migration und jegliche betriebliche Automatisierung, die im Leistungsumfang enthalten ist + Überprüfung, ob die für das interne Team freiwerdende Zeit problemlos und produktiv für andere typischerweise wertvollere Aktivitäten genutzt werden kann, was dem Team Aufstiegschancen und eine höhere Entlohnung und der Organisation mehr Nutzen bietet Beurteilen Sie, wie viel Zeit jedes Mitglied in jeder Rolle innerhalb des Teams für seine verschiedenen regulären Aktivitäten aufwendet, und geben Sie Hinweise zur erwarteten Verringerung der Arbeitsbelastung für verschiedene Aktivitäten. Die folgende Tabelle enthält erste Hinweise zu den typischen Stufen der Arbeitslastreduzierung nach Aktivitäten für Aufgaben, die den Großteil des IT-Betriebs und des Supports in den verschiedenen Rollen im Team in Anspruch nehmen. Die Tabelle enthält eine Beschreibung, wie die Produktivität erreicht wird. **Anmerkung** Die aufgeführten Aktivitäten werden in der Regel von Teammitgliedern in verschiedenen Rollen ausgeführt. Daher sollten die Produktivitätseinsparungen bei jeder Aufgabe für alle Rollen im Team bewertet werden. In IT-Betriebsteams, die nach Infrastruktur-Tower (z. B. Datenverarbeitung, Speicher und Netzwerk) organisiert sind, können beispielsweise die Planung und Budgetierung der Investitionsausgaben für jeden Tower üblich sein. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html) Die folgende Tabelle zeigt die erwarteten Einsparungen für jede Stufe der Arbeitslastreduzierung. | **Stufe** | **Erwartet** | | --- | --- | | Very high (Sehr hoch) | 85% — 100% | | Hoch | 60 — 90% | | Mittel | 30 bis 70% | | Niedrig | 10 bis 35% | | Minimal | 0%-10% | Diese Kennzahlen bieten einen Ausgangspunkt für die Bewertung der Produktivitätssteigerungen und deren Einbeziehung in das detaillierte Geschäftsszenario. Die tatsächlichen Produktivitätssteigerungen variieren je nach Situation. Es kann nützlich sein, die Produktivitätseinsparungen sowohl in der Mitte als auch am unteren Ende der Spanne zu berechnen, um typische und konservative Szenarien abzuschätzen. Im weiteren Verlauf des Programms ist es hilfreich, aktuelle Daten für die für die einzelnen Aktivitäten aufgewendete Zeit nach Rollen zu erfassen. Diese Daten bilden eine bessere Grundlage für die Schätzung von Betriebsabläufen und unterstützen die Kosten für neue Projekte und Serviceerweiterungen. *Ausgelagerter IT-Betrieb und Senkung der Supportkosten* [Wenn IT-Betrieb und Support in erster Linie ausgelagert oder von Auftragnehmern verwaltet werden, kann die Kostenverteilung für das future Betriebsmodell (FOM) vorbereitet werden, indem Angebote von Partnern angefordert werden, die Managed-Service-Lösungen anbieten, einschließlich von AWS Partnern geführter Lösungen ( AWS AMS AWS Managed Services ).](https://aws.amazon.com/managed-services/partners/) Sie können sich auch an Ihren AWS Kundenbetreuer wenden und direkt einen Preis für AMS anfragen, wie im Unterabschnitt „Integration der [Betriebskostenoptimierung“ im](directional-business-case.md#building-operational-cost-optimization) Abschnitt „[Erstellung eines](directional-business-case.md) zielgerichteten Geschäftsszenarios“ beschrieben. Für ein detailliertes Geschäftsszenario sollten Sie alle Referenzwerte durch ein Angebot ersetzen, das auf der überarbeiteten AWS Leistungsliste und dem voraussichtlichen Leistungsverbrauch, dem AMS-Paket und allen benötigten Optionen sowie dem erforderlichen Serviceniveau basiert. Die Kosten werden aus einer einmaligen Implementierungskomponente und einer nutzungsabhängigen Ausführungsrate bestehen. Dazu gehören alle verbleibenden IT-Operationen, der Support, der für alle Services, auf die nicht migriert werden soll, beibehalten werden muss AWS, und einmalige Kosten, falls Vertragsstrafen anfallen (z. B. bei vorzeitiger Kündigung). ## Entwickeln Sie das Wertmodell für Resilienz Mit dieser Option können Sie eine breite Palette von Architekturen mit hoher Verfügbarkeit, Notfallwiederherstellung und Fehlertoleranz aufbauen. AWS Eine verbrauchsabhängige Preisgestaltung bedeutet, dass Dienste nur dann in Rechnung gestellt werden, wenn sie in Anspruch genommen werden. Zusammen sorgen diese beiden Faktoren für ein außergewöhnliches Kosten-Nutzen-Verhältnis und Stabilität. Darüber hinaus haben AWS Kunden dies genutzt, um die Widerstandsfähigkeit ihrer Workloads zu verbessern. Die [IDC-Umfrage von 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) enthält Beispiele für teilnehmende Kunden, die 73 Prozent weniger Ausfälle pro Jahr, eine Verkürzung der mittleren Wiederherstellungszeit (MTTR) um 58 Prozent und eine Reduzierung des Produktivitätsverlusts um 94 Prozent verzeichneten. Dieselbe Umfrage ergab, dass die finanziellen Vorteile, die sich aus der erhöhten Ausfallsicherheit ergeben, um 50 Prozent höher waren als die Kostensenkung für die IT-Infrastruktur. Darüber hinaus wird durch die Modernisierung des Softwareentwicklungszyklus für Anwendungen eine weitere Ausfallsicherheit erreicht. Wenn CI/CD Pipelines mit Testautomatisierung eingeführt werden, um die Flexibilität des Unternehmens zu erhöhen, werden Softwarefehler früher im Entwicklungszyklus erkannt, wodurch die Kosten für die Softwarewartung erheblich gesenkt werden. **Um diesen Wert zu bewerten und in das Geschäftsszenario einzubeziehen, arbeiten Sie zunächst mit den Geschäftsinhabern der Anwendungen zusammen, um sich ein Bild vom *Gesamtnutzenpotenzial* für jeden zu migrierenden Workload zu machen.**Dies kann unter anderem die folgenden Elemente beinhalten: + Anzahl, durchschnittliche Dauer und Art der Betriebsunterbrechungen: + Zu den Dienstunterbrechungen gehören beispielsweise Ausfälle, Leistungseinbußen, Überlaufen von geplanten Batch- und Wartungsfenstern, Fehler in wichtigen Funktionen und Zugriffseinschränkungen in Spitzenzeiten. + Auswirkungen auf den Umsatz durch Unterbrechungen umsatzgenerierender Dienste wie E-Commerce-Systeme: + Die wahrscheinliche Anzahl von Transaktionen, die aufgrund von Serviceunterbrechungen nicht abgeschlossen werden können, basierend auf der Unterbrechungszeit und den Transaktionsraten + Durchschnittswert für jede betroffene Transaktion + Der zusätzliche Zeitaufwand für Support-Techniker bei der Behebung von Fehlern in Produktionssystemen im Vergleich zu den Kosten für deren Entdeckung zu einem früheren Zeitpunkt im Entwicklungsprozess + Auswirkungen auf die Produktivität interner Benutzer und die Kosten für verlorene Zeit Beurteilen Sie anschließend die erwartete und konservativere Reduzierung des Zeitverlusts durch Betriebsunterbrechungen****, der sich aus der erhöhten Ausfallsicherheit ergeben sollte. Erwägen Sie beispielsweise, die folgenden Elemente einzubeziehen: + Reduzierte Anzahl von Ausfällen und MTTR durch Hochverfügbarkeitsarchitekturen und verbesserte Recovery Time Objective (RTO) und Recovery Point Objective (RPO) + Verringerung der Verlangsamung, Beseitigung von Kapazitätsdrosselungen und Vermeidung von Überschreitungen bei der Stapelverarbeitung mithilfe von Funktionen wie automatischer Skalierung + Reduzierung der Anzahl von Anwendungsfehlern, die nur in der Produktion entdeckt werden, durch die Implementierung von CI/CD Pipelines und automatisierte Regressionstests für Infrastrukturen, die auf- und abgeschaltet werden, um die Kosten zu minimieren Stellen Sie diese zusammen, um das Portfolio der zu migrierenden und zu modernisierenden Anwendungen zusammenzustellen, und berechnen Sie den erwarteten und konservativeren Geschäftswert für jedes einzelne Jahr. Die Vorteile sollten im Einklang mit dem Migrationsplan steigen und dann im Umfang entsprechend den Erwartungen der beteiligten Anwendungen an das Nutzungswachstum angepasst werden. ## Entwickeln Sie das Wertmodell für geschäftliche Agilität Geschäftliche Agilität ist der Hauptgrund für die Migration von AWS Kunden AWS. Die [AWS IDC-Kundenumfrage 2018 ergab](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770), dass die Vorteile der Geschäftsflexibilität 47 Prozent der gesamten gemessenen Vorteile und mehr als das Fünffache der Vorteile, die sich aus der Senkung der Infrastrukturkosten ergeben, ausmachten. Es ist eine Herausforderung, alle Vorteile der Geschäftsflexibilität, die sich aus einer Transformation ergeben, genau vorherzusagen. Wenn Sie sich jedoch auf Anwendungen konzentrieren, die eine große Anzahl von Benutzern unterstützen oder Quellen der Geschäftsdifferenzierung sind, können Sie diesen Vorteil modellieren und einen wesentlichen Teil dieses Vorteils in den detaillierten Geschäftsszenario einbeziehen. Mit fortschreitender Migration sollten Sie das Wertmodell für geschäftliche Agilität schrittweise verfeinern und erweitern, je mehr Vorteile quantifizierbar werden. Dadurch bleibt der Geschäftsszenario relevant, sodass er als primäres Instrument zur Entscheidungsunterstützung zur Steuerung des Programms verwendet werden kann. Verwenden Sie die folgenden Leitlinien, um das Wertmodell für geschäftliche Agilität zu entwickeln: + Wählen Sie die Workloads aus, mit denen die größte Verbesserung der Unternehmensleistung erzielt werden kann, z. B.: + Umsatzgenerierende Workloads + Workloads für den Geschäftsbetrieb mit Möglichkeiten zur Steigerung der Effizienz und zur Senkung der Geschäftskosten + Produktivitätstools für Unternehmen, die eine große Benutzerbasis unterstützen + Gehen Sie wie folgt vor, um Umsatz und Effizienz zu generieren: + Machen Sie eine realistische und konservativere Einschätzung des Umsatzwachstums oder der betrieblichen Effizienz, die mit größeren und kleineren Anwendungs-Upgrades zu rechnen sind. + Schätzen Sie die steigende Anzahl von Haupt- und Nebenversionen pro Jahr ein, was die AWS Geschwindigkeit der Anwendungsentwicklung und die Verkürzung der Infrastrukturbereitstellungszeit ermöglicht. Einige grundlegende Kennzahlen hierfür sind im IDC-Bericht enthalten. + Berechnen Sie die realistischen und konservativeren Nutzenerwartungen. Ordnen Sie sie dem Zeitraum des Geschäftsszenarios zu und berücksichtigen Sie dabei, dass die volle Effizienz einige Zeit nach der Migration der jeweiligen Workloads erreicht wird. + Gehen Sie für Produktivitätstools für Unternehmen wie folgt vor: + Machen Sie eine realistische und konservativere Einschätzung der Zeitersparnis, die mit größeren und kleineren Anwendungs-Upgrades zu rechnen ist. + Schätzen Sie die durchschnittlichen Zeit- und Arbeitskosten aller betroffenen Benutzer ab. + Verwenden Sie die Zahlen für die Erhöhung der Häufigkeit von Haupt- und Nebenveröffentlichungen und berechnen Sie die Vorteile für die Laufzeit des Geschäftsszenarios. Da die höhere Produktivität der Entwickler und die kürzere Zeit bis zur Markteinführung keine zusätzlichen Ressourcen erfordern, fügen Sie die Nettoleistungslinien für jede Arbeitslast in das Cashflow-Modell für den Geschäftsszenario ein, um sie in die Berechnungen des diskontierten Cashflows, des Kapitalwerts, des ROI, des MIRR und der Amortisation einzubeziehen.