After you have mapped your application ecosystem as best as you can, you should begin work on prioritising which applications to modernise first.
Lots of variables can help you to determine a priority order but it’s important to remember that it’s not rocket science. It’s mostly just a common sense approach to evaluating and balancing the various factors and needs of your organisation.
Security and maintainability are important reasons to modernise legacy applications. If software ages and is not maintained, then security vulnerabilities can be discovered over time and it can become difficult to roll out the required upgrades to plug these holes. Security and maintainability come hand in hand.
It’s also important to consider budget constraints. These may result in you choosing a particular transformation approach for an application or in deciding to modernise a different application altogether. In making these choices, you will need to weigh up the business value of transforming an application against the technical effort required to do so.
What affects prioritisation?
Some modernisation tasks may take longer than others or take longer than expected, so you might find yourself needing to juggle conflicting priorities. You may also find that a new piece of information surfaces when you are following up on your application mapping that has a knock on effect on your priority order.
While it’s important to be aware that these issues might crop, you can get on with prioritisation by weighing up technical effort and business value.
The diagram above serves as a simple guide to how these factors might steer your decision. Using the attributes you have collected during your application mapping, you can identify the technical effort an application may require and the business value it represents.
As mentioned, the security and maintainability of an application are key considerations when prioritising. However, you might also have an urgent need to alter an application’s behaviour to add a new or adapt an existing feature based on changing user needs. If it is difficult or impossible to add or change the functionality of an application in its current state, the business value of the feature change may be significant enough for the organisation to trump all other considerations.
Review priorities regularly
Just as you needed to create a single source-of-truth when mapping your applications, you need to create a single list of applications to track your transformation priorities. This should be reviewed on a regular basis because priorities can change if, as mentioned, new information is gathered.
Set a recurring review session in the calendar and remember that if no change in prioritisation has occurred, it’s not a waste of a review meeting – it just confirms that your current order is still correct.
If priorities do change, it’s not anyone’s fault either. You should just accept that a change in priorities has occurred, that you’ve caught it early on and that you can therefore pivot.
What are you trying to achieve?
Without a priority order list, you’d be taking a gamble on which application to modernise first.
What you actually want is a list of prioritised scores for each application, based on the attributes from the mapping work you’ve already done. This scorecard will help you to make an informed decision about which applications to work on first. The quadrant diagram above, paired with your mapping information, will allow you to rank applications into your prioritised list.
You may need to do a few iterations of your priority list before deciding on an initial order because a priority for one application might affect another. Upcoming deadlines is one example of how applications may affect the priority of others, potentially around support contracts or licence renewals. Until you have done one iteration of all applications, you won’t be able to compare those deadlines against one another. However, this will be possible in a second iteration.
This is why reviewing the priority list at regular intervals is important. You can check what progress is being made and, if slower than initially estimated, revise your priorities to account for changes. By doing this, you’ll ensure you are not left needing to renew a costly licence or contract for one application because the transformation of another took up all your time.
Gather different viewpoints
It is important to consider the people in your organisation that might use or be involved with the application.
For example, the product manager and the service owner might see different parts of the picture within the organisation. Similarly, if different departments are involved in the support and running of an existing application, they might have different needs to factor in.
Technical factors
When considering the technical effort required to modernise an application, some questions worth asking are:
- How up-to-date is the application?
If it is a bespoke application, you need to consider the versions of the programming language and application framework that it has been written in. How many versions behind the most recently released one is the application? What are the known security vulnerabilities of the version that your application is currently using? The difference between versions will steer the technical effort required, as upgrade paths are not always clear or simple. Plus, frameworks and other third-party dependencies might not just be drop-in replacements.
If it is a Commercial Off The Shelf (COTS) application, how many versions behind the most recently released one are you? Is there an automated or clear upgrade path you can follow? Will an upgrade break any integrations that expect functionality or data to be available in a particular format or structure? - How complex is the application?
For bespoke applications where you have source code to maintain, is it written with hundreds of lines of code or hundreds of thousands of lines of code? Each line of code increases the complexity of maintenance and the burden on ensuring that functionality does not break. - How well tested is the application?
With the application complexity comes the question of what sort of automated tests are there for the code? If tests exist that can check if functionality works as expected, you can use those as a safety net to ensure it works as expected when upgrades need to happen. In this way, you can ensure other applications or users that interact with it won’t have any surprises. - When was the application last released?
If an application hasn’t been released in a while, there is the risk that instructions or even automated pipelines to deployment might be out-of-date or broken. This might be a hurdle that blocks you from putting a modernised application in front of users.
Business/organisation factors
When considering the business value of modernising an application, some questions worth asking are:
- How much are licences costing you?
For COTS, how much do the licences cost for the application? Would it be worth saving the money for this license by replacing COTS with a bespoke application? Also, is there a renewal deadline? Would you like to save money by having the application replaced or decommissioned before that date? - What support contracts exist?
Depending on how COTS or bespoke applications are hosted, do you have to pay large support contracts that are squeezing budgets? If you want new functionality or to change existing functionality, do you have to pay large fees? - Does the COTS feature roadmap align with organisation?
Before making the decision to remain with a COTS application, does the future of that application match the predicted needs of your organisation? Might the company that develops the software take a radical new direction with the application? If so, have you considered that you might be stuck with the version you have or be forced onto a bespoke system later?
Considering interdependencies
It’s important to consider interdependencies between applications while you are prioritising. What you want to avoid is duplicated or wasted effort when modernising applications that affect others.
If an application depends on another directly, or further down a chain of dependencies, do you need to consider which order you modernise those applications? If you modernise one of the applications, does that mean you’ll then need to alter the way that application communicates with another?
You wouldn’t want to finish modernising one application and then start with others, to find these subsequent applications have changed in such a way that you need to revisit the first one to ensure it continues to communicate.
Develop a few iterations of your priority list using the application mapping work you’ve done to identify interdependencies and work out the order for prioritising these dependency chains. After all, the destiny of one application’s modernisation may be tightly coupled to another.
Choosing your top priority
If we look back to our quadrant diagram:
A workshop would be an ideal format to iterate through your list of applications a few times to work out your first priorities. The iterations of the list can be based on the factors we have discussed so far and listed below. After each iteration, the priority may change and should be reordered accordingly:
- Business value
- Technical effort
- Upcoming deadlines
- Interdependencies
With the two axes in our quadrant diagram, technical effort and business value, you’ll need to ensure that you invite the correct people to give an opinion on each from their different perspectives.
Some example prioritisation scenarios may be:
- A number of applications that have a number of dependency upgrades available that contain security fixes. So long as they pass automated tests highlighting that the upgrades will not break functionality—as this would increase the technical effort required—these could be updated rapidly with the benefit of increased security over a wide area of applications. These would be low technical effort but mid-high business value.
- An application that has an expensive support contract renewal looming but is not easy to change to meet new user needs. If a bespoke solution could be created to replace it, that would mean this application becomes a low business value item and could be decommissioned, so that the costly renewal costs can be avoided.
- A legacy bespoke application that is of high/critical business value, though also high technical effort to modernise. The risks of not being able to fix security vulnerabilities and make changes to meet user needs means this should be a top priority, as the risk to the organisation is too high if it were to fail.
- Applications that don’t pose a significant risk to an organisation due to low business value and low technical effort that can be dealt with at a later time once the higher risk items are handled.
After the prioritisation workshop, you may have a clear priority list that allows you to decide on the best transformation strategy for the top application, before working your way through the other applications. If the top positions in your list are still hard to determine though, things may become clearer as you consider the transformation strategies for each application.
Either way, let’s continue by looking at the various transformation strategies you could employ in the next section.
This blog post has been co-authored by our Senior Technical Advisor David Winter, CTO Luke Morton, Technical Consultant Ben Pirt, and Content Consultant Joe Carstairs. It is part of a series that covers modernising legacy applications. We are always trying to improve our blog and we’d appreciate any feedback you could share in this short feedback survey.
If you are interested in learning more about this topic, our team has released our ‘Modernising Legacy Applications In The Public Sector’ e-book which will empower you to define and implement the right approach for your organisation to make legacy applications a thing of the past. Download a free copy here.
