Governance as Code, this is the Way
Azure Governance artifacts, such as json files with deployment scripts, are visible and human-readable artifacts that can be stored along with source code. This concept is called Governance as Code (GaC). Traditional governance is often, in its earliest stages, subject to interpretation. In later stages of maturity there are still policy documents that update, and trickle down through various programs and initiatives, requiring some interpretation. This will not work well in Azure. When GaC Interpretation is not required, this is the way.
Most Teams are Already Expert in Required Patterns
Most developers and teams have switched over to storing code in cloud repositories like Azure DevOps and GitHub. They are already branching to write code and required tests. The branches link back to work items being tracked and expressed in terms of business value. They are already gating check-ins so that team members and stakeholders all agree to the change. Once the change has been accepted the change is promoted to the correct environment. At various stages of acceptance, the change is further promoted. There is no try, this is happening today. Changes are accepted or they are not. Changes are promoted, or they are not. Infrastructure as Code is following the same patterns, the same goals. Azure Governance should follow the same process.
Azure Governance Change Scenario
A team wants to deploy a new feature to an application that is working on an Azure Virtual Machine. They know that from a cost perspective the required SKU is more than they have asked for before, and the required OS is different than they have deployed in the past. As part of the assessment phase of this project they want to evaluate the policy to ensure they will still be compliant with policies and not have deployments denied.
The team inspects Governance as Code and sees that they can provide the operating system and VM SKU as parameters. The OS parameter is without limitation, but they have discovered that the VM SKU is not currently allowed. The team updates the policy document and requests that their change be accepted with clear reasons why they are pointing back to business cases. The team and stakeholders all agree this is required, but further we want to limit it, so add some additional scoping so that this only applies to their team and product. Finally, when the change is accepted the Azure Governance change is executed and the team can progress.
Use the Force!
Okay that sounds great, in fact your compliance officer just did cartwheels past your office. We can take it a step further, not only policies and management groups, but also to describe our entire architecture as well. With an Azure Blueprint we have an entire reusable artifact dedicated to delivering enterprise classes of infrastructure, policy, security all in the same package, and it is all versioned! You might even be able to go on vacation after this!
To learn more about enterprise and cloud governance, download the Governance Playbook today!
