Account Governance

Zielbild

Account Governance beschreibt, wie Teams, Umgebungen und Zuständigkeiten in der Cloud klar getrennt und steuerbar aufgebaut werden.

Damit entsteht die organisatorische Steuerungsebene für Migrationswellen: wo Workloads betrieben werden, wem welcher Scope gehört und wie neue Projekte ohne Umgehung von Guardrails angebunden werden.

Governance-Hierarchie

Governance-Design und Delivery

Kernbausteine der Governance

• Regions: Die Regionenstrategie bestimmt Datenlokalität, Latenzprofil und Resilienzgrenzen für Workloads und Shared Services. Definieren Sie früh verbindliche Nutzungsmuster und stimmen Sie diese mit Compliance- und Kontinuitätsanforderungen ab. Dokumentation
• Customer Account: Der Customer Account ist die oberste Governance-Grenze für Ownership, Abrechnung und Administration. Er bildet den Anker für organisationsweite Standards und Kontrollverantwortung. Dokumentation
• STACKIT Folder: Folder strukturieren organisatorische Domänen (zum Beispiel Plattform, Shared Services, Business Units, Umgebungen) und ermöglichen Policy-Vererbung sowie klare Delegationsmodelle. Dokumentation
• STACKIT Projects: Projects sind die Delivery-Scopes, in denen Ressourcen bereitgestellt und betrieben werden. Sie sollten über ein definiertes Onboarding-Modell an Folder angebunden werden und nicht ad hoc entstehen. Dokumentation

Wie die Bausteine zusammenspielen

• Regionprinzipien zuerst: Legen Sie fest, welche Regionen für welche Workload-Klassen zulässig sind.
• Customer Account als Governance-Root: Verankern Sie globale Ownership, Policy-Absicht und finanzielle Verantwortlichkeit.
• Folder für Struktur und Delegation: Überführen Sie das Betriebsmodell in skalierbare organisatorische Grenzen.
• Projects für Delivery: Stellen Sie Projektscopes über einen standardisierten Lebenszyklus mit verpflichtenden, vom Folder geerbten Kontrollen bereit.

Wichtige Entscheidungen

• Region-Governance-Modell: Entscheiden Sie zwischen Single-Region-, Dual-Region- oder Workload-basiertem Regionenansatz inklusive Ausnahmen.
• Customer-Account-Verantwortung: Definieren Sie, welche zentralen Teams Governance, Billing-Transparenz und Kontrollbetrieb verantworten.
• Folder-Topologie: Legen Sie fest, wie Folder auf Domänen wie Plattform, Umgebungen und Business Units abgebildet werden.
• Project-Onboarding-Modell: Standardisieren Sie Projekterstellung, Namenskonventionen, Tagging und Lebenszyklus-Kontrollen.
• Policies und Ausnahmen: Definieren Sie verpflichtende Guardrails und transparente Ausnahmeprozesse.

Typische Ergebnisse

• Governance-Blueprint: Customer-Account-, Folder- und Project-Topologie mit Verantwortungsmatrix.
• Regionen-Nutzungsrichtlinie: Freigegebene Regionenmuster je Workload-Typ und Risikoprofil.
• Project-Onboarding-Standard: Wiederholbarer Prozess für die Erstellung und Anbindung gesteuerter Projekte.
• Control-Baseline: Erzwungene Namens-, Tagging- und Policy-Kontrollen mit dokumentiertem Ausnahmefluss.

Typische Anti-Patterns

• Keine Regionenrichtlinie: Regionauswahl pro Team oder Projekt ohne unternehmensweite Leitplanken.
• Unstrukturierte Project-Sprawl: Projekte entstehen ohne Folder-Strategie, klare Ownership oder Lebenszyklusstandards.
• Governance nur auf Papier: Kontrollen sind dokumentiert, aber nicht im Projekt-Onboarding und Betrieb verankert.