A Framework to Prioritize Analytics Use Cases for Cloud Migration

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

  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?

Model 1: The Cost Model

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

An example of bringing the models together
  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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pradeep Menon

Pradeep Menon

Creating impact through Technology | #CTO at #Microsoft| Data & AI Strategy | Cloud Computing | Design Thinking | Blogger | Public Speaker | Published Author