Azure Devops Governance How To Support Cloud Governance With Azure DevOps: A Practical Example

In the previous articles in this series, I’ve introduced the concept of a cloud governance framework. I also explained how you could start to implement it based on the example of simple cost control mechanisms and rules.

Today I will demonstrate how you can approach resource consistency. We’ll see how your governance model and mechanisms can directly support the business outcomes of your organization.

Key points
  • How to use technology to accomplish your business goals?
  • How can you use Azure DevOps for achieving your objectives?
  • What should you keep in mind when developing your cloud governance model?

This post has originally been published on Jun 06, 2019. It has since been updated for better readability.

Last time we focused on risk control and cost management as some of the aspects of the governance model. Just as a reminder: in our process, we need to focus on the following five key areas:

  • Cost management
  • Security baseline
  • Identity baseline
  • Resource consistency
  • Deployment, auditing, and monitoring.

This time, I will describe a case study showing how you can take care of the two latter aspects – resource consistency and deployment. You’ll see how we do it at Predica for our internal and project resources. I will also demonstrate how we approach business requirements, from defining the goal to deployment.

Your IT structure and cloud model can directly support your business goals

Actually, it probably is like that at the moment. But you need to think about it and deliberately apply it. Again, let’s start with a scenario.

Join our community to get practical advice from our CTO in a weekly newsletter! Sign me up

What is our business case?

In our cloud, we host internal resources like applications, databases, data warehouses, and dashboards. We are a data-driven organization, and we put a lot of effort into our operational infrastructure and applications.

As in many such cases, it consists of a lot of moving parts. To name just one simple example – our time management system comprises:

  • Dynamics CRM which defines the projects we are already running
  • Individual calendars with time entries created by every employee along with their respective project codes (coming from CRM)
  • A process to harvest these time entries and collect them in the internal data warehouse
  • A data warehouse where we process and calculate metrics for our time tracking system in a tabular model
  • Dashboards and reports available for users in Power BI.

As you can imagine, keeping up with all these inconsistent resources might be a bit of a challenge. Also, we have new business requirements coming in all the time, which require changes to our environment.

Development and deployment of changes are the two elements which are always hard to manage at any organization. For us, it’s no different.

A little background

There is one key element you need to address to make sure you won’t suffer from deployment burnouts, and that you won’t have to fight resource fires in Azure – deployment automation!

You have the entire resource consistency and deployment toolchain available on Azure.

In our case, internal IT operations (which formed along the way within the organization) use Azure ARM templates and Azure DevOps to manage resources and deployments.

Azure DevOps is our primary tool for gathering user stories based on business requirements, managing our team’s backlog, keeping our code base, and deploying our resources. We came a long way from using on-prem VSTS to Azure DevOps with automated deployment pipelines. We also migrated all code repositories to Git in the meantime.

Let’s track how we define our business requirements, map them to work items in Azure DevOps, and finally develop and deploy them through automated pipelines to cloud resources.

It all starts with a goal

We use the OKR methodology to manage our organization’s objectives. I talked about it in one of our vlog episodes which you can check out below.

How to work with the Objectives and Key Results system?

Every quarter, we set Objectives for each department. Then we add Key Results, and consequently a way to measure our goals – and that’s how we get OKRs. All actions taken within Predica Practices and other departments are aligned with them.

Why is it important? Because IT doesn’t exist next to the business, it is not a service provider for industry; it works together with the rest of the organization to deliver the objectives.

It means that even our development and resource management must be aligned with business goals.

In our case, OKRs are defined in 7Geese (the app we use to manage our objectives) and are public and visible to everyone. Here is an example of how one such OKR is defined (its ID is 369516, we will get back to it and explain why this is important).

An example objective in 7Geese

An example objective in 7Geese

Time for action – OKRs to Azure DevOps

Objectives (OKRs) defined at the company level are translated into Epics and Features in Azure DevOps. For each OKR which requires some work to be done in our environment, our IT department aligns the backlog respectively.

We have an Epic in Azure DevOps where we manage our work related to OKRs. It is done very quickly with tags. A Feature in Azure DevOps is tagged with the ID of the OKR to which it refers. Now we are getting back to our OKR with ID 369516, which translates to this Feature: “Each Project runs according to Predica Methodology.”

OKR backlog in Azure DevOps

OKR backlog in Azure DevOps

Our IT department breaks it down to a Feature at the User Story level, which translates into development and deployments in our environment. Each User Story is tagged with its relevant business and technology area.

Here you can see that this particular Feature breaks down to several tasks, where one of them is related to the development of our timesheet Tabular model.

Feature breakdown in Azure DevOps

Feature breakdown in Azure DevOps

We have another Feature, also derived from our OKRs, which is a requirement for our internal tools to be managed through a CI/CD pipeline. There you also have a User Story for our Tabular.

Feature breakdown for another OKR

Feature breakdown for another OKR

How does it all relate to a cloud governance model?

If you go back to our first article in the series, you will know that all our actions should be driven by business objectives and goals set by the organization.

This is what we achieve with our OKR approach and translating business goals into Azure DevOps items.

Our business objective is to have all our projects ran according to our methodology. It posits using CI/CD tools for resource deployment to avoid manual implementation and resource inconsistency.

Note: to address the need for resource consistency across all your Azure deployments, you can use the following tools:

We use those tools, and primarily Azure DevOps, to make sure that our resources are deployed in an efficient and consistent way, to meet our business objective.

Simple but powerful!

Put Azure DevOps to work!

To make it practical, let’s get back to our OKR related to the Tabular model. The model is built on Azure stack. It serves as our main data source for our analytical tools and self-service Power BI dashboards. Additionally, it combines several data sources, including our timesheets and financial data.

According to our framework, we don’t want to risk that anything goes sideways during deployment, or that someone will change it manually.

Thus, based on the business objectives set above, we have translated our OKR directly to an Azure DevOps task and configuration of our deployment pipeline for the Tabular model.

Here is a high-level diagram of our deployment model for this particular piece of our operations.

Part of cloud governance model: developing a deployment model in Azure DevOps

Our deployment model in Azure DevOps

As you can see, we maintain a full flow through Dev and Test environments with the build and final deployment into the production environment.

All of it is done in an automated way to comply with our cloud governance model in terms of automation and resource consistency.

From the Azure DevOps perspective, our business stakeholders can monitor the current status of these deployments with dashboards and reports.

Overall, the project status for our internal IT operations looks like this:

Project statistics

Project report

And here are the particular build and deployment pipelines for specific resources:

Project deployment pipelines

Project deployment pipelines

Cloud governance is not academic – it is a hands-on experience!

As you can see, cloud governance sets directions and rules for how we operate our cloud environment. It is fully aligned with our business goals, as we derive our rules from business policies and objectives set at the company level.

This doesn’t mean that it’s just a static document with lots of theory and guidelines. Rather, it is a real-life implementation with practical usage, where your objectives and rules set the direction on where to head with technology and how to apply it.

Based on this approach, we can implement different solutions and tools. In our case, we bet on Azure DevOps as a standard way of doing things, although it’s not the only purpose we use it for. You can read more about it in another series, starting with this article.

Sign up for Predica Newsletter

A weekly, ad-free newsletter that helps cutomer stay in the know. Take a look.


Want more updates like this? Join thousands of specialists who already follow our newsletter.

Stay up to date with the latest cloud insights from our CTO