A Glitch in the Matrix

Su and Roger take a light hearted look at why your Code doesn't always work as you expect.

What do being shut out of your bank account, not being able to connect your Smartphone to your screen in your new car, failures in the US benefits systems, the mass leakage of personal data, and chaos in airline booking systems all have in common?

If you guessed "Legacy IT Systems" you'd be right. We've all been there! The buggy old "Legacy System" that just doesn't do what you want it to anymore. There's barely enough money to fix it, let alone replace it, so you just get used to working around it.

When the State of New Jersey's Disability Automated Benefits System crumbled under the weight of all the newly created jobless due to COVID-19, the State Governor went so far as to call for COBOL Programmers to voluntarily come out of retirement to fix it!

In our experience, even an operating system that hasn't been supported for a year or so (Windows 7) won't always play nice with modern internet security, and don't get us started on Vista!

Yet Governments, banks, and major corporations worldwide continue to rely on systems that in some cases pre-date the internet written in Programming languages that have long ago fallen into disuse, on operating systems that are no longer supported by their manufacturers, for some of their most basic functions.

There are reasons for this. IT projects are expensive, budgets are tight, and the temptation to patch, upgrade, and fix the old system, rather than starting from scratch is understandable. Old systems often work just fine, doing what they were designed to do, back in the day when your computer system lived in an entire room and had less computing power than the device you now carry in your pocket.

And there's the rub. Today's society is unpredictable, fast-paced, and fast-moving, 24/7, 365 days a year. Companies more than ever are expected to pivot rapidly to cope with the changes, and consumers and company stakeholders want the responsiveness to change that they get on their mobile phones, on their work systems.

The government doesn't help, with each new change in legislation leading to new information collection and analysis requirements which were unimaginable 10, 20, 30, or even 50 years ago when some of our legacy systems were conceived and designed.

This leads to the legacy system being updated and upgraded piecemeal, with new layers of systems and Apps, written in different programming languages, and even on different operating systems, being grafted on to cope. Data gets duplicated, silos emerge, and no-one responsible for the current system understands how the systems underlying and interconnected with it work, or what their limitations are.

Let's take the US Navy's HR system, currently being updated for around $167 million. It is founded on 9 different Operating Systems, uses 21 different Programming Languages, to build 55 different interconnected IT systems running 223 different applications between them. The oldest parts of the system date back to the 1960s, with not entirely successful attempts to modernise in the 1980s, and the 1990s, and piecemeal additions since. (Oddly enough though, having many interconnected small elements like this can sometimes be a hidden advantage, which we will come back to later.)

Add in decades of underinvestment on routine system maintenance and updating, and it's a wonder anything works at all.

And that's before COVID-19 massively accelerated this process.

So, you may ask, how do I recognise if I have a potential issue with my Legacy Software?

Our feeling is that you probably already know, you just don't want to think about it. Maintaining, upgrading, or replacing an old Legacy System is a budget-busting project, of the kind that make Senior Management understandably twitchy. So, once an IT System is up and running, there is little motivation to plan for its eventual retirement. Instead, Managers seem to expect the system to be cheap to develop, last as long as possible, and cost as little as possible to maintain and update, while continuing to cope with a bewildering variety of new demands that could not have been anticipated at the outset.

But the short answer is, that if any of the hardware or software in your system is out of support, or no longer supplied, you potentially have an issue. If your system-architecture is fragile, or overly complex, your documentation is incomplete, missing, or contained in someone's head, or there are areas of it that no-one understands anymore, you almost certainly have an issue. And if years of lack of investment in routine maintenance have resulted in increasingly bigger bills when something does go wrong, you definitely have an issue. Finally, if any of it is written in a Programming language that is no longer commonly used, or worse, no longer taught, you don't just have an issue, you have a massive problem, just waiting to happen.

So, how do you prevent your shiny new system from eventually becoming a Legacy System that no-one understands?

The bad news is, that with the pace of change in the modern world, you probably can't. But you can budget for future maintenance, and plan to replace elements of your system as they go out of support, become obsolete, or no longer meet the business needs. We know IT is expensive, but underinvestment is still the number one way to end up with a system that ages faster than it needs to.

So, back to the US Navy, and it's proliferating Apps. We think that system is probably too far gone, and we are glad it's someone else's problem, but, if you've already got a system made of different pieces you can tackle them one by one, and make the project, simpler easier to manage, and deliver benefits sooner. And like everything these days it's even got a buzzword. 'Microservices architecture'.

The US Defense department published a report in May 2019 entitled "Software is Never Done", which sums up this approach. The report views Software Development not as a project which comes to an end, but as "an enduring capability that must be supported and continuously improved throughout its lifecycle."

Another phrase you may have heard is DevOps. This means breaking down the silos between Software Development, Operations, and Support, so that the operational system is always "underdevelopment", continuously being improved, tested, and deployed.

This is the approach we prefer at Gamma Science, where we offer Development, Operations, Maintenance, and Continuous Improvement, developing a relationship with our clients over a period of years. Our newest big project is built upon Microservices, and an Agile approach to Project Management to deliver a system that can grow, change, and pivot with business needs. It's not something you will get from employing single freelancers, or offshore services, piecemeal.

In other words, Software is for Life, not just the Current Budgeting Period.