Prioritising applications to move to the cloud — 101

Photo by C Dustin on Unsplash

Selecting and sorting applications to transition to the Cloud is a challenge. The first applications shall be sufficiently representative but in the same time with a mastered/contained complexity aligned with the pursued ambition (Modernizing thru API and/or adopting a quick transition with a minimal impact.. for example), to prepare the industrialization of all the subsequent ones.

If powerful tools, methods and consulting techniques exist on the market, a first set of dimensions to consider can be defined to jumpstart the Cloud Journey.

Why is it so complex to select my apps ?

A first level of complexity resides in the criteria themselves because :

• The list of possible criteria is merely infinite. This story will only emphasize the ones I have used on the field to categorize apps quickly but bear in mind that it should be augmented depending on your context. Just keep in mind that “less is more” and carefully selecting a small set of criteria that you totally mastered is far more efficient than relying on a vast list of elements that just blur the situation.
• Some criteria are easy to measure, while others are more based on people’s impression and perception but give a good indicator of a situation.

A transition to where ?

Moving an application to the cloud can be supported by several transition paths. But among them, 4 approaches allow to address the most usual cases:

• Retire: Path for an application that needs to be sunset because it is not used anymore, deprecated, or the technical debt is too high and a complete re-architecture is preferred, or has an functional overlap with another application… This path requires at least to master the deprovisioning process and its impact on the technology landscape.
• Remain: Basically, nothing is done on the application that is kept in its current state. As an example, it is the case for an application which roadmap indicates a short-term sunset and where transition can’t be justified as an investment.
• Migrate: Path where an application is transitioned to the Cloud while minimizing the impact on the code. As an example, “Lift and Shift” approach or even basic ‘containerization’ fall in this path.
• Modernize: The quantum leap. Here, an application is transformed while transitioned in order to maximize the benefits from the Cloud (Elasticity, Resilience, Velocity…). API and microservices enablement are good examples of modernization.

Managing a ponderation weight on the different criteria will allow to emphasise different target states for a given application and propose different transition strategy.

The selection criteria : A starting kit

To be relevant, the outcomes in term of transition shall be concluded taking the prism of ALL the criteria. Taking a single criterion will not be sufficient to determine a target transition path.

Even more important, remember that these criteria allow not only to select but more surely to order by priorities the applications to transition with a tradeoff between the effort to produce vs the benefits to get. As such, it will become a dynamic tool that permits to define a secured roadmap of the transition of an information system.

• The age of the application: Because newest applications may not be the best candidate to initiate a transition as they have just been released and because retiring or maintaining eldest applications could be a better option than a transition
• The usage of the application: How often is the application used ? Because applications that are not used have a poor interest in term of transition, but intensively used ones present a main risk if they are transitioned first when the process is not totally industrialized and proven on several successful transitions.
• The target population: How many end users? This criterion allows to prioritize application with a small population to establish the transition process or to detect a representative application to maximise the impact of the mastered transition.
• The vitality: How many releases per year?This criterion allows to select the application with several releases per year that would benefit from having industrialised CICD, or being modernised to adopt micro-services to reduce even more their time-to-market.
• The maturity: How many blocking defects per year ? This criterion allow to prioritise the correction of applications presenting blocking defects and lower the priority of stable applications that don’t present short term risk (“Why fix it if it ain’t broken ?”)
• The known roadmap: What is the expected roadmap?Application with promising , highly expected roadmap may be preferred to applications which roadmap indicates a sunset or a status quo in short term
• The impact on the Business: How critical is the application for the business? Representative transition shall include business relevant applications. Being able to prioritze them quickly but on a proven process is a stake.
• The apparent complexity: What is the apparent technical complexity (impression)? This criterion is a … complex one. It is a gutt feeling that the dev team has on the application. It is very hard to evaluate, but at least very complex and very simple applications are oftenly detected in an information system.
• The application’s type: What is the type of application? This criterion allows to promote standard applications types (like web/mobile) against proprietary/thick clients that are usually far more painful to transition
• The underlying technology: What is the underlying technology ? Because some technologies that are more Cloud-native, are usually a happy path!
• The maturity of the aimed transition path: For a type of application, what is the maturity of the transition path at customer ? This is an evolving criterion. It is the maturity of the transition path for a given application type. Because being first is always more risky, this criterion allows to industrialise a transition path on simple/less impacting applications or to promote widely used/very representative ones whenever the transition path is mastered.
• The external interfaces: Is the application integrated with others ? The more external interfaces to address, the more complex the transition will be….until the implementation of the underlying micro-services ontology is sufficient to act as an accelerator (because the more stable/used the interfaces will be).
• The richness of the application : How many use cases are addressed? The number of the use cases proposed by an application is a good indicator of the potential non regressions you can have. Richer application shall be transition on proven transition path.
• The DEV team: What is the size of the Dev Team? Is it usually a better option to design, implement, and validate the transition process on shorter team (or squad) to minimize reluctance to change, training…
• The Dev Team’s Cloud Affinity: Is the DEV team cloud-aware ? The more the dev team has used cloud, even to build new cloud native applications, the easier it will be for them to perform a transition that relies on several common cloud design patterns.
• The requirement for a data migration: Is a data migration required ? Of course, it is surely far more simple/less risky to transition applications/services that don’t hold data.
• The known concerns: Are there known concerns or issues ? Some specific problems (like an irremediable design approach) may have a direct impact on the possibility to transition an application and recommand a modernization thru rearchitecture.

As a conclusion, this first set of criteria helps to sketch a first roadmap for the transition of the applications of an information system. But the outcomes of this shall not be binary, meaning there is not a single roadmap, there are many options . The retained approach shall configure the representativeness ponderations between the different criteria to be aligned first to the amibtion pursued.