Überprüfen und Vergleichen gängiger Cloudbetriebsmodelle

Artikel
03/22/2023

Betriebsmodelle sind basierend auf aktuellen Anforderungen und Einschränkungen einzigartig und spezifisch für das Unternehmen, das sie jeweils unterstützen. Betriebsmodelle sind jedoch keine Schneeflocken. Bei Kundenbetriebsmodellen gibt es mehrere gängige Muster. In diesem Artikel werden die vier gängigsten Muster beschrieben.

Vergleich der Betriebsmodelle

Auf der folgenden Abbildung sind gängige Betriebsmodelle basierend auf ihrer Komplexität angeordnet. Die Anordnung erfolgt von niedrigster Komplexität (dezentralisiert) zu höchster Komplexität (globale betriebliche Abläufe). In den folgenden Tabellen werden die gleichen Betriebsmodelle basierend auf dem relativen Wert einiger weiterer Attribute verglichen.

Diagramm, das die Komplexitätsgrade des Betriebsmodells zeigt.

Prioritäten oder Umfang

Ein Cloudbetriebsmodell wird hauptsächlich von zwei Faktoren beeinflusst:

Strategische Prioritäten oder Motivationen
Umfang des zu verwaltenden Portfolios

	Dezentralisierte betriebliche Abläufe (ops)	Zentralisierte betriebliche Abläufe (ops)	Betriebliche Abläufe (ops) auf Unternehmensebene	Verteilte betriebliche Abläufe (ops)
Strategische Prioritäten oder Motivationen	Innovation	Control	Demokratisierung	Integration
Umfang des Portfolios	Workload	Zielzone	Cloudplattform	Vollständiges Portfolio
Workloadumgebung	Hohe Komplexität	Niedrige Komplexität	Mittlere Komplexität	Mittlere oder variable Komplexität
Zielzone	–	Hohe Komplexität	Mittlere bis niedrige Komplexität	Niedrige Komplexität
Grundlegende Hilfsprogramme	–	Nicht verfügbar oder geringe Unterstützung	Zentralisiert und höhere Unterstützung	Höchste Unterstützung
Cloudgrundlagen	–	–	Hybrid, anbieterspezifisch oder regionale Grundlagen	Verteilt und synchronisiert

Strategische Prioritäten oder Motivationen: Jedes Betriebsmodell liefert die typischen Strategische Motivationen für die Einführung der Cloud. Einige Betriebsmodelle vereinfachen jedoch bestimmte Motivationen.
Umfang des Portfolios: Der Portfolioumfang identifiziert den größten Umfang, den ein bestimmtes Betriebsmodelldesign unterstützt. Zentralisierte Vorgänge sind beispielsweise für einige Zielzonen konzipiert. Die Entscheidung über das Betriebsmodell kann jedoch zu Betriebsrisiken für eine Organisation führen. Operationelle Risiken entstehen, wenn versucht wird, ein großes komplexes Portfolio zu verwalten. Diese Portfolios erfordern möglicherweise viele Landing Zones oder eine variable Komplexität im Design der Landing Zone.

Wichtig

Die Einführung der Cloud löst oft eine Reflexion über das aktuelle Betriebsmodell aus und kann zu einem Wechsel von einem gemeinsamen Betriebsmodell zu einem anderen führen. Die Cloudeinführung ist jedoch nicht der einzige Auslöser. Geschäftsprioritäten und der Umfang einer Cloudeinführung können Einfluss darauf haben, wie das Portfolio unterstützt werden muss. Und auch bei einem optimal ausgerichteten Betriebsmodell kann es zu Veränderungen kommen. Wenn der Vorstand oder andere Mitglieder der Führungsebene Geschäftspläne für die nächsten fünf bis zehn Jahre entwickeln, ist in diesen oftmals die Anforderung enthalten (explizit oder impliziert), dass das Betriebsmodell angepasst werden muss. Betriebsmodelle sind eine gute Referenz für die Entscheidungsfindung. Diese Modelle können sich ändern oder müssen an Ihre Anforderungen und Einschränkungen angepasst werden.

Ausrichtung der Verantwortlichkeiten

Viele Teams und Einzelpersonen sind für die Unterstützung verschiedener Funktionen verantwortlich. Aber jedes gängige Betriebsmodell weist die endgültige Verantwortung für die Entscheidungsergebnisse einem Team oder einer Einzelperson zu. Dieser Ansatz beeinflusst die Art, wie ein Betriebsmodell gefördert wird und in welchem Umfang den einzelnen Funktionen Unterstützung zukommt.

	Dezentralisierte betriebliche Abläufe	Zentralisierte betriebliche Abläufe	Betriebliche Abläufe auf Unternehmensebene	Verteilte betriebliche Abläufe
Geschäftliche Ausrichtung	Workloadteam	Zentrale Cloudstrategie	CCoE	Variabel – allgemeines Cloudstrategieteam bilden?
Cloudbetrieb	Workloadteam	Zentrale IT-Abteilung	CCoE	Basierend auf einer Portfolioanalyse – weitere Informationen finden Sie unter Erstellen der Geschäftsausrichtung in der Cloudverwaltung und Die geschäftliche Verpflichtung in der Cloudverwaltung
Cloud Governance	Workloadteam	Zentrale IT-Abteilung	CCoE	Mehrere Governance-Ebenen
Cloudsicherheit	Workloadteam	Security Operations Center (SOC)	CCoE + SOC	Gemischt – weitere Informationen finden Sie unter Definieren einer Sicherheitsstrategie
Cloudautomatisierung und DevOps	Workloadteam	Zentrales IT-Team oder nicht verfügbar	CCoE	Basierend auf einer Portfolioanalyse – weitere Informationen finden Sie unter Erstellen der Geschäftsausrichtung in der Cloudverwaltung und Die geschäftliche Verpflichtung in der Cloudverwaltung

Beschleunigen der Implementierung von Betriebsmodellen in Azure

Wie im Artikel Definieren Ihres Cloudbetriebsmodells erläutert, stellt jede Methodik des Cloud Adoption Framework einen strukturierten Pfad für die Entwicklung Ihres Betriebsmodells bereit. Diese Methodiken können Ihnen dabei helfen, Hindernisse zu überwinden, die auf Lücken bei der Einführung des Cloudbetriebsmodells zurückzuführen sind.

Die folgende Tabelle enthält Möglichkeiten zur Beschleunigung Ihrer Betriebsmodellimplementierung:

	Dezentralisierte betriebliche Abläufe	Zentralisierte betriebliche Abläufe	Betriebliche Abläufe auf Unternehmensebene	Verteilte betriebliche Abläufe
Startpunkt	Microsoft Azure Well-Architected Framework	Azure-Zielzonen: Implementierungsoptionen für Zielzonen	Azure-Zielzonen: Implementieren von Cloud Adoption Framework-Zielzonen auf Unternehmensebene in Azure	Geschäftliche Ausrichtung
Iterationen	Ein Fokus auf Workloads ermöglicht es dem Team, innerhalb der WAF zu iterieren.	Bei der Option für einen einfachen Start sind mehr Iterationen für die einzelnen Methodiken erforderlich. Diese können jedoch durchgeführt werden, wenn die Cloudeinführung weiter vorangeschritten ist.	Wie durch die Referenzimplementierungen ersichtlich wird, liegt der Fokus zukünftiger Iterationen in der Regel auf kleineren Konfigurationszusätzen.	Sehen Sie sich den Artikel Implementierungsoptionen für Zielzonen an, um mit der Option zu beginnen, die den Grundlagen Ihrer betrieblichen Abläufe am besten entspricht. Befolgen Sie den Iterationspfad, der in den Entwurfsprinzipien der entsprechenden Option definiert ist.

Dezentralisierte Vorgänge

Betriebliche Abläufe sind immer komplex. Wenn Sie den Umfang Ihrer Vorgänge auf eine Workload oder eine kleine Sammlung von Workloads beschränken, kontrollieren Sie die Komplexität. Von den gängigen Betriebsmodellen weisen dezentralisierte betriebliche Abläufe die geringste Komplexität auf. Bei dieser Form des Betriebs werden alle Workloads unabhängig von dedizierten Workload-Teams ausgeführt.

Prioritäten: Ihr Team misst Innovation über zentralisierte Kontrolle oder Standardisierung über mehrere Workloads hinweg.
Eindeutiger Vorteil: Maximieren Sie die Innovationsgeschwindigkeit, indem Sie Workload- und Geschäftsteams uneingeschränkte Kontrolle über Entwurf, Erstellung und betriebliche Abläufe geben.
Eindeutiger Nachteil: Bei der workloadübergreifenden Standardisierung, bei Skaleneffekten über gemeinsam genutzte Dienste und bei einer konsistenten Governance für eine zentralisierte Compliance müssen Einbußen gemacht werden.
Risiko: Dieser Ansatz kann Risiken einführen, wenn ein Workloadportfolio verwaltet wird. Workloadteams verfügen möglicherweise über spezielle Teams für zentrale IT-Funktionen. Dieses Betriebsmodell wird von einigen Organisationen als Option mit hohem Risiko betrachtet – insbesondere von Unternehmen, die Complianceanforderungen von Drittanbietern erfüllen müssen.
Leitfaden: Dezentrale Operationen sind auf Entscheidungen auf Workload-Ebene beschränkt. Microsoft Azure Well-Architected Framework unterstützt die in diesem Bereich getroffenen Entscheidungen. Die Prozesse und Anleitungen innerhalb des Cloud Adoption Framework sind ggf. mit zusätzlichem Aufwand verbunden, der für dezentralisierte betriebliche Abläufe nicht erforderlich ist.

Vorteile dezentralisierter betrieblicher Abläufe

Kostenverwaltung: Die Betriebskosten lassen sich leicht einer einzelnen Geschäftseinheit zuordnen. Workload-spezifische Operationen unterstützen eine bessere Workload-Optimierung.
Zuständigkeiten: In der Regel ist diese Art betrieblicher Abläufe stark von einer Automatisierung abhängig, um den Aufwand zu minimieren. Der Fokus der Zuständigkeiten liegt hierbei tendenziell auf DevOps und Pipelines für die Releaseverwaltung. Diese Art von Vorgängen unterstützt schnellere Bereitstellungen und kürzere Feedbackzyklen während der Entwicklung.
Standardisierung: Verwenden Sie einen Quellcode und eine Bereitstellungspipeline, um die Umgebung von Release zu Release zu standardisieren.
Support für betriebliche Abläufe: Bei Entscheidungen, die sich auf betriebliche Abläufe auswirken, geht es nur um die Anforderungen der entsprechenden Workload und um die Vereinfachung von Entscheidungen über betriebliche Abläufe. Mitglieder der DevOps-Community sagen, dass es sich beim Support für betriebliche Abläufe aufgrund des engeren Umfangs um die reinste Form von betrieblichen Abläufen handelt.
Erfahrung: DevOps- und Entwicklungsteams erhalten die meisten Vorteile durch diesen Ansatz und werden durch Marktänderungen am wenigsten beeinflusst.
Zielzonenaufbau: Kein spezifischer betrieblicher Vorteil.
Grundlegende Hilfsprogramme: Kein spezifischer betrieblicher Vorteil.
Aufgabentrennung: Kein spezifischer betrieblicher Vorteil.

Nachteile dezentralisierter betrieblicher Abläufe

Kostenverwaltung: Unternehmenskosten lassen sich schwieriger berechnen. Das Fehlen von Teams für zentralisierte Governance erschwert die Implementierung einheitlicher Kostenkontrollen oder -optimierungen. Bei hoher Skalierung kann dieses Modell kostspielig werden, da es bei den einzelnen Workloads unter Umständen zu Duplizierungen bei bereitgestellten Ressourcen und Personalzuweisungen kommt.
Zuständigkeiten: Fehlender zentralisierter Support bedeutet, dass das Workloadteam vollständig für Governance, Sicherheit, betriebliche Abläufe und Change Management verantwortlich ist. Der Mangel an Unterstützung ist problematisch, wenn diese Aufgaben in Codeüberprüfungs- und Release-Pipelines nicht automatisiert wurden.
Standardisierung: Die Standardisierung für ein gesamtes Workloadportfolio ist variabel und inkonsistent.
Support für betriebliche Abläufe: Skaleneffekte werden bei der Erstellung bewährter Methoden für mehrere Workloads häufig übersehen.
Erfahrung: Teammitglieder haben eine größere Verantwortung, beim Anwendungsentwurf und bei der Konfiguration kluge und ethische Entscheidungen zu den Themen Governance, Sicherheit, betriebliche Abläufe und Change Management zu treffen. Microsoft Azure Well-Architected Review und Microsoft Azure Well-Architected Framework sollten häufig zu Rate gezogen werden, um die erforderlichen Kenntnisse zu verbessern.
Zielzonenentwurf: Zielzonen sind nicht workloadspezifisch und werden bei diesem Ansatz nicht berücksichtigt.
Grundlegende Hilfsprogramme: Wenige grundlegende Dienste werden für mehrere Workloads gemeinsam genutzt (falls überhaupt), was Skaleneffekte reduziert.
Aufgabentrennung: Höhere Anforderungen an DevOps und Entwicklungsteams erhöhen die Nutzung erhöhter Berechtigungen durch diese Teams. Wenn Sie eine Aufgabentrennung benötigen, müssen Sie möglicherweise stark in die DevOps-Reife investieren, um mit diesem Ansatz zu arbeiten.

Zentralisierte betriebliche Abläufe

Bei Umgebungen mit stabilem Zustand muss der Fokus möglicherweise nicht auf die Architektur oder auf bestimmte betriebliche Anforderungen der einzelnen Workloads gerichtet werden. Zentrale betriebliche Abläufe sind tendenziell die Norm für Technologieumgebungen, die hauptsächlich aus Workloads mit stabilem Zustand bestehen. Beispiele für betriebliche Abläufe mit stabilem Zustand sind COTS-Anwendungen (commercial off-the-shelf) und bewährte benutzerdefinierte Anwendungen mit einem langsamen Releaserhythmus. Wenn die Änderungsrate durch regelmäßige Updates und Patches gesteuert wird, ist die Zentralisierung der betrieblichen Abläufe ggf. ein effektives Mittel zur Verwaltung Ihres Portfolios.

Prioritäten: Zu den Prioritäten zählen die zentrale Kontrolle im Gegensatz zu Innovationen sowie die Messung der bereits vorhandenen Betriebsprozesse im Gegensatz zur kulturellen Umstellung auf moderne Cloudvorgänge.
Eindeutiger Vorteil: Zentralisierung führt zu Skaleneffekten, branchenführenden Steuerungsmöglichkeiten und standardisierten betrieblichen Abläufen. Sie funktioniert am besten mit der Cloudumgebung. Für diese Umgebungen sind bestimmte Konfigurationen erforderlich, um Cloudvorgänge in vorhandene betriebliche Abläufe und Prozesse zu integrieren. Die Zentralisierung bietet die meisten Vorteile bei einem Portfolio von wenigen hundert Workloads mit moderater architektonischer Komplexität und moderaten Complianceanforderungen.
Eindeutiger Nachteil: Die Skalierung, um den Anforderungen eines umfangreichen Workloadportfolios gerecht zu werden, kann erheblichen Druck auf zentralisierte Teams ausüben, die betriebliche Entscheidungen für Produktionsworkloads treffen. Wenn erwartet wird, dass technische Ressourcen über 1.000 VMs, Anwendungen oder Datenquellen hinaus skaliert werden, sollten Sie ein Unternehmensmodell in Betracht ziehen, wenn dies innerhalb von 18 bis 24 Monaten der Fall ist.
Risiko: Dieser Ansatz begrenzt die Zentralisierung auf eine kleinere Anzahl an Abonnements (oft ein Produktionsabonnement). Ein späteres Refactoring im Rahmen Ihrer Cloud Journey ist mit einem erheblichen Risiko verbunden und kann zu Problemen mit Ihren Einführungsplänen führen. Konzentrieren Sie sich insbesondere auf Segmentierung, Umgebungsgrenzen, Identitätstools und andere grundlegende Elemente, um Überarbeitungen zu vermeiden.
Leitfaden: Implementierungsoptionen für Azure-Zielzonen, die dem Entwicklungsprinzip „klein beginnen und dann größer werden“ entsprechen, sind ein geeigneter Startpunkt. Sie können diese Optionen verwenden, um die Einführungsbemühungen zu beschleunigen. Um jedoch erfolgreich zu sein, sollten Sie klare Richtlinien festlegen, um die Bemühungen zur frühzeitigen Einführung innerhalb akzeptabler Risikotoleranzen zu lenken. Methodiken für Governance und Verwaltung helfen bei der Erstellung von Prozessen, mit denen betriebliche Abläufe parallel weiterentwickelt werden können. Diese Schritte dienen als Stage Gates, die abgeschlossen werden müssen, bevor im Zuge der weiteren Entwicklung betrieblicher Abläufe höhere Risiken akzeptiert werden.

Vorteile zentralisierter betrieblicher Abläufe

Kostenverwaltung: Eine Zentralisierung gemeinsam genutzter Dienste für viele Workloads kann Skaleneffekte erschaffen und vermeidet duplizierte Aufgaben. Zentrale Teams können schnell Kosteneinsparungen über unternehmensweite Dimensionierungs- und Skalierungsoptimierungen implementieren.
Zuständigkeiten: Zentralisiertes Know-how und Standardisierung führen ggf. zu höherer Stabilität, höherer betrieblicher Leistung und minimalen änderungsbedingten Ausfällen. Dieser Ansatz reduziert den allgemeinen Qualifizierungsdruck auf die arbeitslastorientierten Teams.
Standardisierung: Allgemein sind Standardisierung und Betriebskosten bei einem zentralisierten Modell am geringsten, da weniger duplizierte Systeme oder Tasks vorhanden sind.
Support für betriebliche Abläufe: Die Verringerung der Komplexität und die Zentralisierung von Vorgängen erleichtern kleineren IT-Teams die Unterstützung des Betriebs.
Erfahrung: Durch die Zentralisierung unterstützender Teams können Experten für Sicherheit, Risiko, Governance und Betrieb geschäftskritische Entscheidungen treffen.
Zielzonenentwurf: Die Zentralisierung der IT minimiert die Anzahl von Zielzonen und Abonnements und verringert so die Komplexität. Zielzonenentwürfe imitieren tendenziell frühere Entwürfe von Rechenzentren, was die Übergangszeit minimiert. Im weiteren Verlauf der Einführung können gemeinsam genutzte Ressourcen in ein separates Abonnement oder in eine separate Plattformumgebung verschoben werden.
Grundlegende Hilfsprogramme: Sie übertragen vorhandene Rechenzentrumsdesigns in die Cloud, was zu grundlegenden, gemeinsam genutzten Diensten führt, die On-Premises-Tools und -Vorgänge nachahmen. Wenn es sich bei Ihrem primären Betriebsmodell um lokale betriebliche Abläufe handelt, kann dies ein Vorteil sein. Es gibt jedoch auch gewisse Nachteile. Lokaler Betrieb verkürzt die Übergangszeit, nutzt Skaleneffekte und unterstützt konsistente Betriebsprozesse zwischen lokalen und in der Cloud gehosteten Workloads. Dieser Ansatz kann die kurzfristige Komplexität und den Aufwand reduzieren und es kleineren Teams ermöglichen, den Cloud-Betrieb mit kürzeren Lernkurven zu unterstützen.
Aufgabentrennung: Eine Aufgabenteilung ist essentiell für zentrale betriebliche Abläufe. Die zentrale IT behält die Kontrolle über die Produktionsumgebungen und reduziert den Bedarf an erhöhten Berechtigungen durch andere Teams. Dieser Ansatz reduziert Sicherheitsverletzungen, indem er die Anzahl der Konten mit erhöhten Berechtigungen begrenzt.

Nachteile zentralisierter betrieblicher Abläufe

Kostenverwaltung: Zentrale Teams sind nicht immer ausreichend mit Workloadarchitekturen vertraut, um wirkungsvolle Optimierungen auf Workloadebene vornehmen zu können. Dieser Mangel an Verständnis schränkt die Höhe der Kosteneinsparungen ein, die sich aus gut abgestimmten Workload-Vorgängen ergeben. Mangelndes Verständnis der Workloadarchitektur kann sich auf zentralisierte Kostenoptimierungen auswirken, was wiederum Auswirkungen auf die Leistung, Skalierung und andere Säulen einer gut ausgearbeiteten Workload hat. Bevor Sie unternehmensweite Kostenänderungen auf hochkarätige Workloads anwenden, sollte Ihr zentrales IT-Team die Microsoft Azure Well-Architected Review verstehen und abschließen.
Zuständigkeiten: Die Zentralisierung des Produktionssupports und des Zugriffs ist mit einer hohen betrieblichen Auslastung einiger weniger Personen verbunden und erhöht den Druck auf jeden Einzelnen. Aufgrund der Belastung der einzelnen Personen muss die Arbeitsauslastung sorgfältiger geprüft werden, um die Erfüllung detaillierter Sicherheits-, Governance- und Complianceanforderungen zu gewährleisten.
Standardisierung: Ein zentrales IT-Team erschwert es, die Standardisierung ohne eine lineare Skalierung der Mitglieder des zentralen IT-Teams zu skalieren.
Support für betriebliche Abläufe: Die größten Nachteile dieses Ansatzes hängen mit der erheblichen Skalierung und wesentlichen Änderungen zur Messung der Innovation zusammen.
Erfahrung: In dieser Art von Umgebung besteht das Risiko, dass Entwickler und DevOps-Experten unterschätzt werden oder zu vielen Beschränkungen unterliegen.
Zielzonenaufbau: Rechenzentrumsentwürfe basieren auf Einschränkungen vorheriger Ansätze, die nicht immer eine Rolle für die Cloud spielen müssen. Bei diesem Ansatz gibt es weniger Gelegenheiten, die Umgebungsaufteilung zu überdenken und Innovationsmöglichkeiten zu nutzen. Das Fehlen einer Landing-Zone-Segmentierung erhöht die potenziellen Auswirkungen von Sicherheitsverletzungen, die Komplexität der Governance und die Einhaltung von Vorschriften und kann Hindernisse für die Einführung in die Cloud schaffen. Sehen Sie sich dazu den Abschnitt zu Risiken oben an.
Grundlegende Hilfsprogramme: Während einer digitalen Transformation ist die Cloud möglicherweise das primäre Betriebsmodell. Zentrale Tools, die für lokale betriebliche Abläufe entwickelt wurden, reduzieren die Möglichkeiten, betriebliche Abläufe zu modernisieren und die Betriebseffizienz zu steigern. Die Entscheidung, betriebliche Abläufe nicht frühzeitig im Einführungsprozess zu modernisieren, ist ebenfalls eine Option. Die Modernisierung kann durch die Erstellung eines Plattformgrundlagenabonnements im Zuge der Cloudeinführung erreicht werden. Dieser Aufwand kann ohne Vorausplanung komplex, kostspielig und zeitaufwändig sein.
Aufgabentrennung: Zentrale Operationen folgen im Allgemeinen einem von zwei Wegen, und beide können Innovationen behindern.
- Option 1: Teams außerhalb des zentralen IT-Teams erhalten nur begrenzten Zugriff auf Entwicklungsumgebungen, die die Produktion imitieren. Diese Option verhindert Experimente.
- Option 2: Teams entwickeln und testen in nicht unterstützten Umgebungen. Diese Option hemmt Bereitstellungsprozesse und verlangsamt Integrationstests nach der Bereitstellung.

Betriebliche Abläufe auf Unternehmensebene

Betriebliche Abläufe auf Unternehmensebene sind der gewünschte Zielzustand für alle betrieblichen Abläufe in der Cloud. Betriebliche Abläufe auf Unternehmensebene vereinfachen Entscheidungen und Zuständigkeiten und sorgen so für ein ausgeglichenes Verhältnis zwischen Kontroll- und Innovationsbedarf. Das zentrale IT-Team wird durch ein hilfreicheres CCoE-Team (Cloud Center of Excellence, Cloudkompetenzzentrum) ersetzt, das Workloadteams unterstützt. Das CCoE-Team überträgt Workloadteams die Verantwortung für Entscheidungen, anstatt ihre Aktionen zu kontrollieren oder einzuschränken. Workloadteams erhalten mehr Berechtigungen und mehr Verantwortung, um Innovationen voranzutreiben. Dabei bestehen jedoch exakt definierte „Leitplanken“.

Prioritäten: Priorität hat die Demokratisierung technischer Entscheidungen. Die Demokratisierung technischer Entscheidungen verlagert die früher dem zentralen IT-Team zugeteilte Verantwortung auf Workloadteams. Um diese Verschiebung der Prioritäten zu erreichen, werden Entscheidungen weniger von Überprüfungsprozessen von Menschen abhängig. Dieser Ansatz unterstützt die automatische Überprüfung, Steuerung und Durchsetzung mithilfe von Cloud-nativen Tools.
Eindeutiger Vorteil: Die Segmentierung von Umgebungen und die Aufgabenteilung ermöglicht ein Gleichgewicht zwischen Kontrolle und Innovation. Bei zentralisierten betrieblichen Abläufen werden Workloads verwaltet, die eine höhere Compliance und stabile betriebliche Abläufe erfordern oder größere Sicherheitsrisiken darstellen. Umgekehrt unterstützt dieser Ansatz die Reduzierung der zentralisierten Kontrolle von Workloads und Umgebungen, die mehr Innovation erfordern. Bei größeren Portfolios gibt es ggf. Probleme mit dem Gleichgewicht zwischen Kontrolle und Innovation. Diese Flexibilität erleichtert die Skalierung Tausender Workloads mit geringeren betrieblichen Einbußen.
Eindeutiger Nachteil: Was lokal funktioniert hat, funktioniert möglicherweise nicht gut im Cloud-Betrieb von Unternehmen. Dieser Ansatz an betriebliche Abläufe erfordert Änderungen in vielerlei Hinsicht. Kulturänderungen bei Kontrolle und Verantwortung stellen oftmals die größte Herausforderung dar. Die Implementierung, Weiterentwicklung und Stabilisierung betrieblicher Veränderungen, die auf Kulturänderungen folgen, erfordern Zeit und Engagement. Architekturänderungen sind ggf. auch bei stabilen Workloads erforderlich. Änderungen bei Tools sind nötig, um die kulturellen, betrieblichen und architektonischen Änderungen voranzutreiben. Für diese Änderungen muss möglicherweise ein primärer Cloudanbieter einbezogen werden. Anpassungsbemühungen vor diesen Änderungen können erhebliche Nacharbeiten erfordern, die über typische Refactoring-Bemühungen hinausgehen.
Risiko: Für diesen Ansatz muss die Führungsebene tätig werden, um die Strategie anzupassen. Außerdem müssen die technischen Teams aktiv werden, um Lernkurven zu bewältigen und die erforderlichen Änderungen umzusetzen. Um langfristige Vorteile zu sehen, ist eine langfristige Zusammenarbeit zwischen Business, CCoE und zentraler IT sowie Workload-Teams erforderlich.
Leitfaden: Azure Landing Zone-Optionen sind als Unternehmensebene definiert. Diese Optionen stellen Referenzimplementierungen bereit, um zu demonstrieren, wie technische Änderungen mit cloudnativen Tools in Azure bereitgestellt werden. Der Ansatz auf Unternehmensebene leitet Teams durch betriebliche und kulturelle Änderungen, die erforderlich sind, um gänzlich von diesen Implementierungen profitieren zu können. Der gleiche Ansatz kann verwendet werden, um die Referenzarchitektur anzupassen und die Umgebung so zu konfigurieren, dass sie Ihrer Einführungsstrategie und Ihren Complianceeinschränkungen entspricht. Wenn Sie unternehmensweit implementieren, können die Methoden Governance und Verwaltung bei der Definition von Prozessen helfen. Diese Prozesse können Ihre Compliance- und Betriebsfunktionen erweitern, um Ihre betrieblichen Anforderungen zu erfüllen.

Vorteile von betrieblichen Abläufe auf Unternehmensebene

Kostenverwaltung: Zentrale Teams arbeiten an Optimierungen für das gesamte Portfolio. Einzelne Teams sind dabei für tiefergreifende Workloadoptimierungen verantwortlich. Workload-fokussierte Teams werden in die Lage versetzt, Entscheidungen zu treffen und Klarheit zu schaffen, wenn diese Entscheidungen negative Auswirkungen auf die Kosten haben. Zentrale Teams und Workloadteams sind gemeinsam für Kostenentscheidungen auf entsprechender Ebene verantwortlich.
Zuständigkeiten: Zentrale Teams verwenden cloudnative Tools, um Schutzmaßnahmen zu definieren, zu erzwingen und zu automatisieren. Die Arbeit von Workloadteams wird durch CCoE-Automatisierung und entsprechende Methoden beschleunigt. Workloadteams können innerhalb des definierten Spielraums Innovationen vorantreiben und Entscheidungen treffen.
Standardisierung: Zentralisierte Schutzmaßnahmen und grundlegende Dienste sorgen für Konsistenz in allen Umgebungen.
Support für betriebliche Abläufe: Workloads, für die Unterstützung für zentralisierte betriebliche Abläufe erforderlich ist, werden in Umgebungen mit stabilen Steuerungsoptionen unterteilt. Die Segmentierung und die Aufgabenteilung motivieren Workloadteams, die Verantwortung für die betriebliche Unterstützung ihrer eignen dedizierten Umgebungen zu übernehmen. Automatisierte cloudnative Tools sorgen für eine Mindestgrundlage für betriebliche Abläufe für alle Umgebungen mit Unterstützung zentralisierter betrieblicher Abläufe.
Erfahrung: Die Zentralisierung von Kerndiensten wie Sicherheit, Risiko, Governance und Betrieb gewährleistet angemessenes zentrales Fachwissen. Eindeutige Prozesse und Schutzmaßnahmen sorgen für Klarheit bei Workloadteams und ermöglichen es ihnen, detailliertere Entscheidungen zu treffen. Diese Entscheidungen erweitern den Einfluss der zentralisierten Experten, ohne dass das Personal linear mit der Technologie skaliert werden muss.
Zielzonenentwurf: Der Zielzonenentwurf spiegelt die Anforderungen des Portfolios wider und sorgt für eine klare Abgrenzung in den Bereichen Sicherheit, Governance und Verantwortlichkeit. Diese Abgrenzungen sind erforderlich, um Workloads in der Cloud nutzen zu können. Es ist unwahrscheinlich, dass bei der Segmentierung die Einschränkungen wiedergespiegelt werden, die von bisherigen Rechenzentrumsentwürfen geschaffen wurden. Bei betrieblichen Abläufen auf Unternehmensebene ist der Zielzonenentwurf weniger komplex, ermöglicht eine schnellere Skalierung und senkt die Hürden für Self-Service-Nachfrage.
Grundlegende Hilfsprogramme: Grundlegende Hilfsprogramme werden in separaten zentral gesteuerten Abonnements gehostet, die auch als Plattformumgebung bezeichnet werden. Zentrale Tools werden dann als Versorgungsdienste in jede Landezone geleitet. Die Trennung der grundlegenden Hilfsprogramme von den Zielzonen maximiert Konsistenz und Skaleneffekte. Diese Hilfsprogramme sorgen außerdem für eine klare Unterscheidung zwischen zentral verwalteten Zuständigkeiten und Zuständigkeiten auf Workloadebene.
Aufgabentrennung: Eine klare Aufgabentrennung zwischen grundlegenden Hilfsprogrammen und Zielzonen ist einer der größten Vorteile des Ansatzes für betriebliche Abläufe. Cloud-native Tools und Prozesse unterstützen den Zugriff und ein angemessenes Kontrollgleichgewicht zwischen zentralisierten Teams und Workload-Teams. Dieser Ansatz basiert auf den Anforderungen einzelner Zielzonen und den Workloads, die in Zielzonensegmenten gehostet werden.

Nachteile von betrieblichen Abläufen auf Unternehmensebene

Kostenverwaltung: Zentrale Teams sind stärker davon abhängig, dass Workloadteams Produktionsänderungen in den Zielzonen vornehmen. Dadurch besteht die Gefahr möglicher Budgetüberschreitungen und einer langsameren richtigen Dimensionierung der tatsächlichen Ausgaben. Prozesse für die Kostenkontrolle, klare Budgets und automatisierte Steuerungsmechanismen sowie regelmäßige Überprüfungen müssen frühzeitig implementiert werden, um Kostenüberraschungen zu vermeiden.
Zuständigkeiten: Bei betrieblichen Abläufen auf Unternehmensebene müssen höhere kulturelle und betriebliche Anforderungen erfüllt werden. Diese Anforderungen sorgen für Klarheit bei den Zuständigkeiten und bei der Verantwortung zwischen zentralen Teams und Workloadteams.
Herkömmliche Change Management-Prozesse oder Change Advisory Boards (CABs) bieten möglicherweise nicht die nötige Geschwindigkeit und Balance für dieses Betriebsmodell. Diese Prozesse spiegeln sich in der Automatisierung von Prozessen und Verfahren wider, die die Cloud-Einführung sicher skalieren.
Mangelndes Engagement für Veränderungen manifestiert sich zuerst in Verhandlungen und der Abstimmung von Verantwortlichkeiten. Eine Unfähigkeit, sich an Änderungen der Verantwortungen anzupassen, ist ein Indikator dafür, dass zentrale IT-Betriebsmodelle während kurzfristigen Cloudeinführungsbemühungen erforderlich sein könnten.
Standardisierung: Mangelnde Investitionen in zentralisierte Schutzmaßnahmen oder in Automatisierungen führen zu Risiken für die Standardisierung, was sich mit manuellen Überprüfungsprozessen nicht so leicht überwinden lässt. Betriebliche Abhängigkeiten zwischen Workloads in Zielzonen und freigegebenen Diensten erhöhen das Risiko. Dieses Risiko geht von der Standardisierung im Rahmen von Upgradezyklen oder zukünftigen Versionen der grundlegenden Hilfsprogramme aus. Bei Überarbeitungen der Plattformumgebung sind verbesserte oder sogar automatisierte Tests für alle unterstützten Zielzonen und darin gehosteten Workloads erforderlich.
Support für betriebliche Abläufe: Die durch Automatisierung und zentralisierte Vorgänge bereitgestellte Betriebsbaseline kann für Workloads mit geringer Auswirkung oder geringer Kritikalität ausreichend sein. Für komplexe oder hochkritische Workloads können jedoch Workload-Teams oder andere Formen dedizierter Vorgänge erforderlich sein. Wenn dies der Fall ist, kann dies zu einer Verschiebung der Betriebsbudgets führen, wodurch die Geschäftseinheiten gezwungen werden, Betriebsausgaben für diese Formen fortgeschrittener Betriebsabläufe zu verwenden. Wenn die zentrale IT die alleinige Verantwortung für die Betriebskosten übernehmen muss, kann der Unternehmensbetrieb schwierig zu implementieren sein.
Erfahrung: Die Mitglieder des zentralen IT-Teams müssen möglicherweise Fachwissen zur Automatisierung zentraler Kontrollen entwickeln, die zuvor über manuelle Prozesse bereitgestellt wurden. Darüber hinaus müssen sich diese Teams ggf. mit Infrastructure-as-Code-Ansätzen zum Definieren der Umgebung sowie mit Branches, Zusammenführungen und Bereitstellungspipelines vertraut machen. Ein Plattformautomatisierungsteam benötigt möglicherweise mindestens Entscheidungskompetenzen, um Entscheidungen zu verstehen, die von Cloud-Kompetenzzentren oder zentralen Betriebsteams getroffen werden. Workloadteams müssen unter Umständen zusätzliches Wissen zu Steuerungsmöglichkeiten und Prozessen sammeln, die ihre Entscheidungen stützen.
Zielzonenentwurf: Der Zielzonenentwurf hängt von grundlegenden Hilfsprogrammen ab. Workload-Teams sollten verstehen, was im Design enthalten ist und was nicht enthalten sein darf. Dadurch lassen sich ggf. unnötiger Zusatzaufwand sowie Fehler und Konflikte vermeiden. Um Flexibilität zu schaffen, können Sie Ausnahmeprozesse in Ihre Zielzonenentwürfe einbeziehen.
Grundlegende Hilfsprogramme: Die Zentralisierung grundlegender Dienstprogramme braucht Zeit. Diese Hilfsprogramme berücksichtigen letztendlich Optionen und entwickeln Lösungen, die skaliert werden können, um die Anforderungen verschiedener Einführungspläne zu erfüllen. Verzögerungen bei der frühzeitigen Einführung sind möglich. Verzögerungen können ggf. langfristig durch Beschleunigung und die Vermeidung von Hindernissen im weiteren Verlauf des Prozesses ausgeglichen werden.
Aufgabentrennung: Eine klare Aufgabenteilung erfordert ausgereifte Identitätsverwaltungsprozesse. Mit der richtigen Ausrichtung von Benutzern, Gruppen und Onboarding- und Offboarding-Aktivitäten ist möglicherweise mehr Wartung verbunden. Möglicherweise müssen Sie neue Prozesse einführen, um den Just-in-Time-Zugriff über erhöhte Berechtigungen zu ermöglichen.

Verteilte betriebliche Abläufe

Das vorhandene Betriebsmodell ist möglicherweise zu detailliert für die gesamte Organisation, um zu einem neuen Betriebsmodell wechseln zu können. In anderen Fällen verhindern globale betriebliche Abläufe und verschiedene Complianceanforderungen möglicherweise bestimmte Geschäftseinheiten daran, Änderungen vorzunehmen. In diesem Fall ist möglicherweise ein Ansatz mit verteilten Vorgängen erforderlich. Dieser Ansatz ist bei weitem der komplexeste, da er die Integration eines oder mehrerer der zuvor erwähnten Betriebsmodelle erfordert.

Von diesem Ansatz wird zwar dringend abgeraten, er ist jedoch für einige Organisationen erforderlich. Der Ansatz bezieht sich hauptsächlich auf Organisationen, die eine lose Sammlung unterschiedlicher Geschäftseinheiten, eine vielfältige Basis von Kundensegmenten oder regionale Aktivitäten haben.

Prioritäten: Integrieren Sie mehrere bestehende Betriebsmodelle.
Übergangszustand mit Fokus auf der Umstellung der gesamten Organisation auf eines der zuvor genannten Betriebsmodelle.
Ein langfristigerer Ansatz für betriebliche Abläufe, wenn eine Organisation zu groß oder zu komplex ist, um ein einzelnes Betriebsmodell anzuwenden.
Eindeutiger Vorteil: Integrieren Sie gemeinsame Betriebsmodellelemente aus jeder Geschäftseinheit. Dieser Ansatz schafft ein Mittel, um operative Einheiten in einer Hierarchie zu gruppieren, die ihnen hilft, Operationen mit konsistenten, wiederholbaren Prozessen zu reifen.
Eindeutiger Nachteil: Die Aufrechterhaltung von Konsistenz und Standardisierung für mehrere Betriebsmodelle über einen längeren Zeitraum hinweg ist schwierig. Dieser operative Ansatz erfordert ein tiefes Bewusstsein für das Portfolio und die Funktionsweise verschiedener Segmente des Technologieportfolios.
Risiko: Eine fehlende Bereitschaft zur Übernahme eines primären Betriebsmodells könnte zu Verwirrung in den verschiedenen Teams führen. Verwenden Sie dieses Betriebsmodell, wenn es keine Möglichkeit gibt, sich an einem einzelnen Betriebsmodell auszurichten.
Leitfaden: Beginnen Sie mit einer gründlichen Überprüfung des Portfolios. Verwenden Sie dazu den Ansatz, der im Artikel Erstellen der Geschäftsausrichtung in der Cloudverwaltung beschrieben ist. Versuchen Sie, das Portfolio nach dem Zustandsbetriebsmodell zu gruppieren (dezentralisierte betriebliche Abläufe, zentralisierte betriebliche Abläufe oder betriebliche Abläufe auf Unternehmensebene).
Entwickeln Sie eine Verwaltungsgruppenhierarchie, die die Gruppierungen des Betriebsmodells widerspiegelt. Diese Anordnung umfasst andere Organisationsmuster für Region, Geschäftseinheit oder andere Kriterien, die die Workload-Cluster von den am wenigsten verbreiteten zu den häufigsten Buckets abbilden.
Bewerten Sie die Ausrichtung der Workloads für Betriebsmodelle, um für den Beginn den relevantesten Betriebsmodellcluster zu finden. Orientieren Sie sich bei allen Workloads unter der Knoten- und Verwaltungsgruppenhierarchie an dem Leitfaden, der dem Betriebsmodell zugeordnet ist.
Verwenden Sie Govern- und Manage-Methoden, um gemeinsame Unternehmensrichtlinien zu finden, einschließlich erforderlicher operativer Managementpraktiken an verschiedenen Stellen der Hierarchie. Verwenden Sie gängige Azure-Richtlinien, um die freigegebenen Unternehmensrichtlinien zu automatisieren.
Versuchen Sie beim Testen von Azure-Richtlinien mit verschiedenen Bereitstellungen, sie in der Verwaltungsgruppenhierarchie nach oben zu verschieben. Die Richtlinien können auf zahlreiche Workloads angewendet werden. Dadurch lassen sich ggf. Gemeinsamkeiten und spezielle Anforderungen für betriebliche Abläufe ermitteln.
Dieser Ansatz hilft Ihnen möglicherweise dabei, nach und nach ein Modell zu definieren, das für verschiedene Betriebsmodelle skaliert werden kann. Außerdem werden bei diesem Ansatz ggf. auch Teams durch eine Reihe gemeinsamer Richtlinien und Verfahren vereinheitlicht.

Die Vorteile bzw. Nachteile dieses Ansatzes wurden hier bewusst nicht aufgeführt. Nachdem Sie die geschäftliche Ausrichtung Ihres Portfolios abgeschlossen haben, sehen Sie sich den Hauptabschnitt zu Betriebsmodellen oben an, um weitere Informationen zu Vor- und Nachteilen zu erhalten.

Nächste Schritte

Enthält eine Beschreibung der Terminologie für Betriebsmodelle. Anhand der Terminologie können Sie besser verstehen, wie ein Betriebsmodell zur übergeordneten Unternehmensplanung passt.

Terminologie für Betriebsmodelle

Hier finden Sie Informationen zu Landezonen – den Grundbausteinen jeder Cloudeinführungsumgebung.

Was ist eine Zielzone?