Want to accelerate the migration of your applications to the cloud? Iteratively identify patterns to move and supercharge your cloud adoption!

This article is part of the limited preview of the “The Missing Cloud Programme Roadmap”, a generic roadmap for any enterprise cloud adoption programme.

1. Executive Summary
2. The Cloud and Enterprises
3. The Missing Cloud Programme Roadmap
   1. The Cloud Programme Roadmap
   2. The First Iteration of The Cloud Programme Roadmap
   3. The Unavoidable Disclaimer
   4. The Roadmap for The Missing Cloud Programme Roadmap
   5. The Manual for the Missing Manual
   6. Building the Business Case
   7. Starting the Cloud Programme
   8. Iteratively Building the Delivery Pipeline
      1. Key Achievements
      2. Constantly Monitoring Dependencies
      3. Prioritising Cloud Capabilities By Applications
      4. Iteratively Identifying Patterns to Move
         1. Cloud Suitability
         2. Application Assessment
         3. Identifying and Developing Patterns
      5. Selecting Cloud Compagnon Applications
      6. Setting Up the Teams
      7. Avoiding Friction for Existing Processes
      8. Recording Outcomes: The Cloud Handbook
   9. Iteratively Executing the Delivery Pipeline
4. A Cloudy Future

Iteratively Identifying Patterns to Move

Where the application driven approach merely requires the selection of high priority applications, the pattern driven approach requires the a priori identification of patterns. Now,

A pattern is a standardised solution to a clearly defined problem. As such, patterns are ideal candidates when trying to identify reusable components.

Reusable components then allow to accelerate the adoption of cloud by leveraging synergies between the cloud capabilities to provision.

Cloud Suitability

The identification of commonalities and required cloud capabilities for applications can be accelerated by investigating their suitability for moving to the cloud.

The “cloud suitability” of an application can be measured by combining data points from the following core areas

• Regulatory Approval to leverage the cloud in the first place
• Criticality to the Business including key metrics such a return on investment (in short: ROI) or total cost of ownership (in short: TCO)
• Application Lifecycle Status such as invest, maintain, or divest
• Maturity and Stability such as, mean-time-to-failure (in short: MTTF), recovery time objective (in short: RTO), recovery point objective (in short: RPO), and service level agreements (in short: SLAs), etc; ideally also including historical data from tickets, requests, incidents, or post mortem analyses
• Complexity of the cloud capabilities required to deploy the application to the cloud. Additional data points should include
  • Architecture of the application
  • Number of Processes required to provide the application service
  • Application Service Dependencies, i.e., technical as well as non-technical dependencies the application has on other services as well as other services have on the application
• Migration Speed including required lead times and the modus operandi during the migration period; strategies can range from incrementally migrating specific parts of the application and running the application in parallel to hard cutovers
• Amount of Transformation Required to achieve improvements in cost, agility, delivery speed, or knowledge gain
• Alignment of Application Migration or Transformation to the general objectives of the cloud programme and the organisation
• Exit Strategy both for existing on-premise assets as well as unsuccessful migrations to the cloud

The above core areas are common to most organisations. However, they are a mere starting point and by no means comprehensive.

Chances are that multiple iterations eventually lead to an appropriate definition of “cloud suitability” that is matching the individual requirements of the organisation.

Application Assessment

Using the above “cloud suitability” metric, applications can then be categorised into different tiers according to their suitability to migrate to the current build-out of the cloud (remember, it’s iterative!).

A simple four tier categorisation might be

• Unsuitable for Cloud. The application does not lend itself for a migration to the cloud. Deal breakers might include lack of regulatory approval, unjustifiable investments, or the use of technology not available in the cloud.
• Requires Fundamental Changes. The application is suitable to migrate to the cloud. However, doing so would require significant investments, as numerous processes, architectural components, or dependencies would need to be provisioned or changed beforehand.
• Requires Limited Changes. The application is suitable to migrate to the cloud. The changes are not as drastic as in the previous tier but some investments still need to be carried out beforehand.
• Fit for Cloud. The application is an ideal candidate for migrating to the cloud. It requires no major changes as it only leverages readily available cloud capabilities.

Note that the above is a mere starting point. A more detailed list of suitable categories matching the requirements of the organisation will most likely be revealed over the course of several iterations.

Identifying and Developing Patterns

In each iteration, the above application assessment then allows to define a prioritised list of existing “candidate applications” moving to the cloud. At the same time, this also provides an updated placement rationale for new applications and whether they are being built out on-premise or “cloud-first”.

The general outcome of the above application assessment is the development of approved standard patterns.

Not only for cloud but also for on-premise applications. Note that this also provides the opportunity to re-visit existing patterns for on-premise applications.

Approved standard patterns then allow to define principles, based on loose coupling and standardisation, for all applications that are not lifted-and-shifted to the cloud (there are limitations to that approach — and we have yet to see it fully succeed).

These principles then allow to define architectural patterns, such as API or event driven architectures, required levels of API documentation, well-defined messaging contracts, a priori elasticity, or the use of federated or localised identities.

Selecting Cloud Compagnon Applications

Find out more about it in the next article.

So, How Do You Identify Patterns?!

While the above Worx for Me!™ when it comes to identifying patterns to move, you may have an alternative or better way.

Think this is all rubbish, massively overrated, or generally heading into the absolutely wrong direction?! Feel free to reach out to me on LinkedIn and teach me something new!

As always, prove me wrong and I’ll buy you a pint!