In my recent article I introduced the concept of cloud governance models and explained why you need one. Today I will use our own example to demonstrate how you can put it into practice!
This post has originally been published on May 16, 2019. It has since been updated for better readability.
Let’s quickly recap the key points from last time (although I encourage you to read the entire post). The main issue was that your cloud governance model and deployments need to address three high-level aspects:
You need to define the correct states and identify business objectives, mostly encompassing the following:
Based on these, you can apply technology solutions and choices in the following five key areas:
That’s about it in terms of the concept. But let’s make it practical. Today, I want to share with you a simple example of the above approach that we often use in relation to cloud governance implementation. Let’s start with Azure resources for our projects and customers.
In your case, it might be internal resources. You might want to allocate the cost to business units and departments, or a project. Another example could be that your source of projects is not a CRM but an EPM solution.
In all these examples, think about the business objectives and what you want to achieve, then translate them into policy or governance statements. The last step is to implement those in a technology stack.
As an outcome, you get clear cloud resources with proper management, which makes the adoption process easier.
Let me show you how you can get started with cloud governance implementation using a relatively simple process.
We host all our infrastructure and resources in Azure. They might be hosted as internal resources, allocated either to the project or the customers as part of us being Tier 1 CSP partner for Microsoft.
As you can imagine, with 250+ employees and several hundreds of customers and projects, things might quickly get out of control in terms of cost and resource management.
However, as a data-driven company, we want to be able to track full resource assignment which translates to several business objectives.
Both reasons above translate into a few risk related objectives.
These are the business objectives defined by our resource policies as part of our cloud governance implementation. As you can see, we have not delved into any aspects of technical implementation or services in defining those objectives.
Now, let’s translate all this into a practical example.
If you know Azure or other cloud services, you can probably come up with some kind of a solution right away. But for those who are interested or who have never done this before, let’s see how we turned those business requirements into a practical implementation of cloud governance.
In our case, all resources need to be allocated to a project code that corresponds to one of our business or internal activities. The first requirement is to have a way to identify resources assigned to a specific customer and projects, and the person responsible for them.
You can take a different approach here from the resource structuring point of view:
In our case, all project codes are generated in Dynamics 365 when we start a project. They include two assignments: the customer, for whom we’re delivering the project, and the Project Owner responsible for delivery.
To be able to identify which resources are assigned to the right project we require that every resource group (and resources within it) are tagged with tags in Azure with three key elements:
Once you have this set, the next step is to make sure that you apply it consistently to all the resources you have to manage. Here are your options:
We had a small challenge when setting up our Azure Policy. Some of our resources are created ad-hoc for testing purposes or quick and dirty PoC validation using Azure Portal.
Some time back, implementing a strict requirement for resources to be tagged with Azure Policy would mean that we blocked resource creation via portal on an ad-hoc basis. The portal was not always providing the tagging option for all the resources.
Also, our requirement was not that all resources had to be created with tags, but that we could eventually identify and assign all resources to the correct project and customer (via project).
We settled on automation, with a simple but working solution:
A note for our Azure-savvy friends – yes, we are going to update this process to Azure Policy!
We now have our resource correctly tagged and identified. The next stage is to make sure that it is correctly handled after the work on a project is done.
Again, here comes automation. Our business process in Dynamics CRM maintains project status. Based on this information, our automation updates the project status tag on resources.
Upon project close, the Project Owner is notified that they need to archive it to avoid additional costs and compliance issues.
Why not automate the last phase and archive resources right away?
It might be that the project is in hyper-care period. In that case, we might need to restore it to an up-and-running state quickly. Alternatively, we might be providing ongoing support or managed services for this customer, and so we keep it for testing and validation purposes.
This knowledge stays with the Project Owner, and they make a decision based on the business case. With our governance process, we make sure that:
One thing to note is that in your solution, you don’t always have to go with the latest and greatest in the technology stack.
Azure-savvy people among our readers will quickly notice that fact. For some scenarios we wouldn’t use services or patterns as solutions.
Additionally, there is the iterative nature of cloud governance: you have to assume that it is a cycle. You will have to review your business objectives and how you address them regularly, then apply changes and improvements.
It is the result of:
Do not assume that what you have implemented will stay there forever – plan regular reviews and updates to your governance processes and tools.
It sounds complicated. But, how the solution looks in practice and how it addresses our business objectives is much simpler than it may seem for business users.
We deploy the required resources in Azure to one of the subscriptions (depending on the model, it might be an internal subscription or one dedicated for the customer – CSP model).
Each subscription follows our strict naming convention and all resource groups also follow a naming convention defined in our policies.
In those subscriptions, we have resource groups tagged with three pieces of information: Project Code, Project Owner and Project Status. Here is an example:
Our internal automation keeps the information up to date.
Based on the billing details obtained from a billing API, we pull all the resources every month and allocate them to each business activity (project). These details are blurred here to keep project information confidential (sorry!).
The information connects to the relevant project. It is visible to each Project Owner. If a customer pays for those resources, it is also visible to the customer. The data is available through Excel and Power BI.
When the project closes, the Project Owner receives a notification to decide what to do with the resources.
This simple process meets our business objectives in several ways.
Each resource is assigned to our business activities (in case you’re wondering – we treat internal projects the same way).
When a project ends, we notify the person responsible to mark the resources to be closed. The system will follow up regularly to make sure there are no omitted resources.
Each Project Owner and customer have clear visibility of resource consumption through a smooth self-service flow.
We can assign and quickly identify all resources related to every customer. If required, we can promptly take action on any resource related to a given customer or project (take it down, report actions or access).
We mitigate financial risk by providing clear cost assignment and visibility (of course, this is not all that we do in this area ?). We also improve compliance and reduce data access risk through clear identification of resources and their ownership.
You can check out the next article, where I show you how you can support your cloud governance implementation with another critical element: business-driven deployment and operations for automation and resource consistency.
If you need help on this journey, get in touch with us. We will be happy to assist you.
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...
Sometimes it feels like I'm pushing too much with security and software development, but then you prove me wrong. Rec...