Benefits of application modernization you can check

The head of operations at a freight forwarder is handed a proposal to modernize the shipment tracking application her customers log in to. Page four lists the benefits: agility, scalability, innovation, lower costs, better customer experience, future readiness. There are twelve in all, each with a small icon.

She has no way to tell which of the twelve would be true for her application, or how she would know afterwards. The list would read the same in a proposal to any company. The benefits of modernization are real, but they are specific, and some of them are not delivered by the work at all.

Benefits that follow from the work

Five results come from the modernization itself. If the work is done properly, they arrive, and each can be checked.

• Security fixes resume. An application on a supported platform receives fixes again. The UK's National Cyber Security Centre is blunt about the alternative: for an obsolete product, "the only fully effective way to mitigate this risk is to stop using the obsolete product".
• Changes get quicker. This is the benefit least visible from outside. Martin Fowler notes that "customers and users cannot perceive the architecture of the software", yet a poor one slows a team within weeks. What you can perceive is the time a small change takes, before and after.
• More people can work on it. A current, documented system can be handed to another developer or supplier. The dependence on one person ends.
• It works where the users are. Screens built for today's phones and browsers, not for the desk of eight years ago.
• Search engines can read it. For a public site, pages rendered so that crawlers can index them, with the existing addresses carried over.

What modernization means in the first place, and how it differs from a redesign, is covered in application modernization: what it means and when to do it.

Benefits that depend on what you do next

The second group is what proposals usually lead with. These are possible after modernization, and none of them is produced by it.

• Lower running costs. New hosting may cost less or more. The saving that is dependable is the one described in the cost of technical debt: less of each change spent working around the old system.
• More sales or enquiries. A faster, clearer application removes obstacles. Whether more people buy depends on the offer, the price and the market.
• New features. The work makes them affordable. Somebody still has to choose and build them.
• Growth. A system that can carry ten times the customers is a benefit only to a business that is about to have them.

A proposal that promises the second group is promising your results, not its own. Search rankings belong here too: the work can protect what a site has earned, and nobody can guarantee what a search engine will do.

How to test a claimed benefit

Three questions turn any line on a benefits page into something you can hold a supplier to, or strike out.

1. What is the figure today? If nobody can say how long a change takes now, or how fast the page loads now, "faster" cannot be shown later. A benefit without a starting measurement is a hope.
2. Which part of the work produces it? "Better performance" should point to a named stage. If it points to the whole project, it will be claimed whatever happens.
3. When will it show? Some benefits appear the day a stage goes live. Others, such as quicker changes, show over the following months. A date for each lets you check them in order. Setting those dates out is the job of a roadmap, described in an application modernization roadmap you can hold a team to.

A benefit that survives all three questions is worth paying for. Most lists shrink from twelve to four or five, and the proposal is better for it.

Which of twelve benefits survived at the freight forwarder

The freight forwarder in this example is invented. The head of operations puts the three questions to the twelve benefits.

Four survive. Security: the tracking application's platform stopped receiving fixes last year, and the first stage moves it to a supported version. That can be checked on the day. Phone use: drivers and customers open tracking links on phones, where the current screens need sideways scrolling; the second stage rebuilds the three screens they use. Speed of change: adding a new carrier takes fifteen working days today, and the supplier commits to measuring it again after the third stage. Handover: the system will be documented so that a second developer can release a change.

Three are moved to the second group and reworded. "Lower costs" becomes "hosting cost to be compared after six months". "More customers" is removed. "Ready for growth" is removed, because shipment numbers have been level for three years.

The remaining five could not be tied to a figure or a stage, and the supplier agrees to drop them. The proposal that goes to the board lists four benefits, each with today's figure, the stage that delivers it and the month it will be checked.

Checking the benefits in your proposal

• Take the benefits list from any proposal you hold and sort it into the two groups.
• For the first group, ask the three questions and write the answers beside each line.
• Ask for today's figures to be measured before work begins. They are needed whatever is decided.

Those starting figures are a baseline, and a baseline is the first thing our website modernization assessment produces. The sample assessment shows one for a real site, including where a measurement could not be taken and why.

Sources

• National Cyber Security Centre, Obsolete products, Device Security Guidance.
• Martin Fowler, Is High Quality Software Worth the Cost?, 2019.