Transition vs Transformation

When considering moving applications to the cloud, it is important to consider both the business purpose of the applications and the role those applications play in supporting business and IT strategies. This context is important for considering whether to transition an application to a cloud environment, or whether to re-architect or `transform’ the application, and how to do it.

Transition

Transition, the `lift and shift model,’ is applied when the application runs with minimal changes to the design or delivery model necessary to accommodate cloud delivery. 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 cloud environment to host the application.

Provisioning and configuring the IaaS and PaaS needed to deploy the application.

Provisioning the application to deliver cloud characteristics such as monitoring, metering, and scaling.

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 is able to reap paybacks for the services they expose.

Methods and architecture – The application architecture should support SOA principles and dynamically configurable services for consumption throughout the ecosystem.

Applications – The application portfolio should be structured so that key activities are represented as services.

Information – The application’s business data vocabulary enables integration with external partners, and efficient business process reconfiguration.

IT infrastructure – Services can be virtualised such that any instance may run on a different 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.

Transform

In some cases, business and IT objectives and conditions warrant larger, more comprehensive changes to an application moving to the cloud than are possible under transition. Transforming applications involves redesigning them to be deployed in a cloud environment. This involves the application being redesigned to fit a more open computing model, for example to accommodate SOA, exposed APIs or multi-tenancy. An SOA application model allows for integration across custom and packaged applications as well as data stores, while being able to easily incorporate business support services.

Transforming applications includes the same set of criteria as transitioning applications, 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 – Business services are isolated with each line of business (LOB) maintaining its own siloed applications. There is minimal automated data interaction or process integration. By transforming the application for cloud delivery, the organisation can extend the business value of the service or application to other LOBs and partners.

Organisation – Each business unit owns its own applications, defines its own approach, standards and guidelines for implementing, consuming and maintaining application-delivered services. These may not align well with the needs of the organisation as a whole.

Methods and architecture – No consistent approach for developing components or services. LOBs throw requirements `over the fence’ to the IT organisation, which then develops solutions without feedback from the business. The application architecture is typically monolithic and tightly coupled, with minimal separation between presentation, business logic and the database tiers. There is mostly point-to-point integration.

Applications – Applications take minimal advantage of SOA concepts, and business processes are locked in application silos.

Information – Information sharing is limited across applications. Data formats are often application-specific and the relatively inefficient ETL 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 or services are hardly supported.

Security –Enterprise application and network security enhancements are required to meet current and future security requirements.

Example Approach

An enterprise can choose to run the two approaches in parallel, transitioning some applications 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-premise 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-premise 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.