A Modern Approach To Legacy Software

Forbes

4 hours ago

HAVANA - SEPTEMBER 14: Men relax next to a car as Cuba hosts the week long 14th Non-Aligned Nations ... More summit September 14, 2006 in Havana, Cuba. Leaders from around the world continue to arrive for the Non Aligned Movement that currently has 116 member countries (53 of Africa, 38 of Asia, 24 of Latin America and the Caribbean and one from Europe (Belarus). (Photo by)
Software is new, then immediately old. Rather like a new car, the moment you drive it out of the dealership, it starts to lose value and become old and used. It's a talking point that software engineers ponder over long into the small hours. One camp says that new versions of software are needed all the time, the other (if it ain't broke, don't fix it) camp says that legacy software is still around for a reason, it still works.
There are software administrators and engineers in government IT departments all over the world using database tools from the 1990s. There are banks and financial institutions around the globe running Java and COBOL software language systems from the same epoch. That's not to say that the public sector and finance are necessarily slow; it's just that sometimes these software services just become deeply embedded and entrenched.
VP of engagement and field CTO at technology analyst house GigaOm is Jon Collins. Viewing the world of always-on cloud-native technologies that constantly seek to evolve enterprise IT away from legacy code, Collins says that even though it's a truism that an application becomes legacy the moment it has been deployed; these older COBOL age systems could still perform more effectively if they were given an additional layer of integration and management control.
That integration and management promise is embodied in the comparatively new notion of platform engineering, with its self-service internal developer platform structures that enable developers to manage their deployment pipelines and operations infrastructure.
Does Technical Debt Stifle AI?
Unsurprisingly, it doesn't take AI long to feature in this debate these days. The cloud-native community advocates the need for technologies that far outstrip the big data tools that we considered contemporary a decade ago.
Low-code workflow automation company Pegasystems Inc. is among those warning enterprises over the risks of technical debt and legacy systems in relation to the adoption of AI and onward to quantum etc. The firm conducted a study with UK-based research specialist Savanta, which suggested that legacy dependency happens because organizations can't stop supporting their legacy applications even if they'd like to, because the systems are still business critical.
For its analysis, Pega defined technical debt and legacy systems as outdated hardware, software, or technology platforms that remain in use due to their critical role in business operations. This is despite challenges such as limited scalability, security vulnerabilities, high maintenance costs and incompatibility with modern technologies.
According to Don Schuerman, chief technology officer, Pega, technical debt is the implied (often intangible) cost of additional work or strain experienced when using these applications in business. That strain is often down to the siloed nature of disconnected systems (this app doesn't connect to the backend and show my last transaction… and so on) and the cost of maintenance.
Schuerman says that applications that are resource-intensive to maintain help in 'perpetuating an organizational culture of waste' today. Recognising the fact that some companies (less than 10% in Pega's study) feel legacy applications caused no problems for their business whatsoever, Schuerman and team suggest that almost half (47%) say their oldest legacy application is between 11-20 years old, while more than one in ten (16%) run apps between 21-30 years old.
Pegasystems clearly used its study of legacy mindsets to its Pega Blueprint tool. This is workflow software that developers can use to 'feed legacy process documentation' into so that it can move outdated systems into cloud-ready, future-proof workflow applications. As detailed here before now, technology surveys (even the 'independently executed' ones) generally have a payload of 'findings' that they are designed to deliver.
An alternative analysis of these issues by headless CMS company Storyblok suggested that developers harbor 'widespread dissatisfaction and embarrassment' due to the poor state of the tech stacks they work with. The company thinks that 'an overwhelming number of engineers' say that their technology stack is negatively impacting their job, with some even considering quitting in the past year.
When asked what made these engineers most unhappy in their day-to-day jobs, the chief culprit was 'maintaining and fixing bugs on legacy systems', followed by 'dealing with non-technical stakeholders who don't understand technical limitations' and a lack of clear requirements and constantly shifting priorities. Again, Storyblok has a headless API-first developer-friendly content management system to sell, so it has a vested interest in highlighting the limitations of pre-cloud-native technologies.
Looking at the issues here from a user and business safety perspective, Scott McKinnon, CSO for UK and Ireland at Palo Alto Networks says that legacy IT systems pose a severe, yet too often underestimated cybersecurity risk to organizations across every sector.
'Many businesses continue to rely on outdated infrastructure, software, and applications that were not designed to withstand the sophisticated, multi-faceted attacks that are in use today. While digital transformation accelerates, the foundational components of many enterprises remain rooted in the past, creating vast and exploitable attack surfaces that cybercriminals are quick to leverage,' explained McKinnon, speaking to press this month in London.
Some agree that the UK public sector faces the same challenges, but at an even greater scale, as highlighted by a National Audit Office report. Although UK-specific, this free-to-view report has dedicated sections covering legacy systems and the challenges of implementing digital change in the face of outdated technologies.
"The escalating challenges of technical debt are causing critical vulnerabilities across organizations globally. This is about far more than just legacy hardware; it encompasses accumulated shortcuts, unaddressed architectural flaws and the continued reliance on software and systems that are no longer supported or patched,' said McKinnon. 'As organizations rapidly adopt new digital initiatives, the underlying foundational technical debt creates a dangerously brittle security posture, providing easily exploitable avenues into critical assets that modern security solutions struggle to adequately protect."
In search of the bottom line here, we may need to realize that legacy software will always exist. When (or if) we do get to a point where all enterprise applications are cloud-native and therefore more continuously updateable, we may have already entered the age of quantum computing, so even freshly cut cloud code will start to smell like it's past sell-by date.
Yes, there are legacy software issues, yes modern workflow technologies are more efficient, no, we can't replace all legacy software tomorrow, no, generation-Z software developers are unlikely to learn COBOL rather than Python, yes, we need to find ways to live in a diverse world of dynamic software that's still changing. That might ultimately be what a modern approach to legacy software ends up meaning.