Governance en besluitvorming¶

Iemand moet beslissen wat het platform wel en niet mag doen, uitzonderingen goedkeuren en het ontwerp coherent houden. Deze pagina beschrijft een governancemodel dat werkt voor een gedeeld platform, met het besluitvormingsproces, de regels voor uitzonderingen en de wijzigingscategorieën. Het is een referentiemodel: de organisatie die eigenaar is van het platform bepaalt welke onderdelen ze gebruikt.

Wiens governance?

Governance hoort bij de organisatie die eigenaar is van het platform: de klant. Het platformteam (XMMS of je eigen team, zie Beheermodellen) doet mee en implementeert de besluiten, maar vervangt de architectuur- en securityfuncties van de klant niet. Namen, vergaderritmes en aantallen hieronder zijn voorbeelden.

Technology board¶

Een technology board is een kleine groep die de samenhang van het platform bewaakt. Een typische scope is het deel van het applicatielandschap dat het platform bestrijkt.

Doelen

Coherente ontwerpkeuzes over het platform en de services eromheen.
Adviseren en reviewen voor service owners en voor de afnemers van het platform.
De change advisory board ondersteunen door de architecturale en technologische impact van wijzigingen te reviewen.
De communicatie tussen supportteams efficiënter maken.
Het proces voor architecturale uitzonderingen leiden en bewaken.

Mandaat

Architecturale wijzigingen goedkeuren die in lijn zijn met de architectuurprincipes, policies, standaarden en richtlijnen.
Architecturale uitzonderingen goedkeuren en erop toezien dat de aanvrager ze oplost.

Leden

Rol	Type	Wie
Lead	Kern	Een architect van enterprise architecture of security
Security lead	Kern	De lead security officer of specialist
Supportteams	Kern	De lead engineer van elk team in scope, inclusief het platformteam
Technology champion	Ad hoc	Wordt uitgenodigd als voor een besluit een diepgaand inzicht nodig is

Kernleden worden altijd geraadpleegd. Ad-hocleden worden uitgenodigd als hun input nodig is voor een goed besluit.

Besluitvormingsproces¶

Besluiten worden genomen met consent. Het verschil is belangrijk:

Methode	Betekenis
Consensus	Iedereen is het eens. Traag, en eindigt vaak in een matig compromis.
Consent	Mensen gaan akkoord om verder te gaan, ook als de uitkomst niet hun voorkeur heeft. De vraag is niet "vind je het mooi?" maar "kun je ermee leven, en ga je het steunen?"

De reden is snelheid: het voorkomt dat wijzigingsaanvragen en projecten stilvallen. De lead streeft naar consent. Als consent niet wordt bereikt, neemt de lead het besluit en vertelt de board, de architectuurboard en de betrokken eigenaren waarom het op deze manier is genomen en waarom consent niet is bereikt.

Presenteer het voorstel. Iedereen kan beginnen met het beschrijven van een probleem en een voorstel. Begin met "Ik stel voor dat we...". Een facilitator begeleidt het gesprek zonder partij te kiezen.
Verduidelijkende vragen. Iedereen kan vragen stellen om het voorstel te begrijpen. In deze ronde geen reacties, meningen of verbeteringen. "Niet gespecificeerd" of "Dat weet ik nog niet" zijn geldige antwoorden.
Reactieronde. Eén voor één reageert elk lid. De indiener luistert alleen. Reacties mogen suggesties bevatten.
Herformuleer het voorstel. De indiener mag het voorstel aanpassen op basis van wat is gezegd, of geeft aan dat het blijft zoals het was.
Bezwarenronde. De facilitator vraagt elk lid: "Zie je een reden waarom het aannemen hiervan schade zou veroorzaken of ons achteruit zou helpen?" Bezwaren worden genoemd en vastgelegd zonder discussie.
Bekrachtig. De indiener past het voorstel aan totdat alle bezwaren zijn opgelost. Daarna wordt de bezwarenronde herhaald. De ronde eindigt wanneer het voorstel is aangenomen of ingetrokken.

Een geldig bezwaar is objectief, gebaseerd op de huidige situatie (niet op mogelijke toekomsten) en geen kwestie van smaak. Een collega kan een voorstel niet blokkeren omdat hij of zij een ander voorstel liever heeft.

Noodgevallen¶

Als een besluit niet kan wachten tot de volgende vergadering, kunnen de lead en de security lead direct beslissen. De lead informeert alle leden en licht het besluit toe in de volgende reguliere vergadering.

Escalatie¶

Als consent niet wordt bereikt, of een lid zich onder druk gezet voelde om het te geven:

Soort	Volgorde
Architecturaal	De lead van de board, daarna de centrale architectuurboard
Organisatorisch	De product owner, de service owner, de business owner, daarna het senior management

Documentatie¶

Documenteer elk besluit: wat is besloten, waarom, door wie en welke alternatieven zijn overwogen. Architecture decision records (ADR's) zijn een goed formaat. De ontwerprichtlijnen in deze documentatie zijn gebaseerd op besluiten van dit soort.

Vergaderingen¶

Vergadering	Ritme	Wie	Doel
Boardvergadering	Wekelijks (voorbeeld)	Alle boardleden	Collega's presenteren initiatieven ter review of goedkeuring
Spoedvergadering	Ad hoc	Lead, security lead en de betrokken support leads	Een besluit dat niet kan wachten

Kernleden zijn aanwezig en bereiden zich voor (afgesproken acties, pre-read).
De agenda, de documenten die worden besproken of goedgekeurd en wat van de leden wordt verwacht (lezen, goedkeuren, presenteren) worden drie dagen voor de vergadering verstuurd.

De reguliere operationele en tactische overleggen tussen het platformteam en de klant staan beschreven in Operationele en tactische overleggen.

Spelregels¶

Een board werkt beter met een paar gedeelde regels. De korte lijst die bij dit soort governance past:

Respecteer vertrouwelijkheid: wat in de vergadering wordt gezegd, blijft daar, tenzij de eigenaar akkoord gaat.
Wees aanwezig, en blijf als het moeilijk wordt.
Spreek open, respectvol en zonder te beschuldigen. Neem eigenaarschap over je eigen perspectief.
Luister voordat je oplost. Vraag toestemming voordat je ongevraagd advies geeft.
Wees op tijd, wees voorbereid en blijf tot het einde.
Fouten mogen. Leer ervan.

Policies, standaarden en best practices¶

Niet elke regel is even bindend. Gebruik drie niveaus en zeg welk niveau een regel heeft. Zie Ontwerpprincipes.

Uitzonderingen en exemptions¶

Uitzonderingen zijn normaal op een groot platform, zolang ze expliciet zijn.

Soort	Waar besloten	Waar vastgelegd
Architecturale uitzondering (een afwijking van een principe, standaard of ontwerp)	De technology board	Het besluitrecord
Policy-exemption (een resource of scope wordt uitgesloten van een Azure Policy)	De security officer keurt goed, het platformteam implementeert	Als JSON-bestand in de configuratierepository met een `expires_on`-datum (Policy assignments, Policy exemptions)

Houd een exemption-register bij met, voor elke exemption: de policy, de rationale en de scope. Review het regelmatig, minimaal als een exemption verloopt.

Typische gerechtvaardigde exemptions op een managed platform. Het zijn voorbeelden, geen standaarden:

Policy (bedoeling)	Typische rationale	Compenserende maatregel
Gastaccounts met lees-, schrijf- of ownerrechten moeten worden verwijderd	Een externe managed-serviceprovider werkt als gast in de tenant en heeft deze rollen nodig	Rollen zijn alleen beschikbaar via PIM, met least privilege
Het DDoS protection plan moet zijn ingeschakeld	De securityfunctie van de organisatie heeft besloten dat de vaste kosten op dit moment zwaarder wegen dan het voordeel	Besluit vastgelegd en gereviewd
Service principals mogen geen administratieve rollen hebben	Service principals deployen de infrastructure as code naar de hub en de spokes	Credentials zijn kortlevend of federated; zie Toegang, groepen en PIM

Voor afnemers: Policy en uitzonderingen.

Wijzigingscategorieën¶

Drie categorieën houden de inspanning in verhouding tot het risico. Ze volgen de gebruikelijke betekenis van IT service management (ITIL).

Categorie	Betekenis	Voorbeelden
Standaard	Laag risico, vaak herhaald en vooraf goedgekeurd. Volgt een gedocumenteerde procedure die change management eenmaal heeft beoordeeld.	Nieuwe workload of spoke, extra spoke, een firewallregel, een tagwijziging. Zie Veelvoorkomende aanvragen.
Normaal	Een geplande wijziging, geen noodgeval, die change management, architectuur en/of security eerst beoordelen	Een wijziging aan het spoke-template, een nieuwe koppeling tussen workloads die niet het standaardpatroon volgt, een nieuwe feature flag
Nood	Een wijziging die zo snel mogelijk moet worden doorgevoerd	Een securitypatch voor een zero-day exploit

Een aanvraag die niet in een standaardwijziging past, wordt behandeld als normale wijziging. Een wijziging die nieuwe Terraform vraagt, is een ontwikkelwijziging in de coderepository (Nieuwe functionaliteit bouwen).

Afnemers informeren over platformupdates¶

Een gebruikelijke afspraak voor platformupdates (nieuwe versies, hubwijzigingen) is ze in twee groepen te splitsen:

	Kleine wijziging (geen verwachte impact)	Grote wijziging (mogelijke impact)
Aankondiging	De klant wordt vooraf geïnformeerd (voorbeeld: 14 dagen)	De klant wordt vooraf geïnformeerd (voorbeeld: 14 dagen)
Review door de klant	Niet nodig	Ja
Timing	Op elk moment	Samen afgesproken
Change advisory board	Niet nodig	Goedkeuring nodig
Registratie	In het ticketsysteem en de work tracker	In het ticketsysteem en de work tracker

Je contract of interne afspraak bepaalt de echte aantallen. Zie Wat te doen als een nieuwe versie wordt gereleased en Achterwaartse compatibiliteit.

Service levels¶

Een service level agreement voor het platform is steeds opgebouwd uit dezelfde bouwstenen:

het servicevenster (uren waarin het platformteam beschikbaar is),
severities met reactiedoelen,
een beschikbaarheidsdoel voor de hubcomponenten, exclusief gepland onderhoud,
rapportage (beschikbaarheid, incidenten, wijzigingen),
voor additional services een apart addendum (Servicetypen).

Hoe je ze definieert, meet en rapporteert staat in Service level management. Een eerste set voorbeeldseverities en -doelen staat in Operationele verantwoordelijkheden. Workload teams kunnen hun subscription taggen met een serviceklasse (bijvoorbeeld Dev, Bronze, Silver, Gold), zodat duidelijk is welk supportniveau geldt; zie Naamgeving en tags.