Cloud adoption in the era of accelerated Digital Transformation (Part 2)

Once we finalize the Strategy Phase, we are ready for the Plan Phase of our cloud adoption endeavor. This is the tricky part, because up to now, everything we did was purely academic. At this point we need to develop actionable migration/adoption plan, analyze the skill gaps, and map them to specific roles in the organization, and prepare the organization for the upcoming changes. We can proceed on the path to Digital Transformation.

This is the point in the cloud adoption when we start looking at Governance and Management and start building a long-term strategy in these areas. We must break the traditional barriers and processes and shift them to then new paradigm. But we will get back to that.

In case You missed the first article, refer to the following link to Part 1

Plan

Based on findings and directions set forth in our Strategy stage, we can proceed and create the actionable plane for our cloud adoption journey. The process evolves around the following:

• Rationalize the digital assets
• Organizational alignment
• Skills plan
• Cloud adoption plan

Rationalize digital assets

It might sound simple enough, but in complex and interconnected environments it is not that easy. In order to do this, we need to do full Inventory of applications, software, hardware, and system performance metrics.

You can speed up the process, by focusing only on potential assets that can be moved to the cloud. Full inventory of the environment will take some time. You can perform that in parallel to the rationalization process.

Next step would be performing Quantitative Analysis which will influence the first layer of decisions, which assets will we flagged a part of the cloud journey. We must go through the inventory and prioritize the workloads that will be part of the cloud migration. Basis for the decision will be – Is the workload being used or not? What is the dependency of that asset and others? Is the hardware or software nearing end of life? Is the asset accessible internally or externally?

Focus on assets that are non-business critical, not used that often as viable candidates; Workloads that are available to external users, that does not involve major governance and security changes; Legacy workloads (end of life) that will benefit from the move to the cloud.

TThen we can move to the QualitativeAnalysis, which is unique on a per solution basis You can do either workload-driven or asset-driven approach. The first one is top-down analysis based on security aspects (high, medium, low business impact), and the other one you focus on the application for the migration. This process, in traditional rationalization model, will take most of our time and efforts. This will cause significant delays, and it will not help our quick win effort.

To speed things up, go for the asset-driven approach. That will support you QuantitativeAnalysis since that analysis is valid for IaaS workloads, hence the rationalization can be achieved more efficiently and faster.

This process, in traditional rationalization model, will take most of our time and efforts. This will cause significant delays, and it will not help our quick win effort. Based on the results of these 2 steps, we can get to the Rationalization decision.

The rationalization decision will encompass:

1. Rehost – Lift & Shift (or what I prefer is Move & Improve) of current assets to cloud, with minimal changes on overall architecture of the solution. This is pure Infrastructure-as-a-Service (IaaS).
2. Refactor – move the assets to the cloud in Platform-as-a-Service (PaaS). Partial code changes might occur, additional application testing should be done
3. Rearchitect –  completely re-architect a legacy application to be able to run in the cloud
4. Rebuild– start from scratch and build the solution for the cloud (new code base, native cloud application)
5. Replace – move away from the current solution, and replace it with  Software-as-a-Service (SaaS) solution

For our quick win model, we will focus only on the first two – Rehost and Refactor. They will drive faster results, such as: cost reduction (operations), free space in the on-prem datacenter, tangible ROI, improve efficiency. This will go hand in hand with the results from Quantitative and Qualitative Analysis.

For us to move faster, the approach would be to use Incremental Rationalization process. This means, we do the following:

• Reduce data discovery points: use a tool that will aggregate the inventory data, including performance information. Preferred model is agent-less (i.e. Azure Migrate), which for a quick win we look for is good enough.
• Streamline decision process: Focus only on two rationalization decision and apply the quantitative factors on them.
• Temporary assumptions: We reduce the number of potential outcomes, to make the decision easier. We have less questions to ask the business stakeholders in early stages, which means less possible answers and faster decision making.

This will we enough to select the first workload we will move to the cloud. This will be key to learning and testing the assumptions, provide corrective measures, and learn about the process.

The selection should be a workload with minimum dependencies, as well as small group of assets. Focus on low business impact ones. Qualitative analysis will be easier to perform – data point wise, but also time wise. We can do more precise cost-modeling and align them with the forecast costs.

The migration of such workload will improve skills, help define core services (long-term goal), understand the operational model of the cloud environment.

On the area of cost modeling side, we can use several tools at our disposal:

• Azure Pricing Calculator: useful online tool for budgetary cloud cost estimation. You can use it during the Strategy or Plan phases.
• Azure Migrate: most cost-effective tool (agent-less) than can be used for precise inventory, partial rationalization and cost calculation for the digital assets. Its part of the Plan, Ready and Adopt phases.
• Azure Cost Management: once we move asset to the cloud, Azure will provide us with real consumption information and cost trends, define and track budgets, get alerts. We can use the Portal or integrate trough the API’s, directly to our ERP/Finance systems, providing full visibility into the resource consumption.

The complete CAF for Azure methodology goes into more details on all above-mentioned topics, and I strongly recommend reviewing it before you proceed.

Once we complete this step, we will be ready to pick and choose the quick win projects. In the other parts of the article, we will talk little bit more about these into details.

People, skills, organization alignment plan

What ever plan we make, it will always depend on whether the right people (teams) are assigned to it, what are the skills of those people for that specific plan execution, and the organizational alignment.

Out of the three, the last one – organizational alignment is the longest one to achieve. If we see any traditionally structured organization, it holds a lot of siloes inside – application/workloads, operational, development, governance wise. I have worked with organizations where their model was based on application silo – all related operations, including governance and security, bound to single siloed vertical. There was no one-to-one, direct mapping between their on-prem applications and the cloud. This implied a lot of “sacrifice” on their organizational, but also operations side.

This implies significant change on how we do business, how we operate, how we structure the people in our organization. You need to map appropriate people capabilities to the cloud adoption project. I’ve  seen quite a few cloud adoptions projects, where the focus was on the assets, inventory, mapping of technologies, their move to the cloud, on-boarding experts, but nobody was paying attention on the organizational structure. Luckily, full org alignment is not mandatory requirement for the CAF.

During this process, your organization might rely on external help, that will support this process through consultancy services. But that should not delay the internal process of alignment.

You will need, as bare minimum, two teams – Cloud adoption and Governance Team. As the name says, the first team will be running and executing the cloud adoption project. The second team, will be checking and watching against potential exposure of the business to any new risks during this.

Organizational alignment is a long-term process. It must start, and it must at the beginning of the cloud adoption project. It will be done in parallel with the cloud adoption process, and it requires tight involvement of the business and administrative side of the organization. The Cloud Adoption Framework, has a separate section that an support that effort

Additional information: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/organize/

In parallel to establishing the two teams, you need to focus on the gaps – skills, roles or process that is part of the cloud adoption project, but it does not exist in the organization. You need to develop a readiness plan, that will support both the process and the people involved. During the cloud adoption process, you will see traditional IT roles disappearing or transforming into something new.

We find a lot of situation, where employees are resistant to such change (Digital Transformation). Lack of clarity of what their new job position will be, misconception that it will just bring additional work, fear of change or shifting the comfort zone, and last, but not least, losing their job.

Once you have completed the above steps, you can focus on the Cloud Adoption Plan. This plan is well defined strategy, and it is a requirement for successful cloud adoption project. Remember, we are not bound to traditional, linear model of project management. Cloud implies different asset acquisition model – agile or iterative model. We do not have capital expenditures, we move towards operational expenditures model.

The Cloud Adoption Plan, addresses the following actionable strategies, based on the steps previously completed:

1. Prerequisites – Effectiveness of the plan is measured by the data we put into it. We need to make sure that we have clear business goals, justifications and outcomes; we have completed the planning phase (rationalization of the assets, basic organizational alignment, and readiness plans)
   
2. Define and prioritize workloads – We have identified our top 10 workloads (conceptual collection of assets) out of our inventory, mapped the dependencies and prioritized them for cloud adoption.
   
3. Align assets to workloads – Map appropriate workloads to assets. This means listing appropriate virtual machines and servers, applications , data sources and dependencies that correspond to a workload.
   
4. Review of rationalization decisions – Double check your initial rationalization decisions and implement corrections if needed.
   
5. Established iterations and release plans – Define the (recurring) time blocks for the iterations. Time block can be between one to six weeks but fix it to 2 weeks per block. Assess the amount of work that need to be done per time block, based on people and skills capacity. Define the release plans (sprints), based on the business value that deliverables must justify the risk of potential disruption to the business processes.
   
6. Estimate timelines – Crate the Work breakdown Structure (WBS), starting from the initial release, to create the delivery plan timeline. Create granular milestones for the timeline, based on step 5.

Conclusion

Once we complete the Plan Phase, we will e in position to crate our first Landing zone, to test our Cloud Adoption Plan. This will proof test it, learn about Azure, gain necessary skills and knowledge, make corrections, and prepare for expansion of the landing zone. This will support our efforts towards the Adopt Phase.

For the process of these series, Part 3, will be about actual workloads we can move to the cloud, as well as governance and management components that will enable us to support the mid to long term digital transformation process. Those will be our quick wins.