The 7Rs of Modernisation – a roadmap to app transformation

Digital transformation is well underway, with tech teams around the world hitting the ground running to try to update their organisation’s digital experiences at the rate that consumers demand. The way enterprises have integrated technology slowly, over time, means that many have a sprawling web of half-fit for purpose apps behind the scenes that could be improved, updated, or cut altogether.

Modernisation requires a healthy dose of elbow grease – not quite as simple as tapping ‘update’ in the app store. A thorough assessment of an organisation’s systems could potentially reveal that there are thousands of highly diverse applications and services to dig through and review. Air France-KLM, for example, has been working on modernising 2,000 applications. Larger organisations could have even more, complicated even further by business ‘life’ events like mergers and acquisitions.

It might seem that the primary motivation to modernise is for technical reasons – why not make everything run smoothly and quickly? While the beauty of technology is that it’s constantly getting better, in an organisation, it’s important to understand the business reasons for modernisation too.

The impact of an app or service will eventually be determined by how fit for its purpose it is – if it works well for the business. This actually makes your work easier, as not every system needs to be the highest spec possible. There’s no point buying a Ferrari to do the neighbourhood school run.

We’ve found that there are seven different ways of modernising any given app. Perhaps humanity will one day discover an eighth, or ninth, and tenth if we survive long enough, but these seven approaches come up over and over. By design, these seven dispositions all begin with the letter R so that we can label them “The Seven R’s.” Here they are, ordered from least to most effort, risk, and value: Retain, Retire, Rehost, Replatform, Refactor, Rewrite, and Replace.

Retain

As the saying goes: if it ain’t broke, don’t fix it. If an app is old but still serving its purpose, keep things running as they are. This is probably the default option for most apps in your portfolio, as doing nothing can be a wise strategic choice when there are likely other apps that more urgently need your attention.

Retire

As an organisation changes and develops, sometimes the need for an app simply runs its course. There’s no need to update it – simply decommission any end-of-life applications. If your analysis has found that the application is used very little, has been superseded by another application, or is no longer profitable to run, it can be decommissioned without worrying about upgrading or replacing it. A good example here is the Minitel service, once the world’s most successful online service. Once the Internet gobbled up all of “online,” Minitel was finally retired after 32 years of operating in June 2021. Applications that were purpose-built for regulations that no longer exist are another common app to retire, as are applications that run parts of your business that no longer exists.

Rehost

Often called “lift and shift”, this is repackaging and moving existing applications with as few changes as possible. This is sort of like just copying an application and all its data to a new computer. Typical examples are cloud and data-centre migrations or the process your company has been through while virtualising its data centre.

Replatform

Now we get into the meat of what might typically be considered modernisation. Here, the application remains the same, but there are significant changes to the underlying technology stack and platform (runtime, framework, middleware, operating system) of your app. This can require changes to the actual application itself, but they should be very minimal. For example, replatforming might mean moving from an Oracle WebLogic Server to Spring Boot, from .NET to .NET Core, from Windows or AIX to Linux, or moving your applications from virtual machines to containers.

Refactor

In this type of modernisation, you’re finally changing your application’s code deliberately. When you refactor, you redesign and rewrite parts of your application to take advantage of new platforms and capabilities. This is distinct from rewriting in that the functionality of the application stays the same and is not updated: just the “internals” of the app are changed. This is sort of like keeping the exterior and interior of your car looking and operating all the same but replacing everything under the hood.

From video games backends such as Diablo II, to core banking systems such as the Open Banking evolution and governmental services exposed to citizens over the internet such as the German online access act, this option is often the default cost-effective choice to rejuvenate existing systems while bringing them to a new era.

Rewrite

The name says it all: sometimes it’s time to start from scratch and write a new application. Your organisation still needs what the application does (for example, registering for fishing licences or scheduling ice machine maintenance), but the old application no longer solves the problem well and is challenging to maintain.
Instead of just duplicating the same screens and workflows but with new fonts and colours, this type of modernisation gives teams the chance to reimagine how people interact with the application and how it functions. The only real option to modernise a digital user experience is usually to rethink and rewrite it from the ground up. There is nothing like throwing a bit of fairy dust on the frontend code to radically ameliorate usability and ergonomics.

Many inspiring examples of application rewrites can be found in the world of software vendors, where operating systems, middleware components, and frameworks of all kinds have been rebuilt from scratch with the newest available hardware and infrastructure paradigms: x86 and 64-bits architectures, parallel processing, and new end-user devices.

Replace

In this scenario, you still need the functionality that the application provides, but you no longer find value in the control and customization abilities that come from owning the application. Instead, you outsource it by replacing it with a commercial off-the-shelf (COTS) application, often a Software-as-as-Service (SaaS). The same “outcomes” are achieved, but you now use a third-party or outsourced option.

Such transformations are straightforward for highly standardised systems like mail or file servers, by simply switching to an already-familiar commercial software like Outlook.

For non-standard, end-of-life systems, this is often the most effort-intensive option. Transitioning your highly customised Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Human Resource Management (HRM), or e-commerce system to another, for example, will likely be a daunting task. But see this as an opportunity for freedom instead, as all that customisation over time tends to become a weight keeping you lagging behind.

Choose right

While the technical side of you might have a preference for one method or another, the final decision for what to do with each app should be made with those aforementioned business goals at the forefront of your mind. Many modernisation project issues come about because the overall business goal isn’t given due consideration. Combining the two, however, turns modernisation into an exciting rather than daunting task.

The post The 7Rs of Modernisation – a roadmap to app transformation appeared first on JAXenter.