4Nov, 2020

What is missing in application development lifecycle?

Today if you ask the CTO of any company – “What’s stopping IT from delivering a better ROI?” I bet one of the answers would be – Legacy Applications. While most CTO’s would agree that legacy applications are problem-some, all would agree that such applications are also integral to their daily operations. According to a research by Information Week , 70% of transactions are processed in COBOL. And also 70% of the IT budget is devoted to legacy application maintenance. This “keep the lights on” approach leads to billions wasted in maintenance efforts rather than being spent innovation.

What’s this blog about?

Most of you would already be aware of the disadvantages of legacy applications and I don’t want to bore you with the same reasons. Through this article, I want to provide my perspective on why companies land into this mess and how the standard “software development” lifecycle is contributing to this mess. My hope is that early stage startups or even existing enterprise firms can learn and avoid the problem of legacy applications.

Where does the problem start?

To start, let us describe a standard IT development project. The business team develops a case and getting the budget approved. The outsourced IT vendor/ internal IT team discusses the requirements with the business and development begins. Irrespective of the methodology (Agile/Waterfall) the rest of the path is pretty standard – Development team would work on smaller modules (agile) or the entire product development (waterfall) and hand it over to the QA team for testing. Any business changes are incorporated & tested and the product is launched. There is a lot of enthusiasm and excitement during the development phase and even for a few months post development where the business wants to fix any impending or new issues.

However post that all the enthusiasm about building a great solution dies, users get used to the small quirks, development team moves on the new projects and the business get involved elsewhere. This is the point where an IT application becomes destined to turn into a legacy IT application.

Business is focused on adding new modules/functionalities and not on updating the technology for existing modules. After a few years the application becomes so big that updating the technology of the entire application is expensive and risky. At this point the application has turned into a legacy application.

The bigger problem is- this is not a one-tie thing that can be easily overlooked. For businesses managing multiple applications, this is pretty much the lifecycle of every application. Things come to a dead-end/ standstill when an application becomes a legacy application.

What’s missing?

I am not saying that adding new modules is less important than updating the existing ones. I am pro innovation but all cogs need to move together to create a well-oiled wheel. While the focus should be on growth, analyzing newer technologies and updating modules should also be paid attention to.

How to ensure that innovation and technology updation move together

Each firm would have to analyze their application development process and figure at what point they start ignoring existing applications. Then processes need to be added to avoid that. I can explain how we at e.Soft technologies do it and ensure that our clients don’t bear the burden of legacy applications.

We utilize the ADTI (Analyze- Develop-Test-Improve) application development framework that ensures applications don’t turn into Legacy applications. The Analyze, Develop and Test phases are where we work together with you to understand your requirements, and craft an application that would meet your business requirements. But we sincerely believe IT should do more – more than just developing good applications. It’s time IT looks at how its contributing to the bottom line and what it needs to do to keep growing the bottom line. IT needs to motivate and push the business to focus to architectural improvements for current/ past projects, even if the team is working on a new project with a new business. And this is the “Improve” phase of our application development framework

Even after the application is successfully deployed, we work with the business (and keep them motivated) to keep improving the deployed application; be it improving UX and userflow, optimizing codebase or updating technology.

We help stakeholders create business cases for how small (but consistent) changes NOW, and prevent large, risky and expensive efforts in the future. Through consistent application improvisation we help businesses cut down on maintenance costs and utilize that budget for innovation.

Results from the “Improvement” Phase

For 4 of our major clients, the “improvement” phase of software development has never stopped since project inception and as a result their average application maintenance spend is about 10% of their IT budget

 

16 / 100