A Framework to Prioritize Analytics Use Cases for Cloud Migration

Cloud computing is transforming industries, and it is growing at an unprecedented pace for a good reason. Gartner predicts worldwide public cloud end-user spending will grow 18% in 2021, topping more than $300 billion. There is no doubt that Cloud fuels innovation.

Analytics workloads are especially poised to leverage cloud computing. Cloud offers unlimited scale, on-demand elasticity, and services that are at the edge of innovation. As a result, more and more organizations are pivoting towards the cloud for analytics. A Forbes report suggests that more than 47% of organizations have analytics running on the cloud in 2021 — up from 39% in 2019. This number is likely to go northwards, and it is a good story for the cloud. However, a story is no good without its challenges. In my experience consulting numerous customers across the region, I have found one perennial challenge that these organizations face:

- Is there a framework to identify analytics use cases for cloud migration?

This question is vital because an analytics function comes with its legacy. Organizations have invested millions of dollars in getting it up and running. Numerous data warehouses, data marts, data lakes, operational data stores, and many other legacy systems lurk around the organizations that fulfill a plethora of analytics use cases. Some of these systems are legacy and redundant. However, some of them are lifelines of businesses. Businesses rely on it for reporting, feedback, performance management, and running their day-to-day operations. Some of these use cases have evolved. However, they are throttled by the inefficiencies of the systems. These use cases need a new lease of life. There needs to be a framework that helps to prioritize these use cases. This blog will highlight a framework that one could potentially use to prioritize the analytics use case for cloud migration. If used correctly, they distill clarity with simplicity. We will examine three two-axis models that can prioritize the workloads to move to the cloud.

The framework consists of three models that focus on three key drivers. These drivers are:

1. Cost Advantage: Will there be a cost advantage if the use case is migrated to the cloud?
2. Value Addition: Will there be a significant value addition if the use case is migrated to the cloud?
3. Enhanced Availability: How available the use case be if it is migrated to the cloud?

Let us investigate each of these models in detail

Model 1: The Cost Model

The first model is the cost model. The cost model considers the dimensions that primarily influence the cost of running the use case in the cloud: compute and storage.

The Cost Model

Model components

• Defining Relative Compute (x-axis): The relative compute required to satisfy (process the data) for the use case is the x-axis of the model.
• Defining Relative Storage (y-axis): The relative data storage required to satisfy the use case is the Y-axis of the model.

The Quadrants

• Quadrant I: The candidate use cases with high compute and high storage requirements should prioritize cloud migration. Cloud provides the ability to scale both compute and storage at a reasonable cost. Therefore, migrating the use case to the cloud will bring the cost down compared to running it on-premises.
• Quadrant II: The candidate use cases with low compute but high storage requirements is a problem child. There needs to be a case-by-case analysis of the use case to determine if it is a good candidate for cloud migration. For example, suppose the relative cost of storing the data on-premises is cheaper than moving to the cloud (on-premises is CAPEX vs. OPEX for cloud). In that case, it may be prudent to keep the use case on-premises instead of migrating the use case to the cloud. One can use the other subsequent models discussed later to determine whether the problem-child use case should be prioritized for cloud migration.
• Quadrant III: The candidate use cases with low computing and storage requirements should be low on priority for cloud migration. One can’t justify the cost of migration and the cost advantage for such use cases. Cloud computing adds value only when there is scale.
• Quadrant IV: The candidate use cases with high compute and low storage requirements should prioritize cloud migration. Compute is ephemeral, and one can control its costs in the cloud, i.e., its cost is controllable OPEX. In an on-premises world, compute is a CAPEX expenditure and needs to be paid for, whether used or not.

Model 2: The Agility Model

The second model is the agility model. The agility model considers the dimensions that primarily influence the value the cloud creates for the business use case. It focuses on the agility that the cloud delivers for the use case. The dimensions are business agility and architectural agility.

The Agility Model

Model components

• Defining Business Agility (x-axis): Business agility implies the rate at which the use case changes are required.
• Defining Architectural Ability (y-axis): Architectural agility implies the speed at which the underlying architecture needs to change to fulfill the business use case.

The Quadrants:

• Quadrant I: The candidate use cases with high business and architectural agility should prioritize cloud migration as the cost of not evolving impacts the business. The cloud provides the platform to be more agile when the use cases changes are frequent. It also provides the ability to be architecturally adapt to the changing requirements.
• Quadrant II: The candidate use cases with low business agility and high architectural agility should be tagged with a medium priority for cloud migration. The architectural agility is high for these use-cases. Hence migrating to the cloud will yield cost benefits as frequent architectural changes cause more overheads on-premises than the cloud.
• cases with low business and architectural agility should have a low priority for cloud migration. Moving such use cases to the cloud may not yield the business value when considered on its own. Once implemented, these use cases are stable as the business requirements change slowly as well.
• Quadrant IV: The candidate use cases with high business agility and low architectural agility should prioritize cloud migration. Given that business agility is high, it can further leverage cloud technologies’ innovation to extract value from the use case. Perhaps, it will be an excellent candidate to enhance it further.

Model 3: The Availability Model

The third model is the availability model. The availability model considers the dimensions that influence how available the use case should be for the business. The dimensions it considers are the expected availability of the use case and the number of architectural components that satisfy the use case. Note that the expectation is for the use case to be available. Not the technology. Let us define the dimensions in more detail.

The Availability Model

Model Components

• Defining availability (x-axis): The expected Availability of the business use case.
• Defining # of Architectural Components (y-axis): The availability dimension is juxtaposed-positioned with the number of Architectural components required to fulfill the specific use case.

The Quadrants:

• Quadrant I: The candidate use cases that require a high business availability and an increased number of architectural components to fulfill them have a higher cloud propensity. The propensity is high because the high availability of the components directly impacts whether the use-case can be highly available or not. For example, the business requires a recommendation engine to be available 24x7 on their mobile application. The recommendation engine depends on series of components ranging from data ingestion to storage to machine learning models. All these components will need to be highly available as well for the use-case to be available 24x7. More the number of components required to fruition the use-case more will be the complexity associated with it. Therefore, the prudence will be to move it to the cloud.
• Quadrant II: The candidate use cases that require a high business availability but the necessary architectural components to fulfill them are lesser have a medium cloud migration propensity. A lot will depend on the underlying components used and whether moving them to the cloud justifies the cost of the movement against keeping them on-premises and maintaining.
• Quadrant III: The candidate use cases that require a low business availability and the number of components necessary to fruition the use cases are lower can afford to stay on-premises. Typically, the effort and cost to move them to the cloud won’t justify the realized benefits. Therefore, they have a lower cloud migration propensity.
• Quadrant IV: The candidate use cases with low business agility and high architectural agility should have a medium priority for cloud migration. It again needs to be judged on a case-to-case basis with an analysis of potential cost and agility benefits vs. the cost and effort required to move them to the cloud.

Bringing It All Together

Now that the three models that can be used qualitatively bucket the use cases for cloud migration are discussed let us bring them together. In practice, these models shouldn’t be used in isolation but instead fused to give a holistic view and determine whether a use case should be moved to the cloud or not. An example of linking these models is as follows:

An example of bringing the models together

In the above example, there are seven candidate use cases, and the task is to prioritize them for cloud migration. The guideline for applying these models are as follows:

1. Each use case is validated against each model and bucketed in HML (High-Medium-Low) bucket.
2. All the use cases with a high propensity are ranked first. The more the number of high buckets, the lower is the ranking. In the example above, use-case #1 has the highest number of highs, followed by use case #4, #6, and #7. Use case #6 and #7 have an equal number of highs. However, use case #6 has a greater number of medium buckets as compared to use case #7. Hence use case #6 is ranked higher than use case #7.
3. Once the use cases with high buckets are ranked, the same principle is applied to use cases with no high buckets but only medium or low buckets. Thus, in the example above, use case #3, #2, and #5 are ranked by the medium or low buckets attributed to each use-case.

In conclusion, applying the models discussed in this article provides a quick but systematic framework for evaluating the cloud migration propensity of business use cases. Furthermore, one can extend the two-axis framework with more dimensions based on the context of the specific use case.