In my previous articles in this series, I’ve introduced a cloud governance model concept and explained how you could start to implement it on the example of simple cost control mechanisms and rules.
Today I will explain how, in this model, you can approach resources consistency and at the same time how your cloud governance model and mechanisms you use there can directly support the business outcome of your organization.
This post is third in the series of articles on cloud governance and its implementation. You can find my previous entries in this series here:
- Cloud-first? Plan First! Why You Need A Cloud Governance Model And Where To Begin
- Cloud Governance Implementation: A Practical Take On How Predica Manages Resources And Costs
The previous article focused on risk control and cost management as one of the aspects of the governance model. Just as a reminder: in our process, we need to focus on following five key areas:
- Cost management
- Security baseline
- Identity baseline
- Resource consistency
- Deployment, auditing, and monitoring.
Today I will focus on a case study that will show how you can implement two later ones – Resources Consistency and Deployment. Instead of only showcasing how we are doing it at Predica for our internal and project resources, I will also show how we approach the business side of requirements from the definition of the goal to resource deployment.
Your IT organization and cloud model can directly support your business goals.
Actually, it probably is like that at the moment. You need to think about it and deliberately apply it.
Again, let’s start with a business case
What is our business case? In our cloud, we host internal recourses 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 consists of:
- Dynamics CRM which defines projects we are already running
- Individual calendars with time entries created by every employee along with respective project codes (coming from CRM)
- The process to harvest these time entries and collect them in the internal data warehouse
- Data warehouse where we process and calculate metrics for our time tracking system in tabular model
- Set of 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 requires development and deployment of changes to our environment.
Development and deployments are the two elements which are always hard to manage in every organization. We were no different. So how we are doing nowadays and how we apply our business requirements directly to our Azure deployments?
Deployments and resources consistency
There is one key element you need to address to make sure you will not suffer from deployment burnouts, and you won’t have resources firefights in Azure – DEPLOYMENT AUTOMATION!
In our case, our internal IT operations (which formed along the way within the organization) is using Azure ARM templates and Azure DevOps to manage resources and deployments.
Azure DevOps is our primary tool for gathering users’ stories based on business requirements, managing backlog of our team, manage our code base, and deploy our resources. We came a long way from using on-prem VSTS to Azure DevOps with automated deployment pipelines, with the migration of all code repositories to Git in the meantime.
Let’s track how we are defining our business requirements, map them to work items in Azure DevOps, develop and deploy them through automated pipelines to the resources in the cloud.
It all starts with a goal
At Predica, we use OKR methodology to manage our organization objectives. I spoke about it in one of our vlog episodes.
Every quarter, we set Objectives for each department. Then we add Key Results, and our objectives and the way to measure them are born – in short, OKRs. All actions taken within Predica Practices organization are aligned with our OKRs.
Why is it important? Because the IT department 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 particular actions in our development and resources management must be aligned with business objectives.
In our case, OKRs are defined in 7Geese (the app we use to manage our objectives) and are public and known for everyone.
Here is an example of how one such OKRs is defined – (its ID is 369516, we will get back to it and explain why it is important).
Time for actions – OKRs to Azure DevOps
Objectives (OKRs) defined at the company level are translated into Epics and Features in our Azure DevOps environment. For each OKR which requires some work to be done in our environment, our IT department aligns Azure DevOps backlog with OKRs.
We have Epic in Azure DevOps where we manage our work related to OKRs. It is done very quickly with tags, where Feature in Azure DevOps is tagged with the ID of OKR to which it refers. Now we are getting back to our OKR with ID 369516, which translates to Feature definition: Each Project runs according to Predica Methodology.
Our IT department breaks it down to the Feature into User story level, which translates into development and deployments in our environment. Each User Story is tagged with its 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 also have another Feature which also is derived from our OKRs which is a requirement for our internal tools to be managed through CI/CD pipeline (where you also have a user story for our Tabular).
How it relates to the governance model?
So, how exactly it relates to cloud governance model? If you get 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.
It is what we achieve with our OKRs approach and translation of business goals into Azure DevOps items.
Our business goal is to have all our projects run according to our methodology. It assumes using CI/CD tools for resources deployment to avoid manual deployments and resources inconsistency.
To address the need for resources consistency across all your Azure deployments, you can use the following tools:
- Azure ARM and Azure Blueprints for resources definition and deployment
- Azure Policy for setting up constraints on resources being deployed and how these are configured
- Azure DevOps for practical resources deployment and automation.
We use those tools, and mainly 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 for your business goals!
To make it practical, let’s get back to our OKR related to the tabular model. Our tabular model is built on Azure stack. It serves as our main data source for our analytical tools and self-service Power BI dashboards. It combines several data sources, including our timesheets and financial data.
According to our model, we don’t want to risk that anything in it will go sideways during the deployment, and someone will play manually with it.
Thus, based on the business objectives set above, we have translated our OKR directly to Azure DevOps tasks 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 full flow through Dev and Test environments with the build and final deployment into the production environment.
All of it is being done in an automated way to comply with our governance model for cloud resources for automation and resources consistency in our environments.
From Azure DevOps perspective, our business goals stakeholders can monitor the current status of these deployments with dashboards and reports.
Overall, the project status for our internal IT operations looks like that:
And particular build and pipelines for specific resources:
Cloud governance is not academic tasks – it is full of hands-on experience!
As you can see, cloud governance sets directions and rules for how we operate our cloud environment. It is aligned fully with our business goals as we derive our rules from business rules and objectives set at the company level.
It doesn’t mean that it’s just a static document with lots of theory and guidelines. It is a real-life implementation with practical usage, where your business goals and derived cloud governance rules set the direction on where to head with technology and how to apply it.
Based on this direction we can implement different technologies and tools – in our case, we bet on Azure DevOps as a standard way of doing things (not only for this reason but we will cover it in the future – stay tuned!).
Now it is time for you to start your journey to cloud governance, and at its end you’ll gain control over your cloud environment!
Remember – IT operations and cloud resources don’t have to be set aside from the business side of your organization. You work together towards the same objective, and you can use tools and techniques we showed here to make it all happen!