In my last two blog entries (blog 1 and blog 2), I demonstrated how to use an analysis model to identify the potential landing zone for an application portfolio and which applications to DevOps enable. Let’s finish this series of blog entries by looking at the transformation strategy to be used by each application in the portfolio. Over the last two months I have had the opportunity to present this approach multiple times to clients and have had a very positive response, recognizing the simplicity and pragmatism of the approach.
Companies migrate applications to cloud for a variety of reasons. They can be grouped in three drivers:
- Business Disruption: Digital Transformation, “Uberization”, IoT, etc.
IT environment needs to transform drastically to address the new ways of doing business. This is often a business led journey and implies applications are broken down in 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.
Often driven by the CIO who is pressured by the business to deliver more value. Applications architectures are adapted to enable them 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 modern technologies to reduce cost of running infrastructure.
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.
It’s not one size fits all
I would argue application transformation is not one size fits all. Depending of 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 company needs. Rather than starting from the drivers, I would propose we start from the application portfolio analysis.
Let me remind you of the model used. On the vertical axis we have the importance of the application for the business. Is the application or the associated data supporting the differentiation of the enterprise, it’s labeled CORE, otherwise CONTEXT. The horizontal axis highlight the type of application. Back-end, collaborative or innovation related.
Let’s first look at the CORE applications
Core applications are the ones that truly differentiate the application, so it makes sense to start with those. Migrating them to a new platform enabling faster creation of additional functionality and improved user experience, will result not only in cost reductions, but also new business opportunities.
Depending on the type of applications, 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 the 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? However, regardless whether the target environment is cloud or not, a migration may have to made as the current environment may be old from an operating system, middleware and database perspective. Going to the latest versions reduces licensing and support costs.
For Systems of Records, the objective is to keep the applications running as they are. This is why we choose a re-host approach. Whether we do a binary migration or have to do small adaptations in the code for compatibility reasons, the objective is to keep the application working as is.
For Systems of Engagements, things are different. They interact heavily with users (employees, clients, partners etc.), and in many organizations there is a trend to enable the use of tablets and other mobile devices to interact with the application. Opening up the application to a wider audience and enable mobile access most often results in unpredictable utilization patterns. However, one thing is important, the user needs a constant and satisfactory user experience, regardless of the utilization levels. Otherwise the application will not be used for long.
From an application perspective, we need to ensure constant responsiveness. Cloud computing offers us the opportunity to clone parts of the application to enable such responsiveness with higher demand. It’s called scale-up/scale-down. So, we should use this. However, this implies we can duplicate some parts of the application 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 ensure the timing of the transactions is kept. So, the architecture of the application needs to be adapted to take full advantage of cloud. This may lead to a re-factor of the application or, if the technologies used are older and difficult to maintain, a full re-architecting, leading to the 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 makes sense to migrate the application as it typically has a short shelf life. Indeed, either the application is very successful and becomes an enterprise standard (systems of engagement type) or it is trashed and replaced by the next experiment. I would suggest we take the opportunity of starting a new development to move to the new platform. We may envisage to develop the next application using microservices, containers, serverless computing and all the upcoming technologies.
And what about the context applications?
The objective for the context applications is to reduce the cost of running them to a minimum. This implies going, where-ever 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-host, as described above, should be the default option. Let’s invest as little as possible in this class of applications that do not provide us differentiation and business benefits. If we need to do more than re-host, let’s first develop a solid business case. We want to invest in areas where we differentiate, not in me-to spaces.
A simple way to analyze your portfolio.
Taking the time to think through your application portfolio and understanding which application deserves what transformation treatment. The exercise forces application teams to think through the actual value of the application for the enterprise. I would strongly recommend to do such exercise jointly with the business to 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, identifying the route forward and understanding what is critical to get there is mandatory. 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 required now and in the future. I do hope that the approach I have outlaid through those three blog entries give you the tools to help you in that transformation journey. As always, feedback is more than welcome.
Previous blog: Improve your application agility