Warum ein Rollenmodell?
Abschnitt betitelt „Warum ein Rollenmodell?“Eine Cloud-Transformation scheitert selten an der Technologie. Sie scheitert daran, dass unklar ist, wer was entscheidet, wer informiert werden muss und wer letztendlich die Verantwortung trägt. Das RACI-Modell beantwortet diese Frage für jede der zentralen Aktivitäten im Framework — bevor die Unklarheit zum Hindernis wird.
RACI steht für vier Arten von Verantwortung. Responsible bezeichnet die Person, die eine Aufgabe ausführt oder koordiniert. Accountable ist die Person, die letztendlich die Verantwortung dafür tragen muss — genau eine pro Tätigkeit. Consulted werden Personen, deren Input gesucht wird, bevor eine Entscheidung getroffen wird. Informed sind Personen, die über das Ergebnis informiert werden, ohne aktiv involviert zu sein.
Das Rollenmodell dieses Rahmenwerks ist bewusst funktional, nicht hierarchisch aufgebaut. Ein CIO kann gleichzeitig für die Gesamtstrategie verantwortlich (Accountable) sein und über technische Detailentscheidungen informiert werden. Die Rollen beschreiben Verantwortung, nicht Stellenprofile.
Die acht Rollen
Abschnitt betitelt „Die acht Rollen“CIO — Chief Information Officer
Abschnitt betitelt „CIO — Chief Information Officer“Der CIO ist der Sponsor und letztendliche Entscheidungsträger der Cloud-Transformation. Er verantwortet die strategische Ausrichtung, sichert das Budget und dient als Bindeglied zwischen IT-Transformation und Unternehmensführung. In der Advisory-Phase trifft der CIO die grundlegenden Entscheidungen: Welche Cloud-Strategie verfolgen wir? Mit welchem Anbieter? Auf welchem Zeithorizont? In der Adoption-Phase ist der CIO in erster Linie Eskalationsinstanz und Kommunikator nach oben und nach außen.
Der CIO ist die einzige Rolle, die für die gesamte Transformationsstrategie verantwortlich ist. Ohne einen aktiven, sichtbaren CIO als Sponsor scheitern Cloud-Transformationen nicht am Budget, sondern an der Energie der Organisation.
CTO — Chief Technology Officer
Abschnitt betitelt „CTO — Chief Technology Officer“Der CTO verantwortet die technische Architektur und die Plattformstrategie. Er sorgt dafür, dass die fachlichen Entscheidungen der Transformation konsistent sind, den langfristigen Zielen der Organisation dienen und nicht im Technologie-Zoo enden. In Organisationen ohne eigene CTO-Rolle wird diese Funktion typischerweise von einem Leiter Architektur oder einem Enterprise Architect wahrgenommen.
Der CTO ist die Brücke zwischen strategischer Vision und technischer Realität. Er beantwortet die Frage: Ist das, was wir tun, auch das, was wir in fünf Jahren tun wollen?
CISO — Chief Information Security Officer
Abschnitt betitelt „CISO — Chief Information Security Officer“Der CISO ist verantwortlich für die Sicherheitsanforderungen und deren Durchsetzung in der Cloud-Umgebung. Er definiert die Security Baseline, bewertet Risiken und sorgt dafür, dass Compliance-Anforderungen — DSGVO, BSI IT-Grundschutz, TISAX, BAIT — in technische Kontrollen übersetzt werden.
Der CISO ist oft der kritischste Stakeholder bei Cloud-Transformationen: Er kann eine Transformation verlangsamen, wenn seine Anforderungen nicht frühzeitig berücksichtigt werden, und er ist einer der wichtigsten Befähiger, wenn Sicherheit von Anfang an in die Architektur integriert und nicht nachträglich verankert wird.
Cloud Architect
Abschnitt betitelt „Cloud Architect“Der Cloud Architect ist der technische Lead der Transformation auf Plattformebene. Er konzipiert die Landing Zone, definiert die Netzwerktopologie, stellt Leitplanken auf und ist erster Ansprechpartner für technische Architekturentscheidungen der Produktteams. Der Cloud Architect ist kein Engpass — er ist ein Enabler, der Patterns und Referenzarchitekturen bereitstellt, damit Produktteams eigenständig bauen können.
Platform Owner
Abschnitt betitelt „Platform Owner“Der Platform Owner ist für den Betrieb der Cloud-Plattform als internes Produkt verantwortlich. Er stellt sicher, dass die Plattform verfügbar, aktuell und für die Produktteams nutzbar ist. Der Platform Owner arbeitet eng mit dem Cloud Architect zusammen und ist für den Betrieb verantwortlich, während der Architect für das Design verantwortlich ist.
FinOps Lead
Abschnitt betitelt „FinOps Lead“Der FinOps Lead ist verantwortlich für Kostentransparenz, Cost Governance und die Einführung von FinOps-Praktiken in der Organisation. Er koordiniert zwischen Finance, IT und Business, betreibt das Tagging-Framework, führt Rightsizing-Reviews durch und kommuniziert Cloud-Kosten nachvollziehbar an alle Stakeholder.
Der FinOps Lead ist keine reine IT-Rolle. Die erfolgreichsten FinOps-Programme werden von Personen geleitet, die sowohl Controlling-Affinität als auch technisches Verständnis mitbringen.
IAM Lead
Abschnitt betitelt „IAM Lead“Der IAM Lead ist verantwortlich für die Identitäts- und Zugriffsarchitektur der gesamten Cloud-Umgebung. Er definiert das RBAC-Konzept, führt den IDP ein, setzt MFA durch und stellt sicher, dass die Least-Privilege-Prinzipien operativ gelebt werden. Der IAM Lead arbeitet eng mit dem CISO zusammen, ist jedoch eine unabhängige operative Rolle.
CCoE Lead — Cloud Center of Excellence Lead
Abschnitt betitelt „CCoE Lead — Cloud Center of Excellence Lead“Der CCoE Lead koordiniert das Cloud Center of Excellence und ist dafür verantwortlich, dass Wissen, Standards und Best Practices in der Organisation verteilt werden. Er organisiert Gilden, baut das Champions-Netzwerk auf, koordiniert Schulungsprogramme und ist die erste Anlaufstelle für Teams, die Unterstützung bei der Cloud-Einführung benötigen.
Der CCoE Lead ist eine der einflussreichsten Rollen in der Transformation — und eine der am häufigsten unterschätzten. Ein effektiver CCoE multipliziert die Wirkung aller anderen Rollen.
RACI-Matrix
Abschnitt betitelt „RACI-Matrix“In der folgenden Matrix: R = Responsible (führt aus / koordiniert), A = Accountable (trägt die Letztverantwortung), C = Consulted (Mitarbeit gesucht), I = Informed (über Ergebnis informiert).
| Aktivität | CIO | CTO | CISO | Cloud Arch. | Platform Owner | FinOps Lead | IAM Lead | CCoE Lead |
|---|---|---|---|---|---|---|---|---|
| STRATEGIE & GOVERNANCE | ||||||||
| Cloud-Strategie verabschieden | A | C | C | C | — | C | — | I |
| Cloud-Anbieter auswählen | A | R | C | R | — | C | C | I |
| Governance-Charta verabschieden | A | C | R | C | — | — | C | C |
| Compliance-Register aufbauen | I | — | A | — | — | — | C | R |
| Security Baseline definieren | I | C | A | R | C | — | R | C |
| Cloud-Budget freigeben | A | C | — | — | — | R | — | I |
| ORGANISATION & ROLLEN | ||||||||
| CCoE gründen und beauftragen | A | C | C | — | — | — | — | R |
| RACI-Modell einführen | A | C | C | C | C | C | C | R |
| Schulungsprogramm aufsetzen | I | C | C | C | — | — | — | A/R |
| Champions-Netzwerk aufbauen | I | — | — | C | — | — | — | A/R |
| Betriebsmodell einführen (YBIYRI) | A | R | C | R | R | — | — | C |
| PLATTFORM & LANDING ZONE | ||||||||
| Landing Zone gestalten | I | A | C | R | C | — | C | — |
| Landing Zone in Betrieb nehmen | I | A | C | R | R | — | — | — |
| Leitplanken umsetzen | I | C | A | R | R | — | C | — |
| Netzwerktopologie freigeben | I | A | C | R | C | — | — | — |
| FINANZEN & KOSTEN | ||||||||
| Tagging-Standard definieren | I | C | — | C | C | A/R | — | C |
| Showback einführen | I | — | — | — | C | A/R | — | C |
| Chargeback einführen | C | — | — | — | C | A/R | — | C |
| Rightsizing-Prozess etablieren | I | — | — | — | C | A/R | — | — |
| IDENTITÄT & ZUGANG | ||||||||
| IDP-Federation einrichten | I | C | C | C | R | — | A/R | — |
| MFA für alle Benutzer erzwingen | I | — | A | — | R | — | R | — |
| RBAC-Matrix definieren | I | C | A | C | — | — | R | — |
| Zugriffsüberprüfungsprozess einführen | I | — | A | — | — | — | R | — |
| BESCHAFFUNG & RECHT | ||||||||
| AVV mit Anbieter abschließen | A | — | R | — | — | — | — | — |
| EVB-IT-Cloud-Vertrag prüfen | A | C | R | — | — | — | — | — |
Hinweise zur Anwendung
Abschnitt betitelt „Hinweise zur Anwendung“Die RACI-Matrix ist ein Ausgangspunkt, kein unveränderliches Dokument. Jede Organisation hat eine andere Führungsstruktur, unterschiedliche Rollendefinitionen und unterschiedliche Entscheidungswege. Die Matrix soll zu Beginn der Advisory-Phase im Führungsteam besprochen, angepasst und anschließend formal verabschiedet werden.
Drei Muster, die häufig in der Anwendung auftreten und die Qualität der Matrix beeinträchtigen: Erstens zu viele A-Einträge für eine Person. Verantwortlichkeiten sind sparsam zu verteilen. Wenn eine Person für 15 von 25 Tätigkeiten verantwortlich ist, ist das kein Führungsleitbild, sondern eine Diagnose der Überlastung. Zweitens fehlende R-Einträge. Wenn niemand für eine Tätigkeit verantwortlich aufgeführt ist, wird diese entweder nicht durchgeführt oder spontan von der falschen Person übernommen. Drittens zu viele C-Einträge. Wenn bei jeder Aktivität alle Rollen hinzugezogen werden, verlangsamt das die Entscheidungsfindung ohne entsprechenden Qualitätsgewinn.