Why software modernization matters to business

When we talk about ‘software modernization’, there’s a lot of confusion.

Some argue that older software that still works— often disparagingly referred to as ‘legacy’ software— isn’t out of date at all, precisely because it still works.

Some argue that mainframe software— widely installed in financial organizations and research institutions around the world and in use every day— isn’t out of date either, because it has a functional job to do, the results of which continue to be welcomed.

Others still argue that anything but cloud-native software these days ranks as something from the past.

Why we love cloud computing

The cloud-native converts argue that anything previous to the ‘as-a-Service’ era of web-connected software lacks the flexibility, scalability, and cost-efficiency of the cloud.

They also point out that because open source techniques, models and methodologies proliferate across cloud platforms (and even the previously proprietary-only big players now embrace open source), that this must be seen as the route to modern contemporary software.

But it’s tough to rip-and-replace. If elements of an organization’s software stack look a little dated, yet they are running in a stable and predictable manner, then why would anyone want to replace them?

The open-source argument comes right back in here straight away i.e. many of these older packages won’t be open to the community contribution model of collective input and so, logically, they will eventually be outstripped by the greater levels of functionality we find in really modern software.

Future-proofing proof points

So we know that older software that still performs a useful functional job is harder to get rid of. But business today moves quickly, more quickly than it did before the turn of the millennium and many companies in 2019 will still be holding onto some packages that date back to 1999 or further.

Technology analysts argue that this is a bad strategy for future-proofing. The shape of IT has changed over the last couple of decades and with it the shape of connected business has too. Mitigating risks and positioning the business’s IT systems for future innovation is made more difficult if you’re driving a classic car, however much nostalgia you might have for it.

Modern workloads

What we’re driving at here is a certain degree of inevitability.

The fact that we must now look to the highly competitive nature of x86-based public cloud systems (in terms of both their price and performance) can’t be ignored. The fact that we’re pushing massively-scaled data workloads to public cloud systems that would not be possible on much of the installed base of software from yesteryear can’t be ignored. The fact that quantum computing is around the corner or, more realistically, Quantum-as-a-Service from a cloud services provider, and that this has the potential to disrupt every aspect of IT with its wildly increased power— also cannot be ignored.

There’s another inevitability if we hold onto legacy software too long (ouch, sorry, we used the L word), and it’s related to the new fabric of computing in the open-connected cloud era.

Older systems will often be built upon a convoluted entanglement of software interdependencies. One part of the system needs to talk to another to get the information it needs to execute processes A, B or C. And if one disconnect occurs, then the interdependent relationship breaks down.

Modern software still has dependencies and interdependencies, but newer approaches to microservices, application components and Application Programming Interfaces (APIs) have been championed by cloud computing, and the industry has worked hard to make sure there are orchestration tools (Kubernetes would be a good example, but there are others) to coalesce all these more composable elements of computing together.

To use another classic car analogy, today’s software has snap-on wheel nuts, quick-change tires and the fuel intake is constantly open so we can refuel (in software, we’re just talking about ‘updates’, obviously) on the fly and keep running 24×7. Your older vehicle, well, that has to go into the garage shop for a while doesn’t it?

Pricing points

Despite the rationales put forward here and the full scope of this discussion, it often comes down to price.

For many firms running older systems (some of which may be mainframe-based), there may be comparatively punitive pricing models stipulated by those firms supplying the software and its maintenance contract.

Equally though, it has to be said that moving away from older permanent (pay once, use forever) license software can mean that some firms have to prepare themselves for more subscription-based and consumption-based pricing contracts.

In summary, software modernization is a thorny subject in and of itself, but it should form a part of every contemporary organization’s wider IT program.