Getting started with the Microsoft Cloud Adoption Framework for Azure can be quite overwhelming. And I can not stress this enough: It doesn’t have to be.
Even though it can feel like the framework is mainly written towards enterprises and end-customers, it doesn't mean that Microsoft Partners, Managed Services Providers or individual contractors are not to gain from the Cloud Adoption Framework. In fact, the Cloud Adoption Framework is for everyone. Even even if only read up on it, the framework will provide you with thoughts and insights on how to further improve your practice.
It takes a good understanding of what your customers want and need to successfully engage with them. The Cloud Adoption Framework can help you do just that. It will help you ask the right questions and gather valuable input, understand your customer, predict costs and provide your teams with valuable information. Last but not least; it will help you structure your design process, migration strategies and managed services.
Additionally, as it so happens to go with processes and frameworks. If you run through them a couple of times you will gather valuable information to learn from. What if 90% of the customers in a specific industry need a similar infrastructure? Hello standardization, goodbye lengthy design sessions.
This blog is intended to share a view, structure some thoughts and look at a way to go about using the Cloud Adoption Framework as a Managed Service Provider. What I'm trying to illustrate is that you can map the framework onto your MSP processes and you can and will benefit from using the framework. I have tried to provide some examples of how the average Managed Service Provider goes about their business and how this relates to the different topics of the Cloud Adoption Framework.
Table of Contents
The Microsoft Cloud Adoption Framework
Improvise: Mapping your business onto the Cloud Adoption Framework by example
Adapt: Overview / Putting things into perspective
Considerations when implementing
The Microsoft Cloud Adoption Framework
The Microsoft Cloud Adoption Framework is currently in preview but already has a lot to offer. And if you have feedback; who's stopping you from contributing? :)
As documented by Microsoft (here): “The Cloud Adoption Framework is the One Microsoft approach to cloud adoption in Azure, consolidating and sharing best practices from Microsoft employees, partners, and customers.”
But what does that mean? If you or any of your customers are just getting started with adopting the Microsoft Azure Platform (though the concept applies to any public cloud) or, if you're looking to improve your cloud adoption and processes; this is probably a good place to start. The challenge here is that as a service provider you have to look at the Cloud Adoption Framework from a different perspective. You're not mapping it onto your own technical environment and processes. You are providing the customer with a service where you will go through the topics of the framework with them.
But how will the framework help you as a service provider? You're defining a process that you can go through with and for your customer. It will help you engage with new and existing customers by leveraging the best practices that are already documented or building on top of them by adding your own best practices.
You can manage expectations on both sides as you're both looking at the same set of rules and guides: The Cloud Adoption Framework.
Let's look at the average sized service provider and keep it simple. You would typically see at least the following roles:
- Architects (or some consultants who design environments)
- Consultant (implementation and migration specialists)
- Support Staff / Managed Services
- Sales team
Of course, one could argue that companies have more roles than that or that one person could have multiple roles. But like I said, let's start simple.
Now let's look at how (in my experience) many companies go about implementing a solution for customers. In general, you would see the following steps:
- Sales Process (Sales Team and perhaps an Architect)
- Architecting the design, capacity planning and cost indication (Architect / Sales)
- Migration planning (Architect)
- Implementation (Consultant)
- Managed Services (Support / Managed Services Staff)
Now let's look at the Cloud Adoption Framework:
The Cloud Adoption Framework contains the processes that will guide you in defining the life cycle for your organization. We're talking about:
- Defining a strategy
To quote one of the introduction articles "This framework is designed primarily for cloud architects and the cloud strategy teams leading cloud adoption efforts. However, many topics in this framework are relevant to other roles across the business and IT." (https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/getting-started/migrate)
The key here is: Many topics in this framework are relevant to other roles across the business and IT
Let's see how this would fit the average service provider.
Improvise: Mapping your business onto the Cloud Adoption Framework by example
This really is a simple exercise but requires some improvisation. You want to start small so lets just take the topics of the framework and go through your design, implementation and management processes. You will find that for every step, you probably already have something in place.
If you go through the Framework you will find that a couple of executive summaries are provided as an introduction. providing you with context such as common motivations, different approaches to cloud adoption and migration and an explanation of the framework altogether.
As a managed service provider, who's engaging the customer first? Most likely someone from your sales team. And this is where cloud adoption starts, managing expectations and kicking off the right processes from the very start. Make them a part of the journey. It’s a common situation where a company is contacted and is persuaded to engage with a Microsoft Partner to further discuss the possibilities that a Cloud platform can offer them. Often the customer isn’t familiar with what platforms such as Microsoft Azure have to offer and maybe it has crossed their minds at some point, they never really went into details and sometimes they’re not even aware that the motivations to justify a move to the cloud are already there.
This is where the defining the strategy starts. Figuring out what the motivations are and what your customers want to achieve by adopting the cloud as a platform. Are you even going to be the best fit for that customer? And if you're not, how are you going to make sure you will be? This is what you want to know as early as possible in the process. Sounds like something for a sales team and have an architect tag along. And in reality, a lot of services providers are already doing this. As far as the framework goes. The stuff you want to check off your list are:
- Document the motivations
- Get clarity on expected business outcomes
- Business justification (business case)
- Choosing the first project (nobody likes the risk of big bang migrations)
As far as the adoption of the framework goes, don't worry if you're not checking all the boxes. You need to leave some room for improvement :) or maybe you're checking the box in another stage. But to get back to mapping this to the processes. Let's put Strategy in the Sales Team / Architect box for now.
Even though, Planning and Readiness are both separate steps within the Cloud Adoption Framework. It is very well possible that you are doing all this in a single process performed by a single team or individual. Depending on the size of your company and your customers you might want to separate these two.
The planning process is where a lot of average sized business will differ from the Cloud Adoption Framework best practices. Over the years they've developed a planning and design process that work for them. They're usually lean, to the point and targeted to convince the customer to hop onboard and start using your services. And then we have the size of the customer. Not everyone is waiting for lengthy process to document the digital estate, rationalize and map the solution to their business goals. Some just want to move to the cloud. Problem? Not so much, we're still talking about a framework here so adjust it to your needs. But it's good to have the tools in place for when you need them.
For me the planning process is all about "gathering intel" and starting to translate the business requirements into an actionable plan. How to start and what to think of is really well documented as "Cloud rationalization" (Rehost, Refactor, Rearchitect, Rebuild and / or Replace). Read up on them here: https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/digital-estate/5-rs-of-rationalization
Keep in mind that customers can have different workloads and you can go about each workload differently in terms of rationalization.
Planning requires information. And initially I like to gather at least the following from customers:
- Inventory and telemetry of current resources
- Dependencies within the platform (which components are talking to each other?)
- Technologies used (operating systems, development languages, deployment tooling)
- What hurts (capacity issues? limited functionality? Costs?) Basically: motivation.
- Compliance and regulatory requirements
- Security requirements
- Availability & Scaling requirements
Then we'll come up with a plan. And focus on rationalization. It's important here that you're honest with your customer. What's short term and what's long term. Are you going to rehost (or move and improve). Or are you dealing with such a legacy application that rearchitecting or even Rebuilding is a requirement?
Planning goes into the Architect box for me.
This is where most Architects will excel. You will start with the strategic inputs (and hopefully you were a part of that conversation), the rationalization and come up with an initial design, workloads and predict the costs of that design. The challenge here is making sure the design fits the motivation and the expected business outcome. That means your design can be focused on just a few workloads that are currently a pain point within customer organization or with a scalable design for all future business. It all depends on the strategy and motivation.
But you have additional stakeholders here: your managed services staff. Does the design fit your organizations best practices for governance and your managed services processes or do you need to adjust? Either way, as an architect at a Managed Service Provider you have three main stake holders to take into account: the customer, those who will perform the migration and those that will manage the environment. The Cloud Adoption Framework illustrates this very well and documents this as "Organization Alignment" (https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/plan/initial-org-alignment - Initial Best Practice Structure).
But if you want to scale your business you don't always want to go back and forth within your organization and just focus on the customer itself. This is where standardization in your designs can be quite the help :)
And when your documenting your design and the migration strategy think of your peers; Someone has to deploy this design and perform the migration. Could be you or one of your consultants. You want to take into account at least the following:
- Has someone deployed a similar designs before and are the skills required to do so present?
- Do you have standardized templates for a large part of your design or do you need to take into account extra hours / days for developing standardization or manual deployments?
Finally, you'll come up with a design, a plan and a financial picture.With the results, you go back to your sales team and engage with the customer.
We'll put this in the box of the Architect with recurring feedback from the consultants and managed services team.
The Cloud Adoption Framework wouldn't be much without a Cloud Adoption Plan. The framework makes a clear distinction between Migration and Innovation. We'll focus on Migration for now as this is what most people are doing. When you're progressing through multiple iterations of the framework with a customer, Innovation will become a topic you need to address.
An adoption or migration plan should (in my opinion) contain your best practices for migration. Even better, you take these best practices into account in each previous stage. If your migration best practice for rehosting Virtual Machines means using Azure Site Recovery then you probably want to get the information required to do that as soon as possible to determine if this is even a viable scenario.
Either way, for me an adoption plan should contain any of your migration strategies that have been proven and tested in the field. If you don't have these then scaling your business can becoming challenging.
There will always be scenarios where you don't have a plan that fits the requirements but you should be able standardize most of it. And, if you don't have a scenario readily available (maybe you've never re-architected a solution; The framework will provide you with best practices and help you get started.
For me writing an adoption plan requires the following:
- Proven migration practice
- Continuous feedback from your peers that are implementing the solution (look back on how it went)
- Continuous feedback from your peers that are managing the solution (managed services). They know much more than you'd expect.
Look back at migrations, ask everyone that was involved how it went and have them share experiences this is valuable input for continuous improvement of your best practices and migration scenario's. Adoption goes into the box of the Architect as well, with a strong connection to consultants and managed services staff for feedback.
The same goes for governance as it does for migrations. You probably already have a standard or best practice in place on how you govern environments. Best practices that you deploy to every customer environment (and maybe industry specific). You're providing the customer with cost management tooling and/or actively advise them on managing costs in their new platform. I can do a write-up on how you could go about implementing governance and what to think of but Phoummala Schmitt describes in really well in her blog post "IT Governance: Everyone needs it even when they think they don’t".
As with the previous steps, consult with your peers when whipping up a new design. For example: does the way you organize the resources for the customer fit your governance picture or do you need to go about it a different way?
Governance goes into the Managed Services / Support staff box for me.
Managing is where you probably excel as a Managed Service Provider. Things like monitoring, update management and capacity management are a part of your DNA. But there's still a lot to learn from the Cloud Adoption Framework when it comes to managing your environment. Read up on "Operation Fitness" https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/operations/operational-fitness-review as a Managed Service Provider this is great content to get started with or improve your pro-active engagement with customers. What ever happens here, is input for the next time you go through the CAF (continuous improvement!).
Adapt: Overview / Putting things into perspective
If we look at the Cloud Adoption Framework and map the customer engagement and design processes onto the framework topics you can see that there are similarities.
|CAF Topic||MSP Process||Role|
|Define Strategy||Initial Contact / Sales Process||Sales Team and Architect|
|Plan||Plan & Design process||Sales Team and Architect|
|Readiness||Plan & Design process||Architect|
|Adopt||Migration and implementation||Architect / Consultants|
|Govern||MSP Processes||Managed Services / Support staff|
|Manage||MSP Processes||Managed Services / Support staff|
Does that mean you're already using the Cloud Adoption Framework and you're good to move on? Definitely not. And to me, that's not what the framework is about. This is just your first encounter with the framework and by putting things into perspective you will understand where to position your processes within the framework and maybe take a closer look at the best practices and insights they provide, helping you to adapt the framework. Maybe move some processes to a different topic with the Cloud Adoption Framework, or add a topic of your own.
If you’re a Managed Service Provider then chances are that you have already got the processes, standardization and automation in place to successfully migrate and manage your customer environments. Just like the the average small-medium sized MSP I just described. If you’re reading up on the framework you will notice you have already implemented a lot of the best practices. Translating these to the Cloud Adoption Framework (or vice versa!) will provide your sales organization, your customer and your technical staff with structure, guidelines and clear expectations. If you standardize you can manage the input and predict the outcome. This will help you create fit for purpose environments, automate where possible and be more efficient altogether. So now that you have your processes and procedures mapped to the Cloud Adoption Framework, you can actually start benefiting by adjusting the processes that can use some improvement or skip best practices that don't suit your business.
If anything, the framework will provide you with well.. a framework to help you structure your MSP business and continuously improve.
Considerations when implementing
Does that mean you have to grab the framework best practices, slap it on top of your company processes and tell your peers that “this is how we do it from now on”? Don’t. Please don’t. This is probably the most effective way to set up for failure. People have learned their lessons from this already so you don't have to (https://www.inc.com/lee-colan/10-reasons-change-efforts-fail.html).
Secondly, we’re talking about a framework here. Frameworks provide guidance but are in no way intended to dictate how you run your business.
Your peers or employees have spent valuable time coming up with processes and best practices that work best for them. Respect their knowledge and efforts and built on that. Instead go about it a different way. Firstly, explain the why and what of the Cloud Adoption Framework (there are plenty of resources for this) and ask your peers how they’re working right now, have them explain their process. See where this fits into the framework.
You’re going to map your processes onto the framework, regardless of good or bad. You now have your baseline and it’s time to improve. Going through the framework and your processes you have two options:
- Good Process, doesn’t fit in the framework: Adjust Framework;
- Process can be improved, see if the framework best practices help: Improve Processes.
In no way should the best practices as documented in the framework dictate how you run your business. True, they’re probably best practices you need, and I would recommended to use most or at least look at what you can learn from them.
The Microsoft Cloud Adoption Framework and some topics mentioned in this post are still actively being developed. If you want to provide feedback or contribute, you are free to do so. Microsoft has published a roadmap regarding Cloud Adoption Framework (https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/appendix/roadmap). Read it, have an opinion and contribute where you can.