Access Governance Implementation How Can Automation Help Out With Cloud Governance?

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:

• Business
• People
• Technology.

Be clear on what you want to achieve

You need to define the correct states and identify business objectives, mostly encompassing the following:

• Performance: meaning how your cloud adoption will translate to performance in terms of your business goals
• Cost optimization: i.e. streamlining and control of costs related to cloud operations
• Compliance: how to meet requirements for your regulations (be it internal or external)
• Security: how to keep your data and infrastructure safe and secure
• Risk management: what is your risk model and what risks are you trying to mitigate with your cloud deployment?

Based on these, you can apply technology solutions and choices in the following five key areas:

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

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.

What’s in it for you?

By the end of this post, you should be able to translate cloud governance from concept and tools into something more tangible and applicable to your organization.

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.

Business case – let’s define it!

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.

Cost optimization

• In our model, we need to be able to assign each resource to a specific project or activity, to make sure that we can track the overall cost assigned to delivery. In case of customer resources, we want to ensure that we are not overcharging our customers.
• We want to make sure that all data for completed projects is properly archived and not consuming resources.
• Additionally, we need to provide each Project Owner with clear visibility of the cost of resources consumed by a project.

Compliance

• We need to be able to identify all resources related to a given project and customer to correctly manage access rights and be compliant with our legal obligations to the clients.
• We also need to be able to point out all the resources hosting data for a given customer in case we need to archive it, or indicate where such data is stored within our Azure resources.

Risk management

Both reasons above translate into a few risk related objectives.

• We want to track all project data to mitigate the risk of budget overrun and a high cost of consumption of Azure resources
• We need to minimize the risk of leaving customer data behind after a project concludes. More specifically, scenarios where we can’t find the data or need to shut down the remaining project infrastructure.

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.

Solution – let’s find it!

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.

What were the requirements?

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:

• Split project resources across separate subscriptions for each project or customer
• In case of a single subscription hosting multiple projects, you can split it by resource groups.

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.

Assigning resources

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:

• Project Code – simple text code coming out of our CRM as part of project initialization
• Contact information for Project Owner – i.e. email address
• Project status – active or closed.

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:

• Put automation in place to make sure that you have the correct tags on all resources
• Implement policies using Azure Policy and enforce them upon resource creation.

A note on Azure Policy

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).

How did this process solve our case?

We settled on automation, with a simple but working solution:

• Our service desk gets a request to create project resources. Each request contains valid information, and resources include tags from the start
• Where resources appear outside of the process or need later modification:
  • An automated job scans all the resources on a scheduled basis. If there is a new resource group or an existing one without proper tags assigned, it is reported to our IT/Consulting department
  • Once the system finds a new resource, our IT works with Consulting to identify where it belongs. Then, they provide a proper project code
• Once the project code is assigned, automation keeps project data in sync with our CRM. For example, status and project owner contact information (email).

An example solution design for our project setup process

A note for our Azure-savvy friends – yes, we are going to update this process to Azure Policy!

What happens when a project ends?

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:

• All resources are correctly identified
• We can assign them to a specific customer and person responsible
• We can allocate the cost of these resources to a particular business activity.

Why automation? It is not at the cutting edge of cloud tech!

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:

• changing business objectives and requirements
• evolving technology landscape and services
• changes in your processes and how your business operates.

Do not assume that what you have implemented will stay there forever – plan regular reviews and updates to your governance processes and tools.

Let’s see it – what is the outcome?

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:

Example project tags in Azure

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!).

A sample report on resource costs

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.

Sample email notification of project close

Why does it work?

This simple process meets our business objectives in several ways.

Cost optimization

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.

Compliance

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).

Risk management

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.

Ready to set up your own cloud governance implementation?

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.