Companies migrate applications to the cloud for a variety of reasons. These can be grouped into three drivers:
- Business Disruption: Digital Transformation, “Uberization”, IoT, etc.
The IT environment needs to transform drastically to address new ways of doing business. This is often a business-led journey and implies applications are broken down into individual services that are invoked as part of digitized business processes.
- Increased Agility & Responsiveness: Be able to respond faster to the needs of the business.
This is often driven by the CIO who is pressured by the business to deliver more value. Applications architectures are adapted to enable applications to scale up and down according to user demand. Their deployment is also automated to enable faster release of new functionality.
- Infrastructure Optimization: Use cloud and other new technologies to cut infrastructure running costs
Infrastructure-led and application transformation/workload migration is often an afterthought. Applications are migrated to the new environment, but keep running exactly as they did before.
It’s not one-size-fits-all
I would argue that application transformation is not a one-size-fits-all undertaking. Depending on the positioning of the application in the portfolio, one or another approach may be most effective. What I often see is that, because a proper portfolio analysis is not performed, the initial driver triggers the transformation strategy, only partially addressing the business needs. Rather than starting from the drivers, I would propose starting from the application portfolio analysis.
Let me remind you of the model used. On the vertical axis we have the importance of the application to the business. If the application or the associated data supports the differentiation of the enterprise, it’s considered core; otherwise, it is context. The horizontal axis highlights the application type: back-end, collaborative, or innovation-related.
Let’s first look at core applications
Core applications are the ones that truly differentiate the enterprise, so it makes sense to start with those. Migrating them to a new platform enables faster creation of additional functionality. And an improved user experience results not only in cost reduction but also new business opportunities.
Depending on the application type, two different transformation strategies are proposed. Systems of record applications with stable demand may (or may not) be migrated to a cloud environment.
Remember what I said in the first of these three blogs. If demand is constant over time, you should ask yourself whether it makes sense to migrate the application to a cloud environment. What is the added value? Regardless of whether the target environment is cloud or not, a migration may have to be made – for example, if the current environment is old from the perspective of the operating system, middleware or database. Moving to the latest version reduces licensing and support costs.
For systems of record, the objective is to keep applications running as they are. This is why I recommend a re-host approach. Whether you do a binary migration or have to do small adaptations in the code for compatibility reasons, the objective is to keep each application working as is.
For systems of engagement, things are different. These interact extensively with users (employees, clients, partners, etc.), and in many organizations there is a trend to enable the use of tablet PCs and other mobile devices to interact with the application. Opening up the application to a wider audience and enabling mobile access most often results in unpredictable utilization patterns. However, one thing is of key importance: the user needs a constant and satisfactory user experience, regardless of utilization levels. Otherwise the application will not be used for long.
From an application perspective, you need to ensure constant responsiveness. Cloud computing offers the opportunity to clone parts of the application to enable such responsiveness with higher demand. It’s called scale-up/scale-down. So, you should use this. However, this implies some parts of the application can be duplicated in a transparent way. This requires the application to be SOA (Service Oriented Architecture)-compliant and the use of a message or enterprise bus between the modules to maintain the timing of transactions. So, the architecture of the application needs to be adapted to take full advantage of the cloud. This may lead to a re-factoring of the application. Or, if the technologies used are older and difficult to maintain, a full re-architecting may be required, resulting in regeneration of the application logic in a modern language such as Java or Python.
If the application is in the systems of innovation category, it probably does not make sense to migrate the application as it will typically have a short shelf life. Indeed, either the application is very successful and becomes an enterprise standard (in other words, a system of engagement) or it is trashed and replaced by the next experiment.
I would suggest you take the opportunity of starting a new development to move to the new platform. You may envisage developing the next application using microservices, containers, serverless computing and all the upcoming technologies.
And what about context applications?
The objective for context applications is to reduce the cost of running them to a minimum. This implies going, wherever possible, to SaaS services or at least COTS packages. So, here the discussion is about replacement and retirement. In practice, there will be a number of applications the business is not ready to let go quickly. Those will have to be migrated. Re-hosting, as described above, should be the default option. Let’s invest as little as possible in this class of application that does not provide differentiation and business benefits. If you need to do more than re-host, you should first develop a solid business case. You want to invest in areas where you differentiate, not in ‘me-too’ spaces.
A simple way to analyse your portfolio
It is essential to take the time to think through your application portfolio and understand which application deserves what transformation treatment. This exercise forces application teams to think through the actual value of the application to the enterprise. I would strongly recommend undertaking this exercise jointly with the business. This is because it will foster a clear understanding of where the enterprise wants to go and what application assets are critical to enable the company to achieve its vision and objectives.
As the economy is increasingly driven by digital technologies, it is mandatory to identify the route forward and understand what is critical to get there. As an existing enterprise, you become a digital migrant. Running the current business while transforming for the future requires skills and understanding of what is needed now and in the future.
I do hope that the approach I have outlaid through those three blog entries provide useful tools to help you in your transformation journey. As always, feedback is more than welcome.
Author: Christian Verstraete
Christian Verstraete, Advisory Services Cloud Application Lead, DXC Technology.
Christian specializes in the use of information technology to support business processes within the enterprise and across eco-systems in Europe and with global clients. His expertise includes consulting, project management, marketing, business and people management. Currently, Christian is a cloud evangelist for DXC, helping to develop a consistent offering crossing organizational boundaries.