For the past 20 years, the average software lifespan
has been between six to eight years. I have known some legacy applications to stay in production for decades. This is in sharp contrast to mobile apps, which lose half of their lives in the first six months of use or the DevOps/Agile world, where apps are continuously undergoing change to the point where keeping logs of future enhancement requests is hardly necessary.
This begs the question: Is the IT backload and application maintenance relevant anymore?
Software maintenance, largely comprised of chipping away at application enhancement request backlogs, has historically consumed half of IT application developers’ time. It would follow that dramatically reducing these backlogs would warm most CIOs’ hearts.
Can we make this happen?
The IT Enhancement Request Backlog
The IT applications enhancement request backlog is a list of all the application request enhancements that end users have submitted and that have not yet been addressed by IT. This log does not include fixes that are applied when applications malfunction.
I have seen these enhancement request backlogs literally go back for years to the point where no one (including the original requestor) can even remember the purpose of the enhancement request. In some cases, the original enhancement requestor isn’t even with the company anymore.
Nevertheless, most enterprises have a dedicated team of software maintenance programmers who tackle this enhancement request list each day. They modify and document the app that is being enhanced, notify the enhancement requestor that the enhancement is complete, and place the revised application in production. Then, they move to the next prioritized request on the list.
From an application developer’s standpoint, this task can be a tedious and thankless job, because you don’t get to work on anything new. Some developers might not mind, but there are many more who would prefer to be engaged in new project work.
DevOps/Agile, Low-Code/No-Code, Cloud Impact
A decade ago, it wasn’t uncommon for a new system deployment to take 1.5 years from start to finish. This timeframe subsequently reduced to six months and now can be as small as six weeks.
What’s changed?
Companies and vendors began to move away from time-consuming, custom-developed, in-house applications. As a result, more code remained standardized, and there was corporate pressure to live within the confines of standardized code.
End users began to expect applications and systems with very quick turnaround. This speed of application delivery was spearheaded by the move to more mobile and Web-based applications. At the same time, user tolerance and expectations for high-quality code diminished in favor of the ability to deploy code faster, even if it meant that code was not entirely perfect. The rationale was that you could always quickly jump in and change something if you don’t like it.
Traditional waterfall development methodology with its emphasis on sequential define-develop-test-deploy-maintain application development began to fall out of favor because it took too long. In its place DevOps/Agile methodology with its rapid application turnarounds took root and was soon joined by a plethora of no- and low-code application development tools, often used by end users who developed and maintained their own applications.
The Next Best Thing for the IT Backlog
In 2022, it’s unlikely that CIOs will pencil in a review of the IT backlog as a strategic priority, but now is the time it should be getting attention.
If the enterprise’s attitude, philosophy, and methodology for developing software have changed, software maintenance should also be revisited.
Here are several steps that IT organizations should consider:1. Review the application enhancement request backlog
It is possible that 30% to 40% of this backlog might not even be relevant anymore. These requests should be reviewed with requestors and if all agree, the requests should be eliminated.
2. Move legacy applications to the cloud
Legacy system vendors are moving their applications to the cloud, whether their systems are SCM, ERP, CRM, or something else. This move by vendors, steadily increasing over the past half dozen years, is in response to more companies moving to the cloud and wanting cloud-hosted applications.
Vendors also want to get away from calls from clients that have highly customized systems. Instead, vendors take in enhancements from clients and then prioritize the requests for future software releases. In this way, vendors can better control their software enhancement streams and ensure that they are addressing the primary concerns of their client bases.
For a company invested in a highly customized legacy system, the tradeoff is that you lose many of the customized enhancements that may give the company a competitive edge, and in some cases the tradeoff won’t be worth the switch. But for companies that value reducing their software maintenance and that don’t see an enormous competitive advantage in maintain an internal code base the switch may be worth it.
3. Reevaluate your staff deployment
If your software maintenance log decreases by 30% to 40%, do you really need that many staff employed in maintenance anymore? Likely not, so these staff members become available for new project work.
That being said, there is likely an upfront investment that needs to be made. These staff may need to be upskilled to work in new software development environments.
What to Read Next:
Ancestry’s DevOps Strategy to Control Its CI/CD Pipeline
Why DevOps Will Have To Change This Year
AIOps, DevSecOps, and Beyond: Exploring New Facets of DevOps
Source link
