Research Hub > Governance for Azure Part 2: Minimum Viable Product and Iteration

July 23, 2020

3 min

Governance for Azure Part 2: Minimum Viable Product and Iteration

Here is how to apply the disciplines of governance to get more from your cloud resources.

Mark Teson


In my last blog, 5 Disciplines of Cloud Governance for Azure, I talked about using the Cloud Adoption Framework (CAF) for Governance and using the five disciplines. In this blog, I will share more detail of how to implement these disciplines. The disciplines are cost management, security baseline, resource consistency, identity baseline and deployment acceleration. Each one of these disciplines can be viewed as a category of governance and used in a way to provide focus on key areas.

Learn how CDW can assist you with all things Azure.

It is important to note that although they are separate, they do intermingle. Though it is possible to implement some governance by selecting a subset of disciplines, it is recommended to use all five disciplines as part of a governance minimum viable product (MVP) strategy. There is a lot of overlap between the disciplines and the tools in Azure that address the business risks cross multiple disciplines.

The CAF model is predicated on two concepts: creating an MVP and constant iteration. The purpose of an MVP is to get started on an implementation to solve immediate issues or concerns without doing the waterfall approach of “boiling the ocean,” risking getting nothing done because of analysis paralysis. The iterative approach indicates that governance is never a complete implementation and there should be a constant review and update of policies as the use of Azure grows and business requirements change. In other words, governance is not a one-and-done solution.


The process I will define today applies to all disciplines and is intended to limit the number of solutions to implement while creating a minimum solution that addresses the primary business risks. The recommendation is to target no more than two or three policies or risks to focus on per discipline to limit the scope. If all five disciplines are reviewed, that would be 15 solutions at maximum — which is large enough to get a substantial implementation, but prevents trying to solve the problems of the world.

The MVP is the combination of these solutions. The MVP would become part of your “landing zone,” which should then be included in every deployment, whether it is DevTest, QA or production. A landing zone is the minimum configuration or reference architecture that you need with settings that address technical and business requirements.

The Process

The process for applying the disciplines involves understanding the risk tolerance of a required policy, determining the metrics and indicators that call out those issues and developing and implementing solutions that ensure compliance with the policies and mitigate the business risks. Specifically, the steps are:

  1. Create actionable policy statements.
  2. Understand business risks.
  3. Define metrics and indicators.
  4. Establish policy compliance processes.

This is an iterative process that would be done for each discipline. There are templates that are used for these statements and solutions that can be used again and again as more needs are identified. Below is an example of the process flow for developing the MVP using all five disciplines.

CDW Governance Process CDW Governance Process

The process starts with a governance benchmark analysis using the Microsoft Governance Benchmark tool. The tool is used to start the conversation and get an understanding of where the priorities are and how they compare against the industry; this helps guide the conversation during the discipline discussion.

The next step is to pick a discipline and develop one to three policy statements. These are actionable statements that are guides for addressing the specific risks that will be identified during this process. Each one should include the statement, business risks and design options. Examples of a policy statement for cost management would be budget overruns:

  • Policy Statement: Deviations of greater than 20 percent are a concern
  • Business Risk: Concern that the annual commit will be exceeded
  • Design Options: planned vs. actual spend could be accomplished by Azure Cost Management

The specific details on this example by Microsoft can be found here.

Policy Statement: The policy statement is a specific statement of what policy you are concerned about and need to adhere to. It is a statement that is related to the specific discipline and outlines where the focus of this portion of the MVP will be. Here is an example in the templates provided by Microsoft:

Overprovisioned Assets: All deployed assets must be registered with a solution that can monitor usage and report on any overprovisioned resources.

This statement is then dissected to a deeper understanding of what is involved, what the priority is and how to ensure compliance to it.

Identify Risk and Tolerance: Once the policy statement is agreed to, the discussion moves to the risk of noncompliance. For example, the risk for Overprovisioned Assets could be the concern of paying too much for unused assets. Depending on the budget process, the tolerance for this could be high, medium or low. For example, if there are strict budgets and the CFO has given explicit instructions that there is concern about overspending, then the tolerance for this is low. However, if budgets are flexible, but monitored, then the risk tolerance could be medium or high. Determining this will help with the priorities during implementation of solutions and could impact the type of solution designed.

Metrics and KPIs: The next step is to review the risk statement and determine how it will be measured. An indicator, or KPI, could be, in this case, monthly spend exceeds a certain threshold — say, $1 million. This is the KPI that needs to be kept under control to address the business risk. Key metrics could be annual spend, monthly spend, etc. Specific indicators can be documented that could cause changes in policy statements. This is the iterative approach since many factors could cause a reappraisal of current strategies and plans. Examples of indicators that could cause readjustment are new releases of software that cause an increase in consumption, or if, despite implemented solutions, monthly spend increased beyond estimates ($1 million). This could indicate that the initial policy statement was incorrect or that the business situation changed since this initial implementation.

Compliance to Policy: This gets to the heart of the governance process. It will do no good to document all the above statements if there is no way to assure compliance to the policies outlined. The compliance aspect is a combination of people, process and technology. For example, the governance team could initiate a process where they discuss the risks of core cloud costs with business owners. Deployment planning is another process that could review deployment strategies, document standards and understand planned deployments with estimated costs.

Tools such as ongoing monitoring using Azure Cost Management (ACM) could be a method for monitoring spend. Triggers and enforcement actions, using ACM Alerting, could be initiated if current spend is approaching 20 percent of budget (though implementing a budget itself is probably a mandatory option). There are many ways to achieve compliance. The amount of effort depends on the risk tolerance of the specific policy statement.

Tools: It is no mistake that the tools section is last. The methodology focuses on the risks to the business and developing policies and plans, and less about tools. Too many times, the tools become the focus and are implemented without real thought as to whether it adds value or not. Tools are important; each discipline has its own set of tools that help with the compliance of a policy. Cost management will usually use some form of Azure Cost Management and Billing, Azure Policy and Azure Advisor. Third party tools, such as CloudHealth, are also options.

Policy Statements and Backlog

This process should be documented in something called Policy Templates (Microsoft) or what we at CDW are calling Guides (CDW). There will be one document for each discipline, rather than an all-encompassing document. This is done so that there are artifacts for future use when triggers indicate that a review of policy statement is in order. This document is intended to be a working document to constantly grow and be a record of what the policy statements, business risks and other metrics have, or will be implemented.

The final work product is an MVP and backlog document. This is a combination of the disciplines and denotes what is recommended as the initial implementation of governance for a landing zone that should be implemented. It will also include any backlog items that came up for discussion but were tabled or put in backlog. It should include an estimate of time to develop and implement. This way you not only have a record and process for iterating each discipline, but you also have the beginning of a backlog to constantly iterate against.

Governance is a journey, not a destination. It is not simply implementing best practices and then it’s done. It is a constant review of your business, an understanding of how the cloud is being used, and whether the results meet your goals and objectives. The cloud changes constantly, so even if your business is static, and your implementation is static, there could be alternatives available today that were not there yesterday. As the cloud and your business change, so should your governance process and policies. That should lead to enjoying the benefits of cloud computing without as much hassle.