There is a global need for more software to be built as a result of digital transformation, with a dominant focus on customer and employee experience, process automation and modernising legacy technologies.
Here we examine the rationales, recommendations, and rewards now playing out in the software development lifecycle.
Don’t we have enough apps? Surely we don’t need to keep building more software? Doesn’t the company IT platform we use have enough flexibility and customizable options to give us what we want? Can’t we just use web apps as a top-up mechanism to get the rest?
These are all reasonable questions on the face of it – and we can easily imagine any CEO or company Director tabling these kinds of frustrations, and singling out the IT Manager and Enterprise Architect as prime targets for answers.
In truth, we do need more software on a global basis, but there are core reasons why this is the case.
Natural Organics
Part of the reason we need new applications comes down to ‘natural causes’ in a sense. Companies merge and get acquired while they also divest and diverge all the time. This typically creates a need for new IT in the shape of apps and data services.
On an equally ‘organic’ (or perhaps digitally organic) level, some applications just get outdated, out-moded, or outclassed, and usurped by newer operational methods, new human workflows, new device form factors, and so on. We will inevitably always need to keep hold of some legacy applications (after all, they still work, that’s why they’re legacy), especially in areas like financial services. However, if they are not running on the latest version of a platform, then potentially you are creating a security risk. For instance, you may have a core banking system that conducts a very specific function, but if it only runs on Windows NT, that creates a maintenance issue and exposes a security vulnerability.
So, how do we decide what to refactor and migrate vs what to retain? If we look at it from a point of functionality, there will always be some systems of record in any organisation’s back end systems that will verge on being legacy in one form or another. These are by no means applications that have lost their worth; they’re doing the job they were assigned to do in the first place. The challenge we have is that the application is going to get forced, in terms of its modality and form, to evolve to modern platforms, protocols, and standards. The other not inconsiderable problem with legacy systems are the skills and knowledge transfer needed to understand, update, and maintain an often out-dated system.
When the underlying platform that any application works on changes, it typically forces some upper level of refactoring, re-platforming, and migration. This is not all bad news; this process presents an opportunity for us to make that application better at that point. We know that according to Lehman’s laws of software evolution, the moment we give something to a user, their expectations change and the software complexity of a system will continually increase in its lifetime.
These realities validate the argument for software evolution at every level. What we mean by that is, even when a piece of software is doing its job, it will typically be subject to increasing complexity, and this means that ultimately, we will need to evolve that application. Coming full circle here, we can still retain legacy functionality, but the application itself needs to be ported in time to a more contemporary platform.
Thinking more broadly about how software development will evolve next in the era of low-code and no-code platforms, now is the time to ask ourselves what other factors could really drive new app development.
About the Author
Prakash Vyas is Head of portfolio marketing at high-performance low-code company, OutSystems. Prakash is an industry recognised business transformation leader, who brings a unique combination of senior business leadership with incisive ‘hands-on’ technical execution for organisations wishing to grow quickly and profitably. He aligns himself closely to the sales function, working comfortably in complex matrix structures, whilst assuming broad responsibility through a highly driven ‘start-up’ attitude.
Featured image: ©Bakthiarzein
