Azure Governance is a set of guidelines. That’s it. A simple table with text. This table can look like this.
| ID | Title | Description | Status |
|---|---|---|---|
| AAD-SEC-001 | AAD Admin roles are assigned through PIM | AAD Admin roles are all roles with “Admin” in their name. Those roles are assigned as eligible roles in PIM | In Review |
| AZ-GOV-001 | Subscriptions are organized in Management Groups | Subscriptions are added to the most suitable Management group: – Level 0 (Root): ROOT MG – Level 1 (Area): FACULTY | STUDENTS | IT – Level 2 (Environment): TEST | PROD | Approved |
| AZ-SEC-001 | Only admin accounts have owner permissions on subscriptions | The standard account is used during the day. To elevate access to owner permissions on a subscription the admin account is to be used | Draft |
What are the benefits of Azure Governance?
Engineers decide many things during their work day. Sometimes bigger discussions emerge from only small decisions to be made. This takes time. And engineers are often biased by past experiences. Those opinion-based preferences can be wrong and don’t benefit the overall cloud architecture.
The engineer has the advantage to adhere to already discussed and defined guidelines. This lets him or her focus on the job at hand – namely to implement the best possible solution for the end-user.
If the guidelines turn out to be wrong or incomplete, the engineer suggests a change to the guideline. The discussion is then focused on improvement and not on opinions – and everyone benefits from that kind of dialog.
What is good Azure Governance?
The guidelines need to be explicit. They are in written form and have the required room for interpretation but not more.
Good example
Resources are provisioned in the main region ‘Switzerland North’. If the resource is not supported by the main region, select ‘West Europe’.
Bad example
Chose the best region available.
Include everyone
You know as well as I do that decisions are best adhered to if the individuals are part of the discussion that led to the decision. Involve the affected persons in the governance process.
This is as simple as having a weekly meeting that involves an IT decision maker, a security officer, an architect, at least one cloud engineer, the cost responsible, and someone from the help desk.
In this meeting, the suggestions are discussed and the guidelines are set to ‘approved’. It’s very important to allow changes to the guidelines always. If this is not given, discussions are endless because the involved persons are scared to approve a guideline.
The engineers then transport the decision to their teams. They know if adjustments are required.
Conclusion
Create a table with governance guidelines and implement a process on how to add or change guidelines. Involve the correct individuals in the process. And don’t be scared to approve the wrong guidelines. The guidelines are changeable in the next meeting if required. A wrong one in written form is always better than having none. Without guidelines, engineers are confused and just lose too much time. So, be brave and implement your first guideline today.