Governance und Entscheidungsfindung¶

Jemand muss entscheiden, was die Plattform darf und was nicht, Ausnahmen genehmigen und das Design stimmig halten. Diese Seite beschreibt ein Governance-Modell, das für eine gemeinsam genutzte Plattform funktioniert, mit dem Entscheidungsprozess, den Regeln für Ausnahmen und den Änderungskategorien. Es ist ein Referenzmodell: Die Organisation, der die Plattform gehört, entscheidet, welche Teile sie verwendet.

Wessen Governance?

Die Governance gehört der Organisation, der die Plattform gehört: dem Kunden. Das Plattform-Team (XMMS oder dein eigenes Team, siehe Betriebsmodelle) nimmt teil und setzt die Entscheidungen um, ersetzt aber nicht die Architektur- und Security-Funktionen des Kunden. Namen, Besprechungsrhythmen und Zahlen unten sind Beispiele.

Technology Board¶

Ein Technology Board ist eine kleine Gruppe, die die Stimmigkeit der Plattform sichert. Ein typischer Scope ist der Teil der Anwendungslandschaft, den die Plattform abdeckt.

Ziele

Stimmige Design-Entscheidungen über die Plattform und die Services drumherum.
Beraten und prüfen für Service Owner und für die Nutzer der Plattform.
Das Change Advisory Board unterstützen, indem die architektonischen und technologischen Auswirkungen von Änderungen geprüft werden.
Die Kommunikation zwischen den Support-Teams effizienter machen.
Den Prozess für architektonische Ausnahmen leiten und bewachen.

Mandat

Architektonische Änderungen genehmigen, die den Architekturprinzipien, Policies, Standards und Richtlinien entsprechen.
Architektonische Ausnahmen genehmigen und nachverfolgen, dass der Antragsteller sie auflöst.

Mitglieder

Rolle	Art	Wer
Lead	Kern	Ein Architekt aus Enterprise Architecture oder Security
Security Lead	Kern	Der leitende Security Officer oder Spezialist
Support-Teams	Kern	Der Lead Engineer jedes Teams im Scope, einschließlich des Plattform-Teams
Technology Champion	Ad hoc	Wird eingeladen, wenn für eine Entscheidung ein vertiefter Blick nötig ist

Kernmitglieder werden immer konsultiert. Ad-hoc-Mitglieder werden eingeladen, wenn ihr Input für eine gute Entscheidung gebraucht wird.

Entscheidungsprozess¶

Entscheidungen werden per Consent getroffen. Der Unterschied ist wichtig:

Methode	Bedeutung
Konsens	Alle stimmen zu. Langsam und endet oft in einem mittelmäßigen Kompromiss.
Consent	Die Beteiligten stimmen zu, weiterzumachen, auch wenn das Ergebnis nicht ihre bevorzugte Wahl ist. Die Frage ist nicht „Gefällt dir das?“, sondern „Kannst du damit leben, und wirst du es unterstützen?“

Der Grund ist Geschwindigkeit: Es verhindert, dass Change Requests und Projekte stocken. Der Lead strebt Consent an. Wenn kein Consent erreicht werden kann, trifft der Lead die Entscheidung und sagt dem Board, dem Architecture Board und den beteiligten Ownern, warum sie so getroffen wurde und warum kein Consent erreicht wurde.

Den Vorschlag vorstellen. Jeder kann beginnen, indem er ein Problem und einen Vorschlag beschreibt. Beginne mit „Ich schlage vor, dass wir …“. Ein Moderator leitet das Gespräch, ohne Partei zu ergreifen.
Verständnisfragen. Jeder kann Fragen stellen, um den Vorschlag zu verstehen. In dieser Runde keine Reaktionen, Meinungen oder Verbesserungen. „Nicht spezifiziert“ oder „Ich weiß es noch nicht“ sind gültige Antworten.
Reaktionsrunde. Jedes Mitglied reagiert nacheinander. Der Vorschlagende hört nur zu. Reaktionen dürfen Vorschläge enthalten.
Den Vorschlag neu formulieren. Der Vorschlagende darf den Vorschlag anhand des Gesagten anpassen oder erklärt, dass er bleibt, wie er war.
Einwandrunde. Der Moderator fragt jedes Mitglied: „Siehst du einen Grund, warum die Annahme Schaden anrichten oder uns zurückwerfen würde?“ Einwände werden ohne Diskussion genannt und festgehalten.
Ratifizieren. Der Vorschlagende passt den Vorschlag an, bis alle Einwände gelöst sind. Dann wird die Einwandrunde wiederholt. Die Runde endet, wenn der Vorschlag angenommen oder zurückgezogen wird.

Ein gültiger Einwand ist objektiv, beruht auf der gegenwärtigen Situation (nicht auf möglichen Zukünften) und ist keine Geschmackssache. Ein Kollege kann einen Vorschlag nicht blockieren, nur weil er einen anderen bevorzugt.

Notfälle¶

Wenn eine Entscheidung nicht bis zur nächsten Sitzung warten kann, können der Lead und der Security Lead direkt entscheiden. Der Lead informiert alle Mitglieder und erklärt die Entscheidung in der nächsten regulären Sitzung.

Eskalation¶

Wenn kein Consent erreicht wird oder ein Mitglied sich unter Druck gesetzt fühlte, ihn zu geben:

Art	Reihenfolge
Architektonisch	Der Board Lead, dann das zentrale Architecture Board
Organisatorisch	Der Product Owner, der Service Owner, der Business Owner, dann das Senior Management

Dokumentation¶

Dokumentiere jede Entscheidung: was entschieden wurde, warum, von wem und welche Alternativen betrachtet wurden. Architecture Decision Records (ADRs) sind ein gutes Format. Die Design-Leitlinien in dieser Dokumentation beruhen auf Entscheidungen dieser Art.

Sitzungen¶

Sitzung	Rhythmus	Wer	Zweck
Board-Sitzung	Wöchentlich (Beispiel)	Alle Board-Mitglieder	Kolleginnen und Kollegen stellen Initiativen zur Prüfung oder Genehmigung vor
Notfallsitzung	Ad hoc	Lead, Security Lead und die betroffenen Support-Leads	Eine Entscheidung, die nicht warten kann

Kernmitglieder nehmen teil und bereiten sich vor (vereinbarte Aktionen, Pre-Read).
Die Agenda, die zu besprechenden oder zu genehmigenden Dokumente und die Erwartungen an die Mitglieder (lesen, genehmigen, vorstellen) werden drei Tage vor der Sitzung verschickt.

Die regelmäßigen operativen und taktischen Besprechungen zwischen dem Plattform-Team und dem Kunden sind unter Operative und taktische Meetings beschrieben.

Spielregeln¶

Ein Board arbeitet besser mit ein paar gemeinsamen Regeln. Die kurze Liste, die zu dieser Art von Governance passt:

Wahre die Vertraulichkeit: Was in der Sitzung gesagt wird, bleibt dort, es sei denn, der Urheber stimmt zu.
Sei anwesend und bleib, auch wenn es schwierig wird.
Sprich offen, respektvoll und ohne Schuldzuweisungen. Steh zu deiner Sichtweise.
Hör zu, bevor du Lösungen anbietest. Frag um Erlaubnis, bevor du ungebetene Ratschläge gibst.
Sei pünktlich, sei vorbereitet und bleib bis zum Ende.
Fehler sind erlaubt. Lerne daraus.

Policies, Standards und Best Practices¶

Nicht jede Regel ist gleich verbindlich. Verwende drei Stufen und sage, welche Stufe eine Regel hat. Siehe Design-Prinzipien.

Ausnahmen und Exemptions¶

Ausnahmen sind auf einer großen Plattform normal, solange sie explizit sind.

Art	Wo entschieden	Wo festgehalten
Architektonische Ausnahme (eine Abweichung von einem Prinzip, Standard oder Design)	Das Technology Board	Der Entscheidungseintrag
Policy-Ausnahme (eine Ressource oder ein Scope wird von einer Azure Policy ausgenommen)	Der Security Officer genehmigt, das Plattform-Team setzt um	Als JSON-Datei im Konfigurations-Repository mit einem Datum `expires_on` (Policy-Zuweisungen, Policy-Ausnahmen)

Führe ein Exemption-Register mit, für jede Exemption: die Policy, die Begründung und den Scope. Prüfe es regelmäßig, mindestens wenn eine Exemption abläuft.

Typische begründete Exemptions auf einer Managed Platform. Sie sind Beispiele, keine Standardwerte:

Policy (Zweck)	Typische Begründung	Kompensierende Kontrolle
Gastkonten mit Lese-, Schreib- oder Owner-Rechten sollten entfernt werden	Ein externer Managed-Service-Anbieter arbeitet als Gast im Tenant und braucht diese Rollen	Rollen sind nur über PIM verfügbar, mit Least Privilege
Der DDoS-Schutzplan sollte aktiviert sein	Die Security-Funktion der Organisation hat entschieden, dass die Fixkosten den Nutzen zum jetzigen Zeitpunkt überwiegen	Entscheidung festgehalten und geprüft
Service Principals sollten keine administrativen Rollen haben	Service Principals deployen die Infrastruktur als Code in den hub und die Spokes	Zugangsdaten sind kurzlebig oder föderiert; siehe Zugriff, Gruppen und PIM

Für Nutzer: Policy und Ausnahmen.

Änderungskategorien¶

Drei Kategorien halten den Aufwand im Verhältnis zum Risiko. Sie folgen der üblichen Bedeutung im IT Service Management (ITIL).

Kategorie	Bedeutung	Beispiele
Standard	Geringes Risiko, häufig wiederholt und vorab genehmigt. Sie folgt einem dokumentierten Verfahren, das das Change Management einmal geprüft hat.	Neuer Workload oder Spoke, zusätzlicher Spoke, eine Firewallregel, eine Tag-Änderung. Siehe Häufige Anfragen.
Normal	Eine geplante Änderung ohne Notfall, die zuvor von Change Management, Architektur und/oder Security geprüft wird	Eine Änderung am Spoke-Template, eine neue Verbindung zwischen Workloads, die nicht dem Standardmuster folgt, ein neues Feature Flag
Notfall	Eine Änderung, die so schnell wie möglich eingebracht werden muss	Ein Security-Patch für einen Zero-Day-Exploit

Eine Anfrage, die nicht zu einer Standardänderung passt, wird als normale Änderung behandelt. Eine Änderung, die neues Terraform braucht, ist eine Entwicklungsänderung im Code-Repository (Neue Funktionalität bauen).

Nutzer über Plattform-Updates informieren¶

Eine übliche Vereinbarung für Plattform-Updates (neue Versionen, Änderungen am hub) ist, sie in zwei Gruppen aufzuteilen:

	Kleine Änderung (keine erwartete Auswirkung)	Große Änderung (mögliche Auswirkung)
Ankündigung	Der Kunde wird vorab informiert (Beispiel: 14 Tage)	Der Kunde wird vorab informiert (Beispiel: 14 Tage)
Prüfung durch den Kunden	Nicht nötig	Ja
Zeitpunkt	Jederzeit	Gemeinsam vereinbart
Change Advisory Board	Nicht nötig	Genehmigung nötig
Registrierung	Im Ticketsystem und im Work Tracker	Im Ticketsystem und im Work Tracker

Dein Vertrag oder deine interne Vereinbarung legt die echten Zahlen fest. Siehe Was zu tun ist, wenn eine neue Version veröffentlicht wird und Abwärtskompatibilität.

Service Levels¶

Ein Service Level Agreement für die Plattform besteht jedes Mal aus denselben Bausteinen:

dem Service-Fenster (Zeiten, in denen das Plattform-Team verfügbar ist),
Severities mit Reaktionszielen,
einem Verfügbarkeitsziel für die hub-Komponenten, geplante Wartung ausgenommen,
Reporting (Verfügbarkeit, Incidents, Änderungen),
bei zusätzlichen Services einem eigenen Nachtrag (Service-Typen).

Wie du sie definierst, misst und berichtest, steht unter Service Level Management. Ein erster Satz von Beispiel-Severities und -Zielen steht unter Betriebsverantwortlichkeiten. Workload-Teams können ihre Subscription mit einer Service-Klasse taggen (zum Beispiel Dev, Bronze, Silver, Gold), damit klar ist, welches Support-Niveau gilt; siehe Namensgebung und Tags.