5 key steps when thinking about App Modernisation.
- Peter St Clair
- May 6, 2024
- Insights
For many organisations, competing strategic priorities, differing operational perspectives, and limited resources are common challenges that halt and put application modernisation projects in the ‘too hard basket’.
A business case will help you define and clearly articulate the reasons why your business should modernise its legacy application. While you and a few colleagues may not need convincing, think of this as a powerful communication tool to get the majority, if not ALL, stakeholders onboard.
While some businesses may require a 30-page business case, for mid-market organisation and enterprise business-units, we recommend that you keep it clear and concise – the reality is that not many people have the time to write or read a thesis.
Define the project.
Before you plunge chest-deep into business case mode, it’s important to have a clear understanding of what the application modernisation project will look like.
There are many ways to skin a cat, but to deliver a successful modernisation outcome, you must always prioritise, define clear scope, and determine the most suitable approach for any work to be undertaken.
1. Priorities
Determining which application you should modernise and why is a critical first step. Don’t try to push for all applications and systems to be modernised. When there are significant barriers against you, it’s important to prioritise your battles and aim for a project that will allow you to prove it and then scale it.
Here are some questions to ask to help prioritise:
- Is this a strategic or tactical solution?
- Is the application adding real value to the organisation?
- How stable is the current application?
- Are there key concerns that are causing the business continuous headaches, or exposing the business to undesired risk?
2. Identify the cause of current problem
The six drivers (Business Fit, Value, Agility, Cost, Risk and Complexity) can be used to not only define the problem you need to solve, but they can also identify the probable cause.
The cause of the problem can originate from three main aspects of the software:
- Technology
- Architecture
- Functionality
Cost, complexity and risk issues are most likely caused by the technology used to build and support the application.
Business Fit and value issues are most likely caused by the functionality.
The architecture and structure of the application can contribute to both and has an impact on complexity and agility.
3. Approach
Once you have identified the cause of the problem, this then allows you determine the best Application Modernisation approach to take.
For that, you need to understand how each modernisation option is able to correct problems or improve the quality of technology, architecture or functionality aspects of the application component.
Approach
Also known as
Description
Encapsulate
Service-enable, re-interface
Encapsulate data and functions of the application — and make them externally available as services via an API.
Rehost
Redeploy the application component to other (physical, virtual or cloud) infrastructure without recompiling, modifying the application code, or modifying its features and functions.
Replatform
Migrate the application component to a new runtime platform. Make minimal changes to code to adapt to the new platform, without changing the code structure, features or functions it provides.
Refactor
Improving and optimizing the internal source code structure of an existing app while preserving its external behaviour to remove technical debt and to improve non-functional requirements.
Rearchitect
Essentially, it is architecture and design modernisation.
Rewrite the application code so that you can shift it to a new application architecture and fully exploit new and better capabilities of the application platform.
Rebuild
Rewrite, redesign
Delivering the same business functionality but using modern coding techniques and architectures.
Replace
Repurchasing, Rethinking
Eliminate the former application altogether, and replace it, rethinking the entire business process that a system is designed to deliver on
4. Scope
The scope of the modernisation project is another important consideration. Define the real business need and separate it from a ‘wish-list’, wishes can be expensive and add substantial risk. Create two lists ‘In-Scope’ and ‘Wish-list’. A formally managed ‘Wish-list’ will help reduce the risk of scope creep, and help determine design, functionality and features for future interactions of the application build. The key is to get started, and you want to provide the biggest impact with minimal effort.
Key questions to consider when thinking about scope:
- How well are the functional aspects of the application understood?
- What other systems does it integrate with?
- Do the current functions meet current business requirements / demands?
- What level of flexibility/agility does the application need to achieve, to meet current and future business demands?
- Can you start with a Proof-of-Concept (PoC) or Pilot project to get the project started?
Choose the modernisation approach with the highest effect and value while also considering cost, risk and impact. It’s important to understand how each modernisation approach improves the relevant aspects of the application (technology, architecture and functionality) and has the ability to solve the problem.
As you can see, as the effort required increases for each of these approaches, so does the impact on applications and on the business. Taking into account your appetite for both cost and risk, it is important to select an approach that has the desired effect, but with the minimum of effort and impact.
5. Who do you need onboard?
Finally, another critical factor before drafting your business case is to think about your audience. Who do you need to onboard?
- Decision makers – who will ultimately give it the green light for funding and resources?
- Influencers – Are there any internal champions who could help influence the final decision?
- Stakeholders – Who will the project impact? Will you need their buy-in to ensure a successful project?
This will determine how technical or non-technical your business case is, and where you need to provide more context and explanation.
In our next post, we will be providing a quick template to help you build your application modernisation business case.
Crafting the business case
Armed with this understanding, crafting a compelling business case becomes more manageable. Tailor the case to your audience, whether technical or non-technical, and highlight the benefits of containerisation in addressing specific pain points and achieving strategic objectives.
Building a business case for application modernisation, particularly with containerisation, requires careful consideration and strategic planning. By prioritising applications, identifying root causes, choosing the right approach, defining scope, and engaging stakeholders effectively, organisations can navigate the complexities of modernisation with confidence.
Ready to take the next step? View our application modernisation solution offerings.
Lifting the Lid on Containerisation
Our Principal Consultants have put together this whitepaper to show how, by adopting the right containerisation solution and implementing it correctly, businesses can accelerate innovation, improve agility and gain a competitive edge in today’s rapidly evolving digital landscape.
