The IT Backlog in the Age of DevOps

Over the past twenty years, the average age of the program has been between six to eight years. I’ve known some old apps to stay in production for decades. This is in sharp contrast to mobile apps, which lost half their lives in the first six months of use or the DevOps/Agile world, where apps are constantly changing to the point where it is difficult to keep records of future improvement requests.

This begs the question: Are IT backloading and application maintenance relevant anymore?

Software maintenance, which largely consists of reducing the backlog of applications improvement requests, consumed half the time of IT application developers. It follows that drastically reducing this backlog would warm the hearts of most CIOs.

Can we make this happen?

Backlog of IT improvement requests

The IT application improvement request backlog is a list of all application improvement requests submitted by end users that have not been processed by the IT department. This log does not include fixes that are applied when applications crash.

I’ve seen that improvement requests backlog literally for years to the point where no one (including the original applicant) can remember the purpose of the improvement request. In some cases, the original improvement seeker is not with the company anymore.

However, most companies have a dedicated team of software maintenance programmers who deal with this list of improvement requests every day. They modify and document the application being improved, notify the improvement requester that the improvement has been completed, and put the revised application into production. Then they move to the next priority order in the list.

From the point of view of the application developer, this task can be quite daunting and honest, because you cannot work on anything new. Some developers may not mind, but there are many who would rather be involved in the work of a new project.

DevOps / Agile, Low-Code / No-Code, Cloud Impact

A decade ago, it was not uncommon for a new system to take 1.5 years to deploy from start to finish. This time frame was later reduced to six months and can now be as low as six weeks.

What has changed?

Companies and suppliers are starting to move away from time-consuming, custom-developed in-house applications. As a result, more code remained standardized, and there was pressure from the company to live within the limits of the standard code.

End users are beginning to expect applications and systems with a very fast turnaround. This speed in application delivery has been driven by the move to more mobile and web-based applications. At the same time, user tolerance and expectations for high-quality code have waned in favor of the ability to deploy code faster, even if it meant that the code wasn’t quite perfect. The rationale was that you can always jump in and change something if you don’t like it.

The traditional waterfall development methodology with its focus on sequential application development-development-test-deployment-maintenance- is starting to fall behind because it took so long. In its place, the DevOps/Agile methodology took root with its rapid application transformations and was soon joined by a plethora of low-code application development tools, often used by end users who developed and maintain their own applications.

The next best thing for an IT buildup

In 2022, CEOs are unlikely to review the IT backlog as a strategic priority, but now is the time to get attention.

If an organization’s attitude, philosophy, and methodology for software development changes, software maintenance must also be reconsidered.

Here are several steps that IT organizations should consider:

1. See the backlog of application improvement requests

It is possible that 30% to 40% of this accumulation may not be relevant anymore. These requests should be reviewed with the applicants, and if everyone agrees, the applications should be cancelled.

2. Move old apps to the cloud

Legacy vendors move their applications to the cloud, whether their systems are SCM, ERP, CRM, or something else. The move by vendors, which has grown exponentially over the past 16 years, comes in response to more companies moving to the cloud and a desire for cloud-hosted applications.

Sellers also want to stay away from calls from customers who have highly customized systems. Instead, vendors get improvements from customers and then prioritize requests for future software releases. This way, vendors can better control their software improvement flows and ensure that they address the core concerns of their customer bases.

For a company investing in an old, highly customized system, the trade-off is that you lose many custom improvements that might give the company a competitive advantage, and in some cases the trade-off won’t be worth the switch. But for companies that value reduced maintenance of their software and don’t see a huge competitive advantage in maintaining their in-house code base, the switch might be worth it.

3. Reassess staff deployment

If your software maintenance history is down 30%-40%, do you really need that many maintenance staff anymore? It probably won’t be the case, so these employees become available to work on a new project.

However, there will likely be an upfront investment to be made. These employees may need to be skilled to work in new software development environments.

What to read next:

Ancestry’s DevOps strategy to control its CI/CD pipeline

Why DevOps should change this year

AIOps, DevSecOps and Beyond: Exploring New Aspects of DevOps


Leave a Comment