In the previous articles in this series, we've introduced the concept of a cloud governance framework. We also explained how you could start to implement it based on the example of simple cost control mechanisms and rules. Today we 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 organisation. 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, we 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 SoftwareOne for our internal and project resources. We 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.
What is our business case?
In our cloud, we host internal resources like applications, databases, data warehouses, and dashboards. We are a data-driven organisation, 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 organisation. 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 organisation) 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 organisation's objectives. 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 SoftwareOne 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 organisation 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 in the company. 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).
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 SoftwareOne Methodology."
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.
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.
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 organisation. 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:
- Azure ARM and Azure Blueprints for resource definition and deployment
- Azure Policy for setting up constraints on resources being deployed and how these are configured
- And finally, Azure DevOps for practical resource deployment and automation.
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.
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.
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.
Author
