Introduction
Coined a few years ago to help measure a specific industry trend, the phrase ’IT Debt‘ is now a de-facto term in the IT world. A quick Google search shows, however, that it is not well defined, and the phrase is often misused, misunderstood and applied generically instead of on a case-specific basis. This blog attempts to unpick the truth from the fable by defining IT Debt, and exploring its causes and the wider industry impact of such a phenomenon.
IT what?
‘IT Debt’ is well-established term promoted by Gartner in 2010 to apply a quantifiable measurement to the backlog of incomplete or yet-to-be-started IT change projects. The accompanying research reported a rise in the amount of unfinished IT activities, at a global, macro perspective. When they wrote their press release, Gartner had the “enterprise or public sector organization” front of mind as most likely to suffer from IT Debt, and were particularly focused on the backlog of application maintenance activities.
Let’s define those terms again here.
- IT Backlog – outstanding work IT has to undertake in order to fulfil existing requirements
- IT Debt – a quantifiable measurement of IT Backlog
IT Debt later started being used interchangeably with similarly debt-focused phrases, such as Technical Debt, IT backlog or – to borrow a phrase from Agile methodology – the stuff in the icebox. Looking objectively at the issue, it will be helpful to think of the IT Backlog as the focus of discussion – “IT Debt” is merely a way of measuring it.
How Did It Get Like This?
The concept of a lengthy ‘to do list’ is by no means a difficult one and is certainly not new in of itself. IT or Data Processing departments would have long maintained a list of work items, prioritized accordingly, and would be working through this list, in the same way any functional area of any organization might. The monetary value adds arguably greater clarity (and potentially therefore concern).
Of course this being an IT term, causative factors can be many and varied. There are a number of elements that can and will contribute to an organization’s IT Backlog in differing measures. It isn’t fuelled by a single element. It is not platform or technology specific. It builds up, application by application. The defining characteristic of a backlog is that it’s the cumulative effect of a number of contributory factors that have accrued over time.
The root causes for the IT Backlog not only unearthed by research but suggested by customers, partners and commentators are wide and varied. They include:
- Historical IT investments The IT world is highly complex; supporting this complexity is an onerous task and previous IT investment decisions may have been a good idea at the time but are now a high ongoing burden to keep running – there’s more on this here. Gartner echoed this major ‘budget’ concern in their original research too.
- Current IT prioritization With 70% of all IT spend typically going on keeping the lights on, further impetus on clearing the backlog isn’t perceived as being a revenue-generating activity, so it may go under the radar in favour of more customer or revenue-centric initiatives. A strategy that sensibly and appropriately invests in what is a housekeeping exercise is not easy to justify.
- Human Resources The lack of appropriate skills is another potential issue, because identifying the solution is one thing but getting ‘your people’ to resolve it can be quite another. Building a solution to a requirement the basis of which requires very specific know-how might just be seen as too difficult or costly to resource.
- Unplanned Backlog Pre-ordained, planned work on the backlog is one thing, but IT priority is seldom isolated from the business in this way. Organizations are at the mercy of shareholders, corporate events, regulatory bodies and even the judiciary. Compliance projects and M&A activities typically find their way to the top of the list unannounced, pushing other backlog activities further down the list.
- New Technology / Innovation Many CIOs and IT Managers will point to the external pressures – such as the disruptive technologies companies must work with to maintain market share – that are causing them to delay other tasks.
- Processes and Tooling Incumbent technology and tools are not necessarily set up to deal with a lengthy application maintenance shortfall. The efficiency or otherwise of the execution of IT changes will have a bearing on how much backlog can be reduced and when.
- Improvement Process With no rigor for monitoring and controlling the application portfolio, it is often harder to plan and prioritize application backlog activities systemically. Gartner suggested this in 2010, and more recent research suggests that only half of organizations have an appropriate process for managing the portfolio this way.
- Vendor Relationships Filtering the must-do from the nice-to-have and ensuring the right technical and 3rd party strategy is in place is an important IT task. Not adding to the longer-term backlog as a result of procurement decisions remains an important and ongoing challenge for the organization’s senior architects and decision makers.
This list is by no means exhaustive. In the whitepaper Modern Approaches to Rapid Application Modernization, IDC argue other potential culprits could include high maintenance costs, “rigid systems that remain resistant to change”, “lack of interoperability” and ”outdated user interface technology”. Of course, the chances are that no two organizations will have the same blend of factors. In truth, it’s going to be an unhelpful cocktail of any number of these issues.
Wherever it resides it’s not a Mainframe Problem
If IT Backlogs exist, they obviously live somewhere. They pertain to or manifest themselves in certain corporate servers. Yet in the IDC report (see above), there is no mention of platform as a salient factor in shaping IT Backlog. No link at all.
The IT Backlog is simply the confluence of any number of factors – tools, process, people, politics, available cash, desire to change, strategy – that will contribute, in greater or lesser concentrations, to create an application maintenance shortfall of work. It doesn’t follow that mainframe owners, or those running ‘legacy’ applications, are grappling with IT Backlog more than anyone else. Indeed, frequently the opposite is true.
An IBM report, noted a positive ‘cost of ownership’ for their System z against distributed servers. It noted that consolidating servers increased IT staff productivity and reduced operational costs – keeping the lights on – by around 57%, further proof that neither the mainframe, nor alternative, mass-distribution systems are the culprit. Other research also highlighted other causes of IT Backlog, choosing to look beyond platforms and ‘legacy’ applications.
From our own research through Vanson Bourne, we surveyed the views of nearly 600 CIOs , which was captured in the whitepaper, The State of Enterprise IT: re-examining Attitudes to Core IT Systems, IT Debt results by company size revealed an interesting perspective. While average estimates for IT Debt grow with company size, this trend only applies to the entire portfolio. Taking the mainframe portion alone, the largest companies actually witnessed a drop, making its percentage contribution towards the IT Debt much lower than the smaller companies.
Clear evidence shows us that IT Backlog is not mainframe-specific. Indeed, it should not be pinned to any given platform at all. Correlating any link between the choice of platform and the consequent presence of IT Debt is misleading.
Paying Your Way
The term IT Debt was introduced to provide some clarity and impetus to what was observed as a growing industry concern. Reactions to this were varied as the debate ensued, though most agreed it was an issue that would require attention.
In our view, the headlong rush to rip and replace perfectly good business applications (many of them COBOL based) and replace them with new code that may – or may not – do exactly the same job doesn’t seem wise. Swapping one problem for another is like clearing an overdraft with a loan you can’t pay back – with terrible consequences for your finances.
Taking a more balanced view of tackling the factors contributing the backlog avoids unnecessary risk in a long term strategy for operational improvement. And help is at hand to tackle many of the root causes.
Arguably the best place to start is with greater focus on the backlog at a systemic level. Isolating and planning backlog busting projects is facilitated by new incarnations of application knowledge technology, and smarter tools for making application changes.
Getting the work done needs the right resources. Lots of people are learning COBOL and many of the companies supposedly struggling with ‘legacy’ systems are at the forefront of the digital economy.
Longer term, training new generations of Enterprise techies is important. Efforts from Micro Focus and IBM’s master the mainframe initiative suggest that the problem is being met by some smart thinking all round, while the recent celebrations around the mainframe’s 50th birthday have added further impetus to a broader appreciation of the value of that platform.
You’re All Set
The phrase ‘IT Debt’ is surrounded by ambiguity, which hasn’t helped the industry understand the problem well. Conjecture over the relevance of underlying platform hasn’t helped either. Backlogs are caused by multifarious issues, and it is important to examine those causes within your organization, rather than reacting to the headline of IT Debt.
Today, establishing a successful mitigation strategy that tackles root causes is a genuine possibility. The backlog burden need not be out of control. Embracing change by seeking to enhance existing, valuable IT assets using smarter processes and technology, enables backlog to be managed effectively, and without introducing risky, unnecessarily draconian change.
