The risks involved with comprehensive digital transformations are simply too high for many organisations, with a majority settling for more measured approaches. While core enterprise systems are the heartbeat of an organisation, they aren’t immune to the impact of time, and do need sustained investment to keep them relevant, beneficial, and compliant in years to come.
As executives seek to provide assurance to their board and shareholders that their core enterprise systems are futureproofed, they need to weigh up which path of continuous improvement should be taken. For some, a heart transplant (a full rebuild) is the right way forward. For many others, too much is on the line for a complete rebuild of such a vital application, so a pacemaker (a more measured application modernisation strategy) solution is preferred.
Once an organisation has understood the need for and has a business case to support the modernisation of a core enterprise application, the discussion shifts to focus on what type of modernisation is best placed to generate the desired outcomes for the business and its customers.
There are seven types of application modernisation that organisations should consider as part of their due diligence:
- Replatforming
- Refactoring
- Rehosting
- Encapsulating
- Replacing
- Rearchitecting
- Rebuilding
It’s not always a case of choosing one and sticking with it through the modernisation process. There are instances where organisations may start with one then move to another. There may also be two forms of application modernisation working concurrently. The approach will depend on the structure of the technology function, the resources available, the expected timeframe, and the customer outcomes that the organisation is driving towards.
This article explores these approaches and touches on reasons why a business might choose one type of modernisation over another, rather than focus on business drivers that are common across all types of application modernisation, such as removing technical debt, improving development speed, reducing maintenance costs, and so forth.
Rehosting enterprise applications
Rehosting has been referred to as the lift-and-shift modernisation strategy. Some view rehosting as the ‘beginner’s approach to application modernisation due to the relative ease at which it can be accomplished.
What is rehosting?
Rehosting is when an organisation redeploys all or a component of an application to another infrastructure - whether that be physical, virtual, hybrid, or cloud. Rehosting can typically be done with minimal (if any) modification to code, features, or functions.
Why consider rehosting?
Organisations looking to use a rehosting modernisation project for cost-out reasons can reduce physical infrastructure costs almost immediately. Due to the relative ease, this type of modernisation can generally be implemented in a shorter timeframe.
The reduced complexity of this approach is also valued by those who cannot have any disruption to their organisation. As a result, the risk of this form of application modernisation is lower than some of the other forms. Once the migration has taken place, additional modernisation projects such as rearchitecting become more manageable.
Replatforming enterprise applications to the cloud
Replatforming is essentially the next iteration of the lift-and-shift application modernisation strategy that we just read about, which adds in a touch more complexity in order to optimise its performance in the new infrastructure.
What is replatforming?
An application that is replatformed has undertaken minor enhancements in order to successfully migrate to and run on the new platform. These are slight changes to the code itself, rather than the features, function, or even the overall code structure.
Why choose replatforming?
Organisations use replatforming when there is an element of uncertainty that a standard rehosting approach will be successful. Whilst achieving cost-out by removing physical infrastructure costs will take a little longer than rehosting, replatforming is typically a shorter modernisation journey compared to other approaches.
Organisations may also have an impending deadline in which they need to meet, which requires the use of broader cloud capability, including scalability, automation, and additional security. An example of this could be to meet its compliance obligations to regulators, which they are unable to do in their current setup.
Refactoring enterprise applications
Existing enterprise systems can be so woven into and relied upon by other applications, that it is vital to ensure any changes, enhancements, or upgrades do not impede and affect its external behaviour – and therefore the performance said applications.
What is refactoring?
Application modernisation projects that utilise refactoring do so to remove technical debt and enhance non-essential aspects of the application. This process restructures existing code without changing the application’s overall programme behaviour.
Refactoring is achieved by pairing formal anti-patterns in the code base (that are symptomatic of underlying issues) with corresponding formal changes. These can be done in smaller, manageable batches, which gives teams greater confidence in delivering successful transformational outcomes.
Why opt for refactoring?
Refactoring is a perfect choice for organisations looking to improve the maintainability of their application through the removal of technical debt. If budgets are limited, partial refactoring can take place in order to break the project down, validate its worth, and use as a business case to the complete refactoring project.
Encapsulating enterprise applications
Some existing enterprise systems were created in an era where the internet was not used as it is today. As such, the genesis of these applications and the context for which they were designed means they cannot handle modern webloads as well as organisations would ideally like.
What is encapsulating?
Encapsulation in an application modernisation context is the process of adding and temporarily hiding data, methods, documentation, or structures within an existing entity for either transmission, future reference, or the enablement of new capabilities.
Why use encapsulation?
Encapsulation helps organisations to enhance and leverage their core applications, enabling them to optimise the way they operate within modern enterprise environments. One such output is being able to offer these applications as services through an API, which means they can have new front-ends with leading UX practices built on them. The other main benefits of encapsulation are the additional security and reliability that can be embedded into the application.
Replacing enterprise applications
There comes a time in an application’s lifespan when the value it offers the business and its customers no longer outweighs the costs required for maintenance and support.
What is application replacement?
Application replacement occurs when the business can no longer justify its technical debt, deciding to retire the application and replace it with another. A guiding principle for this process is to reduce complexity, for example removing functionality from the application that the business no longer needs and that customers are no longer getting value from.
The incoming application will likely look different to the outgoing application; it may be bigger in scope or smaller; there may be other applications in the business that can pick up some of the functionality. These decisions can be made as part of the scoping and discovery phase in order to settle on the new vision and requirements.
Why choose to replace applications?
As touched on above, there may be existing applications in an enterprise that can pick up additional functionality, which can potentially decrease implementation risk as there is existing knowledge of the new application. There may also be other software services available to the organisation that offer greater cost-efficiencies, providing they meet compliance and security obligations.
Changes in customer, employee, and consumer behaviour may also have made some applications redundant, therefore the need to maintain and support that application can no longer be justified.
Rearchitecting the application
Application modernisation projects will normally have in the early stages of the journey a technology-based architectural review. This architecture review will seek to map out the big picture in which the application operates and how the various software components of the organisation interact with each other.
What is rearchitecting?
When existing technology architecture is deemed unsuitable for achieving future (let alone current) desired customer and regulatory outcomes, the application undergoes significant design changes then subsequent code changes in order to operate as desired.
Organisations who use a rearchitecting approach may also utilise other approaches of application modernisation mentioned in this article, such as refactoring.
Why opt for rearchitecting?
There will be some examples where existing architecture is incapable of operating in a modern enterprise environment and at a level expected by employees and customers. Rearchitecting takes place because the business, its processes, and the technology it now uses has moved on so much that new thinking and engineering is now required, especially with regards to the architecture’s extensibility.
One of the other reasons for rearchitecting is that older technology stacks may hinder innovation and feature development. Therefore, taking a high-level approach, at least at the initial part of the modernisation programme, can work wonders from a time-to-change perspective.
Rebuilding enterprise applications
Some applications have had so much investment and provide such considerable value to the organisations, to the point where it is there competitive advantage, that futureproofing them and increasing their longevity by rebuilding it is a given. However, there is agreement across key stakeholders that the application is uncompliant for various reasons in its current state.
What is rebuilding an application?
Rebuilding an application occurs when an organisation decides that an application warrants being redesigned or rewritten from scratch. This is the 'heart transplant' as described above, yet is done so with another 'heart' or application that is normally cloud-native, and is engineered in such a way that preserves the scope and specifications of the original application.
Why decide to rebuild applications?
One reason why organisations choose to rebuild applications is that they have confidence that the existing system provides them with an unfair advantage over their competition, it is just carrying an unacceptable level of technical debt.
Another reason is that the application works in a very specific context and simply adding APIs or using other modernisation strategies may diminish business and customer value.
And finally, if support for all or part of the application may be coming to an end, organisations will be forced to undertake a rebuild, such as any applications running off Microsoft Silverlight (which support is discontinued in October).
Application modernisation on the cards?
Wherever you are on your digital transformation journey, getting external perspectives can guide your thinking or validate your approach. At Jade, we’re always open to having conversations with business and technology leaders to provide such perspectives and offer value where we can. If this is you, and you’re wanting to reduce the future risks of your modernisation programme, let’s talk.