The Roadmap to Cloud by Sam Garforth

An abridged version of this was first published on Cloud Services World as “Transition vs Transformation: 8 factors to consider when choosing the best route to cloud” in July 2013

Many companies have arrived at cloud naturally over the years through data centre optimisation. Traditional IT had separate servers for each project and application. We then had consolidation of the physical infrastructure and virtualisation to allow multiple operating systems and application stacks to run on the same server, plus shared application servers and middleware. Standardisation and SOA allowed the monolithic applications to be broken up into functions that could be reused, shared and maintained independently. By using patterns and putting the application stacks into templates, automation enabled the self-service, elasticity and the dynamic workload provisioning benefits of private cloud.


Now that the functions have been sufficiently encapsulated and commoditised we are seeing more and more customers moving them onto a public cloud and perhaps linking them back to their core existing business as a hybrid cloud. Some companies are teaming together and sharing services in a club cloud.

However you don’t have to go through all these steps in order. It is possible to migrate workloads straight to the cloud, but it’s important to do this using a carefully considered methodology.

According to KPMG’s Global Cloud Provider’s Survey of 650 senior executives, the number one challenge of their adoption of cloud is the high cost of implementation/transition/integration. Steve Salmon of KPMG said “Implementation and integration challenges are critically important to overcome and can threaten both the ROI and business benefits of cloud.”

To get the most benefit from moving to the cloud it is critical that you understand your current portfolio of applications and services and align them with a cloud deployment strategy. Begin by looking at the strategic direction of your company. Next, analyse the business applications and infrastructure components and create a prioritised list of suitable workloads for migration to the cloud as well as an analysis of the potential costs and migration impacts. Then look at your existing environment and determine an appropriate cloud computing delivery model e.g. private, public, hybrid, community etc. Define the architectural model and perform and gap analysis, build the business case and then implement based on a roadmap.

Application Migration Assessment

An assessment needs to be carried out against each application, or group of applications assessing the benefit and effort of moving to the cloud. This will form a roadmap/prioritisation of which applications to move in which order. A typical application migration roadmap would be based on the following chart. This shows risk/ease of migration against gain. In terms of time it is recommended to start migrating the apps in the top right corner of the diagram and end with the ones in the bottom right.


Transition vs. Transformation

When considering whether to move an application to the cloud, it is important to consider both the business purpose of the application and the role that application plays in supporting business and IT strategies. This context is important for considering whether to transition an application to a cloud environment, or whether to rearchitect or “transform” the application – and if so, how to do it.

 Transition, commonly referred to as the “lift and shift model,” is applied to situations when the application runs as-is or with minimal changes to the architecture, design or delivery model necessary to accommodate cloud delivery. For example, an application with no duplication of functionality and that supports current performance and security requirements would be a good candidate to transition to a cloud. The transition of such an application typically includes:

  • Selecting a private or public cloud environment to host the application.
  • Provisioning and configuring the Infrastructure-as-a- Service and the Platform-as-a-Service needed to deploy the application.
  • Provisioning the application to deliver built cloud characteristics such as monitoring, metering, scaling, etc.

When identifying enterprise applications for transition, there are a number of factors to consider.:

  • Business model –Business services and capabilities should be separated from the underlying IT infrastructure on which they run.
  • Organisation – Enterprise IT governance should be well established. Service usage is tracked and the service owner and provider are able to reap paybacks for the services developed and exposed by them.
  • Methods and architecture –The application architecture should support service-oriented principles and dynamically configurable services for consumption within the enterprise, its partners and throughout the services ecosystem.
  • Applications –The application portfolio should be structured so that key activities or steps of business processes are represented as services across the enterprise.
  • Information –The application’s business data vocabulary. This enables integration with external partners, as well as efficient business process reconfiguration.
  • IT infrastructure – Services can be virtualised such that any given instance may run on a different and/or shared set of resources. Services can be discovered and reused in new, dynamic ways without a negative impact on the infrastructure.
  • Operational management – Service management incorporated into the application design addresses demand, performance, recoverability and availability. It also tracks and predicts changes to reduce costs and mitigate the impact on quality of service.
  • Security –Good application and network security design supports both current and future enterprise security requirements.

In some cases, business and IT objectives and conditions warrant larger, more comprehensive changes to an application that is moving to the cloud than are possible under the transition approach. Transforming existing applications involves rearchitecting and redesigning the application to be deployed in either a private or public cloud environment. This path involves the application being redesigned to fit a more open computing model, for example to accommodate service-oriented architecture (SOA), exposed APIs or multi-tenancy. An SOA application model is valuable in that it allows for integration across custom and packaged applications as well as data stores, while being able to easily incorporate business support services that are needed for cloud deployment.

Typically, transforming applications for a cloud environment includes the same set of criteria as transitioning applications to a cloud environment, but with different conditions. Often, applications targeted for transformation are tightly coupled with enterprise legacy systems and do not meet current security, availability and scalability requirements. The situational factors that support the transformation decision include:

  • Business model – In an application that is a candidate for transformation, business services tend to be isolated with each line of business maintaining its own siloed applications. Also, there is minimal automated data interaction or process integration between the silos. By transforming the application for cloud delivery, the organisation can extend the business value of the service or application to other lines of business (LOBs) and partners.
  • Organisation –When each business unit owns its own siloed applications, it defines its own approach, standards and guidelines for implementing, consuming and maintaining application-delivered services. These may not align well with the need of the organisation as a whole.
  • Methods and architecture – In siloed applications there is no consistent approach for developing components or services. LOBs tend to throw requirements “over the fence” to the IT organisation, which then develops solutions with-out feedback from the business. The application architecture is typically monolithic and tightly coupled, with minimal separation between presentation, business logic and the database tiers. Often there is mostly – or in some cases only – point-to-point integration.
  • Applications –Usually, portfolios of discrete applications take minimal advantage of service-oriented architecture concepts, and business processes are locked in application silos.
  • Information – Information sharing tends to be limited across separated applications. Data formats are often application-specific and the relatively inefficient extract-transform-load process is the primary means for information sharing between applications.
  • IT infrastructure –Platform-specific infrastructures are maintained for each application and infrastructure changes have had to be put in place to accommodate service orientation, where it exists.
  • Operational management – Service management functionalities such as monitoring and metering to manage enterprise business applications and/or services are either not supported at all, or only to a limited extent.
  •  Security –Enterprise application and network security enhancements are required in transformation candidate applications to meet current and future security requirements.

After selecting the appropriate cloud delivery model (private or public), the decision to transition or transform an existing enterprise application is important in order to help ensure a successful move to cloud. When resources are limited, it is possible for an enterprise to choose to run the transformation in parallel with transition to meet short-term needs, while planning for longer-term, best-in-class performance through application transformation.

Consider Engaging a Third Party

Enterprise-wide cloud implementation can be a challenging process. Operating under ever-tightening budgets, IT staffs typically spend most of their resources to simply maintain existing server environments. Even those organisations capable of building their own clouds often find, emerging from the testing stage, that they would benefit from outside management support. Because of these challenges, organisations must carefully think about how to best source their cloud technologies. In making a sourcing decision, they should keep in mind business design, necessary service levels and deployment models. The question of who will migrate, integrate and manage applications must also be addressed. After considering these issues, many organisations choose to turn to third-party technology partners for help with enterprise cloud endeavours. Find a third-party provider that offers its clients a choice in the areas of scope, service levels and deployment. The partner should offer deep expertise in strategic visioning and in cloud migration.

To protect the client’s cloud infrastructure, technology partners should provide multiple security and isolation choices, robust security practices and hardened security policies proven at the enterprise level. Security procedures should be transparent, providing visibility into cloud activities and threats. Data monitoring and reporting must be offered. Since business needs are ever-evolving, the best cloud partners also offer a full portfolio of associated services in the fields of security, business resiliency and business continuity. Finally, the client organisation should be able to maintain control over its cloud environment. Technologies that provide this type of control include online dashboards, which can allow the client organisation to manage the cloud environment from virtually anywhere in the world. 

Example Roadmap

An enterprise can choose to run the two approaches in parallel transitioning some to meet short-term needs, while planning for longer-term application transformation.

Middlesex University has embarked on the journey to cloud. They needed to reduce the number of machines from around 250 to 25, electricity usage by 40%, and physical space requirements from approximately 1,000 square feet to 400 square feet. Steve Knight, Deputy Vice-Chancellor, explained, “We need a system that allows flexibility according to our changing requirements. We were looking for a platform solution to complement our longer term plans to achieve a dynamic infrastructure.”

A popular roadmap, similar to the journey Middlesex is on, is:

  • Begin to consolidate, rationalise and virtualise the existing on premises infrastructure into a private cloud. Perhaps install a modern expert integrated system which allows you to start consolidating key applications onto a smaller and more economical estate. This should be done gradually so as not to effect current service delivery. Applications and images on the private cloud should be portable to a public cloud at a later date.
  • Start “experimenting” with hosted unmanaged cloud running new development and test workloads.
  • Look to a MSP to manage your on premises infrastructure and/or private cloud. Start using the cloud provider for disaster recovery and backup.
  • Eventually look to move everything to a flexible hosted managed cloud.

So in summary, a blended approach is needed, choosing whether to cloud-enable existing applications or to write new cloud native applications, depending on the characteristics of the applications and their integration requirements.

4 thoughts on “The Roadmap to Cloud by Sam Garforth

  1. Pingback: 8 Steps to Cloud Success: A Cloud Roadmap is the Path to Business Agility | Basics of Java and Cloud Computing

  2. Pingback: HOW IS CLOUD SECURITY DIFFERENT FROM ON-PREMISE SECURITY | Basics of Java and Cloud Computing

  3. Pingback: Sam’s Views on Cloud for UK Government Policy Makers | Sam Garforth

  4. Pingback: How governments can tap into cloud and Internet of Things | Sam Garforth

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s