Ausgewogenheit konkurrierender Prioritäten

Der Erfolg jeder digitalen Transformation hängt von der Fähigkeit der Projektbeteiligten aus Unternehmen und Technologie ab, konkurrierende Prioritäten auszugleichen.

Ähnlich wie bei anderen digitalen Transformationen werden auch bei der Cloudeinführung im Laufe des Einführungslebenszyklus konkurrierende Prioritäten ersichtlich. Und wie bei anderen Formen der Transformation hat die Fähigkeit, diese Prioritäten gegeneinander auszugleichen, einen erheblichen Einfluss auf die Realisierung des Geschäftswerts. Diese konkurrierenden Prioritäten gegeneinander auszugleichen, erfordert offene und manchmal schwierige Gespräche zwischen den Projektbeteiligten und manchmal auch mit einzelnen Mitarbeitern.

In diesem Artikel werden einige der konkurrierenden Prioritäten beschrieben, die während der Implementierung der einzelnen Methodiken häufig diskutiert werden. Er kann Ihnen helfen, sich auf diese Diskussionen vorzubereiten, wenn Sie Ihre Cloudeinführungsstrategie entwickeln.

Die folgenden Abschnitte folgen dem oben dargestellten Fluss des Lebenszyklusdiagramm der Cloudeinführung. Es ist jedoch wichtig zu erkennen, dass die Cloudeinführung ein iterativer Prozess ist und kein sequentieller, und dass diese konkurrierenden Prioritäten an verschiedenen Punkten während Ihrer Cloudeinführung wieder auftauchen können.

Das allgemeine Thema des Cloud Adoption Framework-Ansatzes

Monolithische Lösungen und die erweiterte Planung basieren beide auf einer Reihe von Annahmen, die sich im Laufe der Zeit als unzutreffend erweisen können. Die Einführung der Cloud ist häufig eine neue Erfahrung für ein Unternehmen und seine technischen Teams. Wie bei den meisten neuen Erfahrungen gibt es eine gewisse Wahrscheinlichkeit, dass sich diese anfänglichen Annahmen als falsch erwiesen werden.

Das Befolgen bewährter agiler Prinzipien verzögerter technischer Entscheidungen ist der bevorzugte Ansatz für die meisten Leitlinien in diesem Framework. Dieser Ansatz folgt einem konsistenten Muster: Legen Sie einen allgemeinen Endzustand fest, gehen Sie schnell zur ersten Implementierung über, testen und validieren Sie die Annahmen, und gestalten Sie frühzeitig um, um fehlerhafte Annahmen zu korrigieren. Diese Art der wachstumsorientierten Mentalität maximiert das Lernen und minimiert das Risiko für den Geschäftswert, aber es erfordert einen gewissen Komfort bei Mehrdeutigkeiten.

Unklarheiten können manchmal beängstigend oder gefährlicher sein als falsche Annahmen. Obwohl dieses Framework dem Lernen und dem Umgang mit Unklarheiten während der Implementierung Vorrang gibt, erfordern viele Situationen, dass das Team die auf Analysen oder Annahmen basierten Ansätze priorisiert. In den folgenden Abschnitten finden Sie mindestens ein „Beispiel zum erweiterten Umfang“, um zu veranschaulichen, wann eine zweite, tiefere Iteration sinnvoll sein könnte.

Gleichgewicht während der Strategiephase

Das Hauptziel der Methodik „Strategie“ besteht darin, einen Konsens zwischen den Projektbeteiligten zu erreichen. Nachdem die ausgerichtete strategische Position definiert ist, steuert sie das Verhalten in jeder der Methodiken, um sicherzustellen, dass technische Entscheidungen mit den gewünschten Geschäftsergebnissen übereinstimmen. Durch die Förderung der Ausrichtung zwischen den Projektbeteiligten wird ein gemeinsamer Satz konkurrierenden Prioritäten geschaffen: Tiefgreifende Begründung gegenüber Zeit bis zur geschäftlichen Auswirkung.

Konkurrierende Prioritäten:

• Tiefgreifende Begründung: Projektbeteiligte wünschen sich oft eine umfassende Finanzanalyse und eine vollständige geschäftliche Begründung, bevor sie mit der Ausrichtung auf eine strategische Richtung zufrieden sind. Leider könnte eine so gründliche Analyse oft mehr Zeit für Datenerfassung und Datenanalyse beanspruchen.

• Zeit bis zur geschäftlichen Auswirkung: Umgekehrt sind Projektbeteiligte häufig dafür verantwortlich, Geschäftsergebnisse innerhalb eines bestimmten Zeitrahmens zu liefern. Mit der zeitaufwendigen Analyse und Bewertung können diese Ergebnisse gefährdet werden, noch bevor die technische Arbeit beginnt.

Mindestumfang: Um das richtige Gleichgewicht zu finden, müssen die Projektbeteiligten frühzeitig in den Prozess eingebunden werden. Laut der Strategiemethodik empfiehlt es sich, den Umfang der Ausrichtung zu Beginn des Prozesses einzugrenzen. Bei dem vorgeschlagenen Ansatz konzentrieren sich die Beteiligten auf die Ausrichtung auf eine Reihe von Kernmotivationen, messbare Ergebnisse und eine allgemeine geschäftliche Rechtfertigung. Die Projektbeteiligten sollten sich dann schnell auf einige anfängliche Projekte oder Pilotversuche einigen, um erforderliche Lernmöglichkeiten zu fördern.

Beispiel zum erweiterten Umfang: Wenn die anfängliche Geschäftsanalyse auf ein hohes Risiko negativer Auswirkungen auf das Unternehmen hinweist, müssen die Projektbeteiligten möglicherweise innehalten und im Rahmen der geschäftlichen Begründung eine tiefergehende Analyse vorsichtiger bewerten.

Gleichgewicht während der Planungsphase

Wie in der Strategiephase besteht auch in der Planungsphase die Notwendigkeit, ein Gleichgewicht zwischen der Tiefe der anfänglichen Planung und verzögerten technischen Entscheidungen herzustellen.

Konkurrierende Prioritäten:

• Die Tiefe der anfänglichen Planung für die technische Implementierung in der Cloud basiert häufig auf vielen Annahmen. Dies ist insbesondere dann der Fall, wenn es im Team Qualifikationslücken gibt, die Umgebung unter Ermittlungslücken leidet oder die Workloads keine klar definierten architektonischen Endzustände aufweisen. Alle diese Annahmen sind in detaillierten Plänen zur Cloudeinführung üblich. Experimente, Pilotversuche und eine qualitative Analyse sind erforderlich, um diese Annahmen zu überprüfen oder zu verbessern.

• Verzögerte technische Entscheidungen basieren auf der Annahme, dass je später eine technische Entscheidung umso genauer ist, je später sie getroffen wird. Die folgenden Prinzipien der agilen Produktplanung helfen beim Verzögern technischer Entscheidungen, damit sie zum richtigen Zeitpunkt und auf der Grundlage ausreichender Informationen getroffen werden können. Dieser Ansatz führt jedoch zu mehr Unklarheiten im ursprünglichen Plan.

Mindestumfang: Wir empfehlen agile Ansätze zur Produktentwicklung, um ein schnelles Handeln innerhalb überschaubarer Pläne zu ermöglichen. Die Methodik „Planung“ empfiehlt die folgenden Schritte zum Erreichen dieses Gleichgewichts:

1. Inventarisieren Sie mit automatisierten Ermittlungstools den ganzen digitalen Bestand, nutzen Sie jedoch inkrementelle Rationalisierungen, um die Arbeit der nächsten 1 bis 3 Monate zu planen.
2. Die richtige Ausrichtung der Organisation sollte schnell voranschreiten.
3. Erstellen Sie einen Bereitschaftsplan für die Fähigkeiten des zugeteilten Teams. Nutzen Sie die Strategie- und Planvorlage, um schnell einen anfänglichen Backlog bereitzustellen.

Beispiel zum erweiterten Umfang: Manchmal ist die Bereitstellung eines Cloudeinführungsplans eine Reaktion auf ein zeitkritisches Geschäftsereignis oder eines mit hohen Auswirkungen. Wenn für den Erfolg eine große Anzahl von Ressourcen innerhalb eines festgelegten Zeitraums verschoben werden müssen, folgt auf die vorangegangenen Schritte oft eine tiefergehende Planung. Der Schlüssel zum Erfolg in diesen Szenarien liegt darin, genug zu planen, um loszulegen, und dann später das gesamte Engagement zu planen. Dieser Ansatz verringert die Wahrscheinlichkeit, dass die Planung die Geschäftsergebnisse blockiert.

Gleichgewicht während der Bereitschaftsphase

Wenn Teams die ersten Schritte zur Cloudeinführung vorbereiten, bestehen oft konkurrierende Prioritäten zwischen der Zeit bis zur Einführung und dem langfristigen Betrieb. Das Team könnte mit dem Gleichgewicht zwischen guter Eignung für die anstehende Aufgabe und guter Verwaltung zu kämpfen haben. Diese Überlegungen sind in herkömmlichen IT-Umgebungen erforderlich, in denen das Entwickeln einer Plattform physische Ressourcen und Erwerbszyklen erfordert. Wenn jedoch die gesamte IT-Plattform in Code definiert ist, verringern traditionelle Entwicklungstaktiken wie Refactoring die Notwendigkeit, von Anfang an gut verwaltet zu werden.

Konkurrierende Prioritäten:

• Langfristiger Betrieb: Kunden sind oft durch den Wunsch nach einer Cloudumgebung blockiert, welche die gleiche Featureparität wie die aktuellen Systeme für Vorgangsverwaltung, Governance und Sicherheit aufweist. Eine Studie ergab, dass mehr als 90 Prozent der Unternehmen Unterstützung benötigen, um diese Denkweise zu überwinden. Diese Blockade kann zu monatelangen Verzögerungen führen, die den Geschäftserfolg verlangsamen oder verhindern.

• Zeit zur Einführung: Cloudbasierte Tools wie Azure Policy, Continuous Integration und Continuous Delivery (CI/CD)-Ansätze wie Infrastructure-as-Code (IaC) und Verwaltungsgruppen können den Prozess der Umgestaltung auf der gesamten IT-Plattform vereinfachen. Darüber hinaus bieten vordefinierte Zielzonen Empfehlungen, um die Bereitstellung in einer Umgebung zu beschleunigen, die bereits viele der Anforderungen der Featureparität erfüllt. Diese Tools bieten Möglichkeiten, die Markteinführungszeit mit minimalen Auswirkungen auf den langfristigen Betrieb zu beschleunigen.

Mindestumfang: Die Bereitschaftsmethodik beschreibt einen direkten Pfad von der schnellen Einführung zu langfristigen Vorgängen. Dieser Ansatz beginnt mit einer grundlegenden Einführung in die Tools, mit denen Sie Ihre Umgebung umgestalten können. Die Tools berücksichtigen Ihre Anforderungen und leiten Sie zu einer Auswahl vordefinierter Zielzonen, die jeweils mit IaC-Modellen bereitgestellt werden. Anschließend können Sie den Code während der Cloudeinführung umgestalten, um den Betrieb, die Sicherheit und die Verwaltung zu verbessern.

Beispiel zum erweiterten Umfang: Für Teams, deren Einführungsplan ein mittelfristiges Ziel (innerhalb von 24 Monaten) vorsieht, um mehr als 1000 Ressourcen (Anwendungen, Infrastruktur oder Datenobjekte) in der Cloud zu hosten, empfehlen wir eine stabilere Ansicht der Zielzonen. In diesen Fällen sollten Sie bei Ihren ersten Gesprächen die Governance- und Verwaltungsmethodiken für Ihre Zielzone berücksichtigen. Dies führt im Rahmen des Cloudeinführungsplans jedoch oft zu Verzögerungen von Wochen oder Monaten. Um die Auswirkungen auf die Geschäftsergebnisse zu minimieren, sollte das Einführungsteam die tatsächliche Workloads in der Cloud pilotieren und gleichzeitig eine ausgereiftere Zielzone und eine zentrale Architekturlösung schaffen.

Gleichgewicht während der Migrationsphase

Während der Migration gehen die Einführungsteams in der Regel davon aus, dass die Workloads in der Cloud in ihrer aktuellen Konfiguration erneut gehostet werden. Diese Annahme steht im Widerspruch zu einem vorausschauenden Plan, jede Workload neu zu gestalten, um die Vorteile der Cloudfunktionen besser zu nutzen. Die beiden Ansichten schließen sich nicht gegenseitig aus und können sich ergänzen, wenn Sie beide mithilfe eines gemeinsamen Prozesses verwalten.

Konkurrierende Prioritäten:

• Erneutes hosten: Organisationen setzen Migration häufig mit einem Ansatz per Lift & Shift migrieren gleich, bei dem alle Ressourcen in ihrer aktuellen Konfiguration in die Cloud repliziert werden. Dieser Ansatz führt zu geringfügigen Abweichungen im IT-Portfolio. Es ist auch die schnellste Möglichkeit, Ressourcen in einem vorhandenen Rechenzentrum außer Betrieb zu nehmen.

• Neugestaltung: Die Modernisierung der Architektur jeder Workload maximiert den Wert der Cloudeinführung hinsichtlich der Kosten, Leistung und Betrieb. Dieser Ansatz ist jedoch langsamer und erfordert häufig Zugriff auf den Quellcode jeder Anwendung.

Mindestumfang: Verwenden Sie in der Frühphase der Planung die Option für das erneute Hosten, und seien Sie sich dabei bewusst, dass diese Entscheidung auf einer anfänglichen Geschäftsannahme beruht und keine technische Entscheidung ist. Bei der Methodik „Strategie“ stellt das Cloudeinführungsteam dann diese Annahme für jede migrierte Workload in Frage. Diese Methodik folgt dem Ansatz „Bewertung/Migration/Förderung“ für jede Workload oder Workloadgruppe, um eine Migrationsfactory zu bilden. Während der Bewertungsphase evaluiert das Einführungsteam die technische Eignung sowie die Architektur jeder Workload. Diese Bewertungsmaßnahmen führen selten zu einem reinen Lift & Shift-Ansatz, da viele Architekturkomponenten meist zum Zwecke von Refactoring und Modernisierung ausgewählt werden.

Beispiel zum erweiterten Umfang: Bei unternehmenskritischen oder hochsensiblen Workloads, etwa bei einem Mainframe oder einer Microserviceanwendung mit mehreren Ebenen, kann während der Bewertungsphase eine gründlichere Bewertung der Workload erforderlich sein. In diesen Situationen der Neugestaltung sollten Sie die Azure Well-Architected Review und das Azure Well-Architected Framework verwenden, um die Workload-Anforderungen während der Bewertung zu verfeinern.

Gleichgewicht während der Innovationsphase

Echte kundenorientierte Innovationen führen häufig zu konkurrierenden Prioritäten zwischen der Notwendigkeit, einen geplanten Funktionsumfang zu liefern, und der Implementierung eines kundenorientierten Entwicklungsprozesses.

Konkurrierende Prioritäten:

• Funktionsfokus: Anfängliche Innovationspläne bauen auf den vorhandenen digitalen Ressourcen und Cloudfähigkeiten auf, um eine Reihe von Funktionen bereitzustellen, die den Kundenbedürfnissen entsprechen. Man kann leicht zulassen, dass der Plan die technische Umsetzung vorantreibt, was zu einer funktionsorientierten Entwicklung führt. Dieser Ansatz führt oft zu einer vorübergehenden Zufriedenheit der Projektbeteiligten, verringert aber die Wahrscheinlichkeit, dass Innovationen vorangetrieben werden, die das Kundenverhalten beeinflussen.

• Blick auf die Kundenanforderungen: Anfängliche Pläne sind ein wichtiger Bestandteil der geschäftlichen Seite der Entwicklung und sollten in die regelmäßigen Berichte aufgenommen werden. Das Lernen, Messen und Entwickeln mit dem Ziel der Kundenempathie ist jedoch ein genauere Maßstab für den Erfolg von Innovationsbemühungen. Die Konzentration auf den Kunden statt auf die Funktionen führt mit größerer Wahrscheinlichkeit zu kurz- und langfristiger Kundenzufriedenheit und geschäftlichen Auswirkungen.

Mindestumfang: Die Methodik „Innovieren“ veranschaulicht, wie Strategie und Pläne durch einen Konsens über den Geschäftswert integriert werden können. Der Leitfaden stellt dann cloudnative Tools vor, die jede Innovationsdisziplin beschleunigen können, sowie bewährte Methoden für die Implementierung. Der Abschnitt über Prozessverbesserungen schließlich zeigt Ansätze für den Aufbau von Kundenempathie bei gleichzeitiger Berücksichtigung von Plänen und Strategien während der gesamten Journey der Cloudeinführung. Dieser Ansatz konzentriert sich darauf, Innovationen unter Verwendung von so wenig Technologie wie möglich zu erreichen.

Beispiel zum erweiterten Umfang: Manchmal ist eine Innovation abhängig von unternehmenskritischen oder hochsensiblen Workloads. Wenn es sich bei dem Kunden um einen internen Benutzer handelt, könnte der Entwicklungsaufwand während den frühesten Iterationen sowohl unternehmenskritisch als auch hochsensibel sein. In diesen Szenarien sollten die Einführungsteams die Azure Well-Architected Review und das Azure Well-Architected Framework verwenden, um das fortgeschrittene Architekturdesign frühzeitig im Prozess zu bewerten.

Gleichgewicht während der Governancephase

Die Praxis der Cloudgovernance ist ein Gleichgewicht zwischen zwei konkurrierenden Prioritäten: Geschwindigkeit und Agilität gegenüber einer gut verwalteten Umgebung. Durch eine einheitliche Steuerung und minimale Änderungen konzentriert sich das Cloudgovernanceteam auf das Auswerten und Minimieren von Risiken für das Unternehmen. Das Einführungsteam konzentriert sich auf die Förderung von Geschäftsergebnissen, die neue Risiken erfordern und von Natur aus Veränderungen bewirken.

Konkurrierende Prioritäten:

• Angemessene Governance: Jede auf Risikominimierung ausgerichtete Kontrolle blockiert einen Änderungsaspekt oder schränkt die Gestaltungsmöglichkeiten ein. Kontrolle ist für eine angemessen gesteuerte Umgebung unverzichtbar. Wenn Kontrollen jedoch isoliert entwickelt und bereitgestellt werden, können Sie genau so schädlich sein wie die Risiken, die durch sie verhindert werden sollen.
• Geschwindigkeit und Agilität: Geschwindigkeit und Agilität sind in der digitalen Wirtschaft grundlegende Geschäftsanforderungen. Beide erfordern die Fähigkeit, Veränderungen mit minimalen Blockaden für die Innovationen oder die Einführung voranzutreiben. Wenn jedoch der Wandel ohne Governance vorangetrieben wird, entstehen neue Risiken, die dem Unternehmen auf unerwartete Weise schaden können.

Mindestumfang: Die Governancemethodik deutet darauf hin, dass weder Governance noch Einführung isoliert erfolgen sollten. Diese Methodik beginnt mit einem Verständnis der Governance-Fachrichtungen und einem Gespräch über Geschäftsrisiken, Richtlinien und Prozesse. Als aktiver Teilnehmer während der Cloudeinführung kann das Governanceteam ein Minimum an Schutzmaßnahmen implementieren, um die greifbaren Risiken innerhalb des Cloudeinführungsplans zu adressieren. Im Laufe der Zeit kann das Governanceteam diese Schutzmaßnahmen umgestalten und erweitern, um neuen Risiken einzubinden. Dieser Ansatz maximiert den Lerneffekt und Innovationen und minimiert gleichzeitig das Risiko.

Beispiel zum erweiterten Umfang: Wenn das Geschäftsrisiko hoch ist, insbesondere zu Beginn der Einführung, muss das Cloud-Governanceteam möglicherweise die Ausweitung der Governance-Implementierungen beschleunigen. Sie können die gleichen Anleitungen und Übungen verwenden, um diese höhere Governanceebene hinzuzufügen, aber möglicherweise müssen Sie schneller voranschreiten. In einigen Szenarien könnte sogar ein fortgeschrittener Zustand der Governance erforderlich sein, während Sie die ersten Zielzonen entwickeln.

Gleichgewicht während der Verwaltungsphase

Das IT-Geschäftsmodell hinsichtlich der Betriebsverwaltung hat sich im letzten Jahrzehnt kontinuierlich weiterentwickelt. Da sich die Hardwarewartung immer weiter von der Kernkompetenz der IT entfernt, hat sich der Blick auf die Betriebsverwaltung verschoben. Da die IT den Fokus zunehmend auf die Bereitstellung des geschäftlichen Nutzens legt, stehen Betriebsverwaltungsteams in Konflikt mit der Notwendigkeit, ein Gleichgewicht zwischen No-Ops und Low-Ops im Vergleich zu umfassenden Investitionen herzustellen.

Konkurrierende Prioritäten:

• Umfassende Investitionen: Beim traditionellen Ansatz der Betriebsverwaltung wird gleichermaßen in die Vermeidung von Ausfällen, die schnelle Wiederherstellung und die Überwachung der gesamten Umgebung investiert. Dieser Ansatz kann teuer sein und führt manchmal zu einer Verdoppelung der vom Cloudanbieter bereitgestellten unterstützenden Produkte.

• No-Ops und Low-Ops: Nutzen Sie cloudnative Betriebstools, um sich wiederholende und wiederkehrende Aufgaben zu minimieren, die bisher von Ihren Mitarbeiter*innen durchgeführt wurden. Durch das Reduzieren dieser betrieblichen Abhängigkeiten können Mitarbeiter*innen auf andere Weise den Wert steigern. Isoliert betrachtet kann dieser Ansatz jedoch zu einer suboptimalen betrieblichen Unterstützung führen.

Mindestumfang: Laut der Verwaltungsmethodik ist es ratsam, eine cloudnative No-Ops-Baseline einzurichten. Mit dem Wissen, dass die No-Ops-Baseline nicht alle Geschäftsanforderungen erfüllt, müssen Sie mit dem Unternehmen zusammenarbeiten, um Verpflichtungen zu definieren und Investitionen besser aufeinander abzustimmen. Erweitern Sie die Baseline, um allgemeine Anforderungen für alle Workloads zu erfüllen. Anschließend ermöglichen Sie es Plattformteams oder Teams mit spezifischen Workloads, gut verwaltete Lösungen in einer gut verwalteten Umgebung aufrechtzuerhalten.

Beispiel zum erweiterten Umfang: In den meisten Umgebungen rechtfertigt der Geschäftswert eines kleinen Prozentsatzes der Workloads hohe Investitionen der IT in den Betrieb. Für diese Workloads kann das IT-Team die Azure Well-Architected Review und das Azure Well-Architected Framework nutzen, um den Betrieb zu vertiefen.

Gleichgewicht während der Organisationsphase

Die in diesem Artikel beschriebenen konkurrierenden Prioritäten spiegeln das Bestreben der IT wider, die Geschäftsanforderungen hinsichtlich Geschwindigkeit und Agilität zu erfüllen. Die gleiche Verschiebung zeit sich bei Änderungen an Organigrammen oder virtuellen Teamstrukturen, um bessere Unterstützung für Geschäftsergebnisse zu bieten. Wenn IT-Leiter über Teamstrukturen diskutieren, werden häufig zwei konkurrierende Prioritäten angesprochen: zentralisierte Steuerung und delegierte Steuerung.

Konkurrierende Prioritäten:

• Zentralisierte Kontrolle: Dieses Vorgangsmodell konzentriert sich auf die Zentralisierung aller Kontrollen, die zur Durchsetzung starrer Richtlinien erforderlich sind. In diesem Modell stellt die IT ein Hindernis für Innovationen, Geschwindigkeit und Agilität dar. Die IT ist jedoch in der Lage, ein höheres Maß an Stabilität, Compliance und Sicherheit zu gewährleisten.

• Delegierte Kontrolle: In diesem verteilten Vorgangsmodell wird davon ausgegangen, dass jedes DevOps-Team oder Geschäftsanwendungsteam eigene Kontrollen bereitstellt, die auf den Lösungen basieren, die zur Erreichung der Geschäftsziele erforderlich sind. In diesem Modell stellt die IT Anleitungen zur Verfügung, die den Teams helfen, Risiken zu vermeiden, minimiert aber so weit wie möglich die Anzahl erzwungener technischer Einschränkungen.

Mindestumfang: Die meisten Organisationen durchlaufen im Laufe der Zeit eine Reihe von natürlichen Entwicklungen. Die Organisationsmethodik beschreibt die gängigsten Entwicklungen. Wir empfehlen, dass Teams versuchen, zu einer CCoE (Cloud Center of Excellence)-Struktur zu wechseln, um delegierte Kontrollansätze bereitzustellen.

Beispiel zum erweiterten Umfang: Viele Situationen lösen das Bedürfnis nach zentralisierter Kontrolle aus. Complianceanforderungen von Drittanbietern und vorübergehende Sicherheitsrisiken sind zwei Beispiele für die Auslöser einer zentralisierten Steuerung. In solchen Situationen besteht häufig die Notwendigkeit, einschränkende Richtlinien und starre, feste Kontrollen einzuführen. Um jedoch weiterhin Innovationen wie auch Akzeptanz zu ermöglichen, ermutigen wir die zentralen IT-Teams, diese Kontrollen auf der Grundlage der Kritikalität und Sensibilität der einzelnen Workloads durchzuführen. Die Bereitstellung von Umgebungen mit weniger Kontrollen und einem reduzierten Umfang oder Risikoprofil ermöglicht Flexibilität, selbst wenn Kontrollen erforderlich sind.

Nächste Schritte

Erfahren Sie, wie Sie Migration, Innovation und Experimentieren in Einklang bringen, um Ihre Cloudmigration optimal zu nutzen.