Governance and Decision Making¶
Someone has to decide what the platform may and may not do, approve exceptions and keep the design coherent. This page describes a governance model that works for a shared platform, with the decision process, the rules for exceptions and the categories of change. It is a reference model: the organisation that owns the platform decides which parts it uses.
Whose governance?
Governance belongs to the organisation that owns the platform: the customer. The platform team (XMMS or your own team, see Operating models) takes part and implements the decisions, but does not replace the customer's architecture and security functions. Names, meeting rhythms and numbers below are examples.
Technology board¶
A technology board is a small group that guards the coherence of the platform. A typical scope is the part of the application landscape the platform covers.
Goals
- Coherent design choices across the platform and the services around it.
- Advise and review for service owners and for the consumers of the platform.
- Support the change advisory board by reviewing the architectural and technological impact of changes.
- Make communication between support teams more efficient.
- Lead and guard the process for architectural exceptions.
Mandate
- Approve architectural changes that are in line with the architecture principles, policies, standards and guidelines.
- Approve architectural exceptions and follow up that the requester resolves them.
Members
| Role | Type | Who |
|---|---|---|
| Lead | Core | An architect from enterprise architecture or security |
| Security lead | Core | The lead security officer or specialist |
| Support teams | Core | The lead engineer of each team in scope, including the platform team |
| Technology champion | Ad hoc | Invited when an in-depth view is needed for a decision |
Core members are always consulted. Ad-hoc members are invited when their input is needed for a good decision.
Decision process¶
Consent, not consensus¶
Decisions are taken by consent. The difference matters:
| Method | Meaning |
|---|---|
| Consensus | Everyone agrees. Slow, and often ends in a mediocre compromise. |
| Consent | People agree to move forward even if the outcome is not their preferred choice. The question is not "do you like it?" but "can you live with it, and will you support it?" |
The reason is speed: it prevents change requests and projects from stalling. The lead aims for consent. When consent cannot be reached, the lead takes the decision and tells the board, the architecture board and the owners involved why it was taken this way and why consent was not reached.
Steps of a consent round¶
- Present the proposal. Anyone can start by describing a problem and a proposal. Start with "I propose we...". A facilitator guides the conversation without taking sides.
- Clarifying questions. Everyone can ask questions to understand the proposal. No reactions, opinions or improvements in this round. "Not specified" or "I don't know yet" are valid answers.
- Reaction round. One by one, each member reacts. The proposer only listens. Reactions may include suggestions.
- Restate the proposal. The proposer may adjust the proposal based on what was said, or states that it stays as it was.
- Objection round. The facilitator asks each member: "Do you see any reason why adopting this would cause harm or move us backwards?" Objections are stated and captured without discussion.
- Ratify. The proposer adjusts the proposal until all objections are resolved. Then the objection round is repeated. The round ends when the proposal is adopted or withdrawn.
A valid objection is objective, based on the present situation (not on possible futures) and not a matter of taste. A colleague cannot block a proposal because they prefer another one.
Emergencies¶
When a decision cannot wait for the next meeting, the lead and the security lead can decide directly. The lead informs all members and explains the decision at the next regular meeting.
Escalation¶
When consent is not reached, or a member felt pressured to give it:
| Kind | Order |
|---|---|
| Architectural | The board lead, then the central architecture board |
| Organisational | The product owner, the service owner, the business owner, then senior management |
Documentation¶
Document every decision: what was decided, why, by whom and which alternatives were considered. Architecture decision records (ADRs) are a good format. The design guidance in this documentation is based on decisions of this kind.
Meetings¶
| Meeting | Rhythm | Who | Purpose |
|---|---|---|---|
| Board meeting | Weekly (example) | All board members | Colleagues present initiatives for review or approval |
| Emergency meeting | Ad hoc | Lead, security lead and the affected support leads | A decision that cannot wait |
- Core members attend and prepare (agreed actions, pre-read).
- The agenda, the documents to discuss or approve and what is expected of the members (read, approve, present) are sent three days before the meeting.
The regular operational and tactical meetings between the platform team and the customer are described in Operational and tactical meetings.
Rules of engagement¶
A board works better with a few shared rules. The short list that fits this kind of governance:
- Respect confidentiality: what is said in the meeting stays there unless the owner agrees.
- Be present, and stay when it gets difficult.
- Speak openly, respectfully and without blaming. Own your perspective.
- Listen before you fix. Ask permission before giving unsolicited advice.
- Be on time, be prepared and stay until the end.
- Mistakes are allowed. Learn from them.
Policies, standards and best practices¶
Not every rule is equally binding. Use three levels and say which level a rule has. See Design principles.
Exceptions and exemptions¶
Exceptions are normal in a large platform, as long as they are explicit.
| Kind | Where decided | Where recorded |
|---|---|---|
| Architectural exception (a deviation from a principle, standard or design) | The technology board | The decision record |
| Policy exemption (a resource or scope is excluded from an Azure Policy) | Security officer approves, the platform team implements | As a JSON file in the configuration repository with an expires_on date (Policy assignments, Policy exemptions) |
Keep an exemption register with, for every exemption: the policy, the rationale and the scope. Review it regularly, at least when an exemption expires.
Typical justified exemptions on a managed platform. They are examples, not defaults:
| Policy (intent) | Typical rationale | Compensating control |
|---|---|---|
| Guest accounts with read, write or owner permissions should be removed | An external managed service provider works as guest in the tenant and needs these roles | Roles are only available through PIM, with least privilege |
| DDoS protection plan should be enabled | The organisation's security function decided that the fixed cost outweighs the benefit at this time | Decision recorded and reviewed |
| Service principals should not have administrative roles | Service principals deploy the infrastructure as code to the hub and the spokes | Credentials are short-lived or federated; see Access, groups and PIM |
For consumers: Policy and exemptions.
Categories of change¶
Three categories keep the effort in proportion to the risk. They follow the usual IT service management (ITIL) meaning.
| Category | Meaning | Examples |
|---|---|---|
| Standard | Low risk, commonly repeated and pre-approved. It follows a documented procedure that change management reviewed once. | New workload or spoke, additional spoke, a firewall rule, a tag change. See Common requests. |
| Normal | A planned, non-emergency change that change management, architecture and/or security review first | A change to the spoke template, a new connection between workloads that does not follow the standard pattern, a new feature flag |
| Emergency | A change that must be introduced as soon as possible | A security patch for a zero-day exploit |
A request that does not fit a standard change is treated as a normal change. A change that needs new Terraform is a development change in the code repository (Building new functionality).
Informing consumers about platform updates¶
A common agreement for platform updates (new versions, hub changes) is to split them in two groups:
| Minor change (no expected impact) | Major change (possible impact) | |
|---|---|---|
| Notice | The customer is informed in advance (example: 14 days) | The customer is informed in advance (example: 14 days) |
| Review by the customer | Not needed | Yes |
| Timing | Any time | Agreed together |
| Change advisory board | Not needed | Approval needed |
| Registration | In the ticket system and the work tracker | In the ticket system and the work tracker |
Your contract or internal agreement sets the real numbers. See What to do when a new version is released and Backwards compatibility.
Service levels¶
A service level agreement for the platform is built from the same building blocks every time:
- the service window (hours in which the platform team is available),
- severities with response targets,
- an availability target for the hub components, with planned maintenance excluded,
- reporting (availability, incidents, changes),
- for additional services, a separate addendum (Service types).
How to define, measure and report them is in Service level management. A first set of example severities and targets is in Operating responsibilities.
Workload teams can tag their subscription with a service class (for example Dev, Bronze, Silver, Gold) so it is
clear what support level applies; see Naming and tags.