Outsystems blog

Huge IT Backlog?4 Strategies That Don't Work

Michel Ozzello - April 29, 2013 - 4 min read

Earlier this year we posted an article about IT 'failures' and discussed why inefficiency in most IT departments was really due to the cost of changing and maintaining existing applications. This cost results in ever-increasing IT backlogs and an increase in technical debt.

In this post, let's take a closer look at the current approaches most IT departments are using to solve their backlogs and why those approaches correlate directly with IT's inability to respond to business requests.

At first glance it stands out that the way companies currently deal with their backlogs and technical debt is just not working. Too many IT departments are challenged with unsustainable business models that render them ineffective, or in some cases, irrelevant. They are in danger of being relegated to little more than cost centers. And in that state, they are unable to support companies hoping to differentiate through innovative tech.

This is unfortunate because most IT departments are probably doing the best they can. The problem is simply that current techniques and tools used for delivering and maintaining enterprise systems are hard to use, and the applications these tools deliver are hard to maintain. This context creates an expensive and unmaintainable problem.

Today, when a business unit needs a new application, or a new piece of functionality in an existing application, your typical IT department responds in one of four ways. At best these approaches kick the can down the road. At worst, they add to the problem by creating an architecture and technical environment that will be unresponsive and unable to adapt to changing business needs.

Let's look at current approaches to software change:

1. Buy and Customize a Packaged Application

Consequence: When an organization chooses to buy a packaged application such as SAP or other ERP, payroll or CRM solutions, they are buying into pre-defined functionality that delivers best of breed standard processes for the industry/market it serves.

More often than not, organizations find that their processes are somewhat different from what the package offers, and therefore must customize the package. The problem is that packages have not been built for change and customizing packaged applications is hard, expensive, can require hundreds or thousands of consulting hours, and will create a maintenance nightmare that possibly hinders future package upgrades.

2. Build a Custom Solution Using In-House Developers or System Integrators

Consequence:The problem with this approach is that building a large system using the current state of techniques and tools is complex and expensive. In many situations, the organizations then fall hostage to the system integrators who built the application, because they are the only ones that know how to maintain it. In any case, enterprise applications are never "built for change".

The urgency and focus on getting an application deployed, using current techniques, produces a solution that is not easy to change, and is often prone to break when you do. This just ends up being a big add-on to existing technical debt.

3. Select and 'Rent' a Cloud-Based Solution

Consequence: With the advent of software-as-a-service (SaaS), companies are resorting more and more to 'renting' cloud-based applications to satisfy business requirements. By the very nature of the model, SaaS applications offer small degrees of parameterization, and with the exception of a couple of very large vendors, no customization options.

To a degree, this is a blessing in that IT tends to use SaaS "as-is" and therefore limits maintenance requirements. It does not, however, address the requirement for custom functionality - namely interfaces, workflows and data repositories that are unique to nearly every organization.

4. Do Nothing

Consequence: When budget, time, or resources are not available to buy or build the needed application, IT often just says "No" to the business. When the IT department chooses to do nothing, it causes its relevance to decrease even further and results in the creation of...

Shadow IT

When the pressure to come up with a solution for the business is intense, and IT can't deliver what is needed, business teams often decide to take matters into their own hands. This is commonly known as "shadow IT" - applications built, installed or rented outside of IT's control. Typical approaches include using departmental 'wiz kids' or finding hired guns to solve the problem. They may use platforms such as force.com or SharePoint to develop and deliver an application to solve the business problem. Or they may use portal, workflow or collaboration tools - or even deliver completely bespoke applications, built using any number of tools or languages.

With cloud-based offerings delivered as a 'service', the business does not necessarily need to involve IT at all - there is nothing to install, nothing to back-up, no disaster recovery considerations, data conversion can be outsourced - business can solve the problem without IT even knowing the application exists.

However, as these applications are adopted and begin to grow, the complexity of changing them and/or the inherent value of the data being maintained by them, forces the business to turn control of the applications over to IT.

Looking at these approaches dealing with backlogs, one can see that none of them are particularly desirable and they are replete with cost issues, control issues, and scalability issues. Yet, despite their futility, time and again, organizations continue to walk down the same trodden paths expecting to arrive somewhere different - or maybe they feel like there is no other path to take?

The fact is there's always a new trail to blaze. In an ideal world, you would not have to worry about the cost of change. You would simply focus on delivering the application your business needs, and know that it would only slightly increase your maintenance costs. In order to do that, you'd need to use technology and an approach that could ensure a flat cost of change across the entire lifecycle of your applications.

In a future post, we'll examine how these same approaches, when thought of differently, can be made to improve IT productivity and the ability to support business innovation. In the meanwhile, for those interested in reading more about what holds IT back from innovation, download our featured white paper on the struggles of IT to innovate.

Michel Ozzello

Although he's been working in Marketing for the past decade or so, Michel is still a geeky Software Engineer at heart. He tries to fit technology in every bit of marketing activity he does - from SEO to websites and digital advertising.