IT-Betriebsmodelle in der Cloud – Eine Frage der Verantwortung

Wenn Unternehmen den Einsatz von Public Cloud Services erwägen, ist es besonders wichtig, das dahinterstehende Verantwortungs- und Betriebsmodell zu verstehen und umzusetzen. Im Fokus stehen dabei Fragen nach Sicherheit und Compliance sowie danach, welche Aufgaben durch das Unternehmen selbst oder gegebenenfalls vom Public Cloud Provider umgesetzt werden.

Die Verantwortlichkeiten für die Workloads variieren in Abhängigkeit davon, ob die Workloads als SaaS (Software-as-a-Service), auf PaaS (Platform-as-a-Service), auf IaaS (Infrastructure-as-a-Service) oder On Premises in einem lokalen Rechenzentrum gehostet werden.

So sind Unternehmen, die ihre Workloads in einem lokalen Rechenzentrum hosten für den gesamten Stack selbst zuständig. Bei einem Wechsel in die Cloud wird dagegen ein Teil der Zuständigkeit auf den Cloud-Anbieter übertragen. Im folgenden Diagramm werden die Zuständigkeitsbereiche von Unternehmen und Public Cloud-Providern entsprechend der Art der Bereitstellung von Applikationen veranschaulicht.

Auch wenn die Begriffe auf der Grafik seit Jahrzehnten in der IT-Branche im Einsatz sind, werden sie im Cloud-Kontext grundlegend anders genutzt: So gelten für das Cloud-Betriebsmodell gänzlich andere Paradigmen, die im Folgenden schematisch dargestellt werden.

Um Fragen wie diesen nachgehen zu können, definieren wir hier das Betriebsmodell für die Cloud und stellen den Bezug zum Outsourcing mit einem IT-Dienstleister und dem Zusammenarbeitsmodell her:

•  Ein Cloud-Betriebsmodell bildet die Gesamtheit von Prozessen und Prozeduren ab, die definieren, wie Technologien in der Cloud betrieben werden.

 Als es noch keine Cloud-Technologien gab, haben Technologieteams Betriebsmodelle erstellt, um die Vorteile zu heben, die Technologie für das Unternehmen hat. IT-Betriebsmodelle von Unternehmen waren schon da auf die Geschäftsstrategie, Strukturierung des Personals, Change Management, Betriebsverwaltung, Governance/ Compliance und Sicherheit ausgerichtet. Bei den meisten Betriebsmodellen hatte die Stabilität der Workloads jedoch höchste Priorität.

Die Verlagerung des Betriebsmodells in die Cloud bedeutet nun, dass sich die gleichen Personen und Prozesse auf eine veränderte Betriebsebene konzentrieren können:

• Wenn sich die Mitarbeiter nicht mehr auf die Uptime von Servern konzentrieren, ändern sich die Erfolgsmetriken.
• Wenn die Sicherheit nicht mehr von den vier Wänden eines Rechenzentrums abhängt, ändert sich das Bedrohungsprofil.
• Wenn die Beschaffung kein Innovationshindernis mehr darstellt, ändert sich auch die Geschwindigkeit des Changemanagements.

Das Cloud-Betriebsmodell dient somit deutlich weniger der Stabilität der Workloads, sondern vielmehr dazu, betriebliche Konsistenz zu gewährleisten als auch Geschwindigkeit und Flexibilität im Betrieb zu ermöglichen.

Geschwindigkeit und Flexibilität können insbesondere über das Zusammenarbeitsmodell mit dem IT-Dienstleister positiv beeinflusst werden. Und sobald über ein Zusammenarbeitsmodell gesprochen wird, ist der Outsourcing-Gedanke nicht fern. Wobei Outsourcing im Kontext der Public Cloud jedoch anders verstanden wird als bei klassischen On Premises-Leistungen.

Kontrolle & Stabilität vs. Geschwindigkeit und Ergebnisse

Die Zusammenarbeit mit externen Parteien liegt in der Regel zwischen zwei Polen: Entweder wird jede Tätigkeit an einen Partner herausgegeben oder das Unternehmen führt alle Tätigkeiten selbst durch. Dazwischen gibt es die Möglichkeit, ein Co-Management der IT zu definieren. Unabhängig der Wahl des Zusammenarbeitsmodells ist die Frage zu beantworten, wie viel Kontrolle und Stabilität im Vergleich zu Geschwindigkeit und Ergebnissen das Betriebsmodell ermöglichen soll: So kann durch ein Self-Management eine hohe Flexibilität und Geschwindigkeit erzielt werden, da die Workloads vollständig in der Hand des Kunden liegen. Gleichzeitig kann hierdurch die Stabilität und Kontrolle verloren gehen, die ein sicherer und robuster Betrieb ausmacht. Es handelt es sich bei der Entscheidung schließlich um einen Trade-Off zwischen Control & Stability vs. Speed & Results.

Co-Management mit DevOps und Shared Responsibility

Viele Kunde entscheiden sich bei diesem Trade-Off für ein Co-Management der IT-Landschaften in der Public Cloud.

Während in der Vergangenheit auf Basis des klassischen Outsourcings mittels Standards wie ITIL Gefahrenübergänge und strikte Verantwortlichkeiten definiert wurden, wachsen im DevOps- bzw. Shared Responsibility Modell Unternehmen und Dienstleister zu einer Einheit zusammen, sodass die Übergänge teils nur noch schwer erkennbar sind. Die Idee dabei ist ziemlich simpel: Unternehmen und Dienstleister arbeiten zusammen lösungsorientiert an Störungen, Service Requests oder auch Changes - sprich der Betrieb wird von Unternehmen und Dienstleister gemeinsam umgesetzt.

Insbesondere beim Co-Management können viele Vorteile generiert werden:

• Fokussierung auf Kernkompetenzen und das Kerngeschäft
• Know-how Transfer zwischen dem Dienstleister und Kunden
• Zugang zu neuen Technologien und Innovationen
• Kostenvorteile insb. durch Effizienzsteigerungen
• Weniger Verwaltungsarbeit
• Höhere Kapazitäten
• Höhere Qualität
• Höhere Flexibilität

Im Wesentlichen stellt sich die Frage, für welche Tätigkeiten das Unternehmen selbst, der IT-Dienstleister oder sogar der Hyperscaler verantwortlich sind. Die Fragestellung sollte darüber hinaus betrachten, für welchen Geschäftsbereich und für welche Unternehmensfunktionen ein Unternehmen auf einen IT-Dienstleister ins Boot holt. Konkret muss diese Frage für jede einzelne Applikation beantwortet werden.

Folgende sechs Schritte können dabei helfen:

1. Bewerten Sie, ob die Tätigkeit Bestandteil Ihrer Kernkompetenzen ist
2. Bewerten Sie die Eignung für die Herausgabe der Tätigkeit/en
3. Bewerten Sie die Gründe für die Herausgabe der Tätigkeit/en
4. Bewerten Sie alle relevanten quantitativen Kosten
5. Bewerten Sie alle relevanten qualitativen Kosten
6. Überprüfen Sie die Fähigkeiten der Lieferanten

Nach Überprüfung dieser Punkte kann eine valide Entscheidung für ein passendes Betriebsmodell getroffen werden. Bei der Abgabe von Tätigkeiten an einen Partner können, viele Vorteile aber auch Nachteile generiert werden. Zudem sollte überprüft werden, ob sich über die Zeit das Betriebsmodell verändern kann. Somit muss vor der Bereitstellung der Cloudarchitektur überprüft werden, wie der Cloudbetrieb gestaltet werden soll. Hierbei sollten die Themen strategische Ausrichtung, Personalstruktur und GRC-Anforderungen (Governance, Risiko und Compliance) definiert sein, um das zukünftige Cloud-Betriebsmodell umsetzen zu können und mit Hilfe des umgesetzten Betriebsmodells Kosten zu sparen.