Modernising Your Application Landscape - Where to Start ?
Businesses face increasing costs and risks trying to maintain a growing body of aging applications. These applications often consume more than 70% of a businesses' IT budget, yet are increasingly out of alignment with business goals and needs. But unsure of how to tackle a modernisation project, businesses often kick such initiatives into the long grass...
This only exacerbates the problem and will ultimately lead to commercial death by a thousand cuts.
Where to start?
This process can be achieved and all information captured using the world's favourite 'jack of all trades' tool - Excel. Alternatively, a Project & Portfolio Management (PPM) tool will help to gather the required information, give real-time views on 'portfolio performance' and aid the overall decision making processes.
When assessing each application, prioritise by aligning with overall business priorities - e.g. supporting business growth, cost reduction and business process improvements. This will help also to draw out modernisation requirements for each application.
One size does not fit all.
Each application will have its own set of modernisation requirements. Consequently, a suitable modernisation strategy needs to be determined for each.
Modernisation strategies that leverage cloud services fall into a number of broad, industry recognised, categories - I provide an overview of each below:
Editing: “Modernising Your Application Landscape - Where to Start ?”%NAV_INIT%
Redeploy the application to a different "hardware" environment e.g. on premise virtualised hardware, private/public/hybrid cloud using Infrastructure as a Service (IaaS). This is typically done to reduce cost and/or increase system reliability.
The main advantage of re-hosting (no application architecture changes) is also it's greatest limitation however, as the application may not be able to take advantage of virtualisation and cloud capabilities such as scale-out and high-availability. Be aware that critical applications with specific workload requirements may not migrate well to IaaS at present. IaaS providers offer facilities to assess application workloads to determine their suitability.
Refactoring the application to enable it to run in a private/public cloud using Platform as a Service (PaaS).
In this scenario, the PaaS provider manages the infrastructure plus container and application framework (e.g. Oracle Cloud or Microsoft Azure App Service). The application needs to be refactored to work with the platform (the scope of which can vary significantly), but having done so, the application can take advantage of most IaaS benefits and all the services PaaS has to offer. These include retention of development skills and languages, agile testing and deployment, scale-out, high availability & disaster recover. The limitations include risks of PaaS vendor lock-in, service maturity and potentially increased integration complexity with on premise applications.
Enhancing the existing application to support modernisation requirements. This involves continuing to leverage the existing application framework and extending the existing code base to add functionality and value directly, or integrating with new technologies. Technology integration options are almost boundless, but examples include Enterprise Search (e.g. Solr ) and adopting a new relational database engine ( e.g. Microsoft SQL Server or Oracle RDBMS). When revising an existing application, consider also the benefits of re-hosting and re-factoring. These may prove in-practical in the short term, but ensure technology choices you make now don't prevent you from re-hosting or re-factoring in future.
This involves re-architecting and rebuilding the application to take advantage of a new application framework or platform (PaaS) and results in many of benefits of refactoring. This approach is relevant where existing applications are built on application frameworks or developed in languages not available through PaaS. Consequently, new skills need to be acquired and re-development scope can be significant, but the lure of increased productivity and capability may be sufficient to sway decision makers. Like refactoring, limitations include risks of PaaS vendor lock-in, service maturity and potentially increased integration complexity with on premise applications.
This involves replacing an existing application with a commercial offering, on premise, or in the cloud using a Software as a Service (SaaS) provider.
Typically, the bigger the application, the larger the benefits of moving to SaaS, as application, platform and infrastructure management become the responsibility of the provider - who are able to operate at economic scales unachievable by most businesses. On the flip side, the bigger and more tailored the application being replaced, the greater the upheaval for the users, having to adapt or redefine business processes to conform to the standard application.
Most SaaS providers offer some customisation capabilities. Investigate these closely to understand the level of flexibility and customisation available, as these do differ dramatically, depending on the maturity of the SaaS platform. Salesforce is a good example of a mature SaaS provider, with great customisation capabilities.
Review & Repeat
Application modernisation is not a one off exercise; instead, like many strategic activities, it is a continuous process that requires regular review and reassessment to ensure the application landscape remains aligned with business goals.
About the Author
Nick Rumble is a Technical Solution Architect at Instrumentum and helps leading software vendors and businesses to migrate their products, applications, tooling and processes to new platforms and technologies, giving them competitive advantage and the tools to scale up their businesses. Contact Nick here to discuss your application modernisation or migration requirements.