Software and software skills decay. Today’s cutting-edge solution can soon be tomorrow’s legacy liability, which ought to be food for thought when modernising your digital banking applications. How long until it’s half as valuable as you once thought?
Half-life defined
Half-life (t½) is the time required for half of an entity to decay. For example, the half-life of uranium-238 is about 4.47 billion years. By comparison, the half-lives of IT systems are fleetingly short. Recognising how and why software assets degrade should inform your approach when sourcing software solutions—especially those used to win, serve, and retain customers.
Erosion of fit
Business requirements change—often even during development. And in the realm of digital banking, customer needs and expectations change faster still. Changes to your products and new offers from competitors make this a particularly dynamic software market segment.
Agility is crucial. The ability to launch quickly and rapidly adapt and enhance your digital banking applications will ensure that they stay relevant and valuable for your business and, most importantly, your customers.
Technology churn
Technology evolves at a phenomenal pace, especially since the advent of Cloud computing. Take Kubernetes, for example. It didn’t exist before 2014. In its seven-year history, it has had 24 versions, each superseded in little more than three months.
JavaScript frameworks—collections of pre-built JavaScript code used to speed up development—continually evolve. “React,” the most popular framework in use today, has had 46 releases in its nine-year life span. That’s roughly five releases each year.
The Open Web Application Security Project (OWASP) is a non-profit organization that works to improve software security. Every year OWASP publishes its top ten web application security risks. New risks are continually identified. Worryingly, according to the World Economic Forum’s Global Risks Report 2022, there’s a worldwide shortage of over three million cyber-security professionals, making it increasingly hard for companies to secure their systems.
In conclusion, software, just like any other asset, requires maintenance. Even if business requirements stay the same, without maintenance, you risk degradation of performance, maintainability, and security as underlying components are superseded or new security risks are identified.
Decay of knowledge
Staff turnover can quickly cause support challenges for in-house developed software. In the UK, the Prudential Regulatory Authority (PRA) stipulates that financial services firms attest to the safety and soundness of critical systems and service providers.
A digital banking platform is a “critical system” for which the PRA will hold you accountable for operational resilience, change control, and ensuring sufficient staff and expertise to support it.
Moreover, the rapid churn of technology imposes a continuous learning challenge on developers when, for example, different JavaScript frameworks deprecate or go out of vogue.
This brings us to the notion of the half-life of software engineering knowledge. Steve McConnell, the renowned author of Code Complete and More Effective Agile: A Roadmap for Software Leaders, wrote:
“You often hear people say that software development knowledge has a three-year half-life: half of what you need to know today will be obsolete within three years.”
More recently, Eric Bloom, Executive Director of the IT Management and Leadership Institute, said:
“A techie’s skill set from a marketability perspective has a two-year half-life. The exact set of skills you have today will only be half as marketable two years from now.”
The implications for digital banking solutions
The speed of change determines the half-life of an in-house developed software solution:
- How quickly will business and customer requirements change?
- How rapidly will technology changes undermine software maintainability and security?
- How long will it be until staff turnover and technology churn jeopardise your ability to support an aging system?
Measured against these criteria, digital banking solutions need to be built for change. You need the agility to rapidly extend and enhance customer-facing products and services. Maintainability and security will be top concerns.
Moreover, the rapid pace of technology churn—particularly associated with cloud, web, and mobile application development—will require continuous investment in software engineering skills.
The differentiation conundrum
The arguments above should cause all but the largest financial services organizations to think long and hard before embarking on any custom software development project. The safer option is to invest in packaged software solutions where the vendor is responsible for continually maintaining the code—eliminating the half-life concern.
But could the adoption of packaged software solutions hinder innovation? In digital banking, differentiation to provide unique customer experiences is crucial.
Our eBook “Three Strategies for Modernising Digital Banking” explores the topics of differentiation and the need to support agile, continuous change. It includes case studies from DF Capital, Toyota Financial Services UK, and Darlington Building Society, all of whom partnered with ieDigital to rapidly improve their digital banking provision.
