Cloud Adoption

Common_Cloud_Adoption_Missteps_PT3_2-1 Cloud Adoption Missteps Part 3: Governance and Organization

Welcome back to the final part of our 3-part Cloud Adoption Missteps series where we will be going over some of the errors and mistakes that take place during the governance and organization stages of the Cloud Adoption Framework for Azure. The first two parts of the series gave insight into earlier steps in the framework process, what they entail, and common cloud adoption missteps that can arise. To read an overview of what the Cloud Adoption Framework for Azure is and some of the antipatterns that take place during the first 2 stages of the framework, click here. If you would like to check out the second part of the series, “Common Cloud Adoption Missteps Part 2: Adoption and Management Stages”, you can read it here.

The conclusion of the Cloud Adoption Missteps series will cover antipatterns in the governance and organization stages. We will share what goes on during these steps, common antipatterns, and some strategies to mitigate the antipatterns that may arise. 

Governance Stage

Taking organizations to the cloud is a complex yet highly rewarding process as we’ve clearly outlined in the past. However, it’s important to note that constant cloud governance must take place to create a strong cloud governance foundation. To learn some of the governance methodologies for the cloud, read this guide from Microsoft.

There are 3 main antipatterns that take place during this stage in the Cloud Adoption Framework: misunderstanding responsibility, straying too far from the compliance framework requirements, and using custom compliance.

Misaligned Shared Responsibilities

Though the Cloud Adoption Framework for Azure is well-defined and clearly laid out, it can still be difficult to recognize where your organization’s responsibilities end and your cloud service provider’s (CSP) begins. Oftentimes that line gets blurred and that’s when the problems begin. Whether it’s security concerns or non-compliant servers, it’s important to address those issues right away. 

By building a “readiness plan”, you and your CSP can find that middle ground that works for everyone. A readiness plan focuses on capturing concerns, identifying gaps, and partnering with other teams to overcome this hurdle. For a more detailed look into what a readiness plan entails, check out Microsoft’s guide here.

Inaccurate Security Assumptions

It’s easy to assume that the move to the cloud is automatically a security upgrade, and that’s not necessarily wrong; however, it’s not a great idea to assume that out-of-the-box solutions provide security. Focusing on adhering to the compliance standards for Azure and using Azure portal ensures more stable security. Learn more about the Azure Security Centre here.

Custom Compliance or Governance Frameworks

The third and final antipattern that takes place during the governance stage is the use of a custom compliance or governance framework. Integrating these custom frameworks is very time consuming, especially when translating them to cloud settings. This will significantly slow down the cloud adoption process. Instead, rely on existing frameworks while making that transition to the cloud. It allows for ease, simplicity, and measurability of security settings. After making that transition is a good time to look at custom frameworks.

 

Organization Stage

The final stage in the Azure Cloud Adoption Framework is the organization stage. It looks at managing and organizing people (teams), structure, and the roles each person plays. Oftentimes, customers face cloud adoption missteps during the organizational stage due to a variety of aspects. The antipatterns that we will cover are 4 of the biggest missteps that often take place: utilizing IT as a cost centre, platform developing without approval, outsourcing core business functions, and hiring technical decision makers rather than cloud engineers. For more information on the organization stage in the cloud adoption framework, check out this overview by Microsoft.

Treating IT as a Cost Centre

When organizations or employees start to see IT as a cost centre rather than an enabler, pushing growth and success, there is reduced motivation in the long run. IT feels discouraged and along with that, management feels as though IT is slow and inefficient. 

Rather than viewing IT as a cost centre, try and see it as an enabler. By viewing IT as an agent with operating expenses, transparency, accountability, and optimization as are all maximized.

Investing in New Technology Without Involving the Business

Different departments all have separate functions to focus on. So it’s easy to forget that there are other business units that could be affected by even the smallest decisions. For example, if IT fails to consider business units while making design and structural decisions, it can lead to platforms that aren’t optimized or properly functioning for the business units. This leads to frustration and poor/ineffective adoption of the new platforms.

Instead, involve business units in the decision-making process. This eliminates the risk that those teams will not be able to implement or adopt new platforms. It takes into account the preferences and needs of the business units and creates a more cohesive platform that works for everyone. 

Outsourcing Core Business Functions

When running an organization, it’s easy to get caught up in outsourcing business functions to managed service providers (MSPs) and consulting partners. These partnerships can give way to a lot of exciting possibilities. However, it’s crucial to make sure that your company doesn’t become dependent on providers.

Keep critical design areas within your company, regarding subjects like risk, compliance, identity, and government. This ensures that your organization won’t become dependent on external providers, and instead will use them to speed up other important business processes.

Hiring Technical Decision Makers

Finally, the last cloud adoption misstep that we are focusing on in this series is the choice between hiring technical decision makers (TDMs) versus investing in cloud adoption engineers. TDMs are often a great way to get your cloud adoption framework up and running. However, a successful cloud adoption journey needs people with deep technical knowledge such as cloud engineers. 

Because cloud engineers are crucial for creating successful landing zones and cloud automations, they can help you realize the true potential of cloud adoption and the benefits that it brings. TDMs can always be brought in for decision-making later in the process, but cloud engineers are the ones with rich engineering knowledge.  

Conclusion

This article was the final part of a three-part series focusing on common cloud adoption missteps while using the Azure Cloud Adoption Framework. We hope that you gained a detailed overview of the many stages of the cloud adoption process and what they entail. As well as this, we hope that you are now aware of the antipatterns and cloud adoption missteps that can be easily remedied. 

Many organizations find it beneficial to work with a Cloud Solution Provider (CSP) when undergoing cloud adoption. Read our article on the benefits of using a CSP.

If you’re interested in having Optimus as your CSP, you can reach us at: info@optimusinfo.com