Dealing with IT Debt – The Lights are on (Part 2)

0

Introduction

My recent blog discussed the topic of “keeping the lights on”[1] in IT terms. Important day-to-day activities including routine maintenance, system enhancements and important compliance and governance activities amounted to a significant operational workload.  The discussion elicited a number of questions on the topic, from a variety of sources. In this blog, I want to tackle those questions here.

Lights On – is it getting any easier?

Alas, no. Typically, Lights On activities are reviewed, managed and prioritized using the concept of a “Backlog”, an IT to-do list. The backlog is an indication of the volume of outstanding must-do requirements. More interestingly, a measurement of the cost of implementing the backlog throws into sharp relief the extent of the issue. Gartner estimates that within the next 12-18 months, the global IT backlog, in dollars terms, will have grown from $500M (in 2010) to reach $1 Trillion. This is what the industry calls IT Debt[2].

Why are things getting worse?

The growing burden of IT may be for a variety of reasons, which will vary on the industry, organization and existing IT estate.

We don’t know where to start – IT estates are often vast, but application experts are often too busy to provide their perspective. However, system documentation and knowledge is usually woefully insufficient to help less experienced staff get “up to speed”. A study by Vanson Bourne[3] revealed that nearly half of all organizations had no process for assessing or measuring IT Debt, despite technology existing to cater for this[4].

IT gets more complex every year – IT estates of anything but the smallest organization are complex beasts, typically with insufficient understanding of all the relationships and interdependencies. Knowing which systems to change, and how, and in what order, is anything but straightforward.

We have more updates to do – the systems of 2013 are supporting more users, through more channels, for more hours of the day, with more variety, than ever before. All of this needs supporting in the back end.

We have more compliance to do – The notion of the “large scale compliance project” took hold for the Y2K and the Euro, then towards Sarbanes-Oxley, HIPAA, Solvency II and Basel II/III but has accelerated more recently in the wake of the economic crisis. Regulations and legislation on data privacy, banking standards, customer information and international taxation have added to the workload. We’ll look at Compliance in more detail in upcoming blogs.

We don’t have the (right) tools – many core systems are mainframe COBOL-based, which use mainframe technology for analysis, development, testing and deployment. Some of these tools have struggled to keep up with technological advances and provide only limited scope to improve efficiency. As years pass, the ability for the tools to support and keep up with the pace of change and new requirements has become steadily worse.

Tackling these concerns would be central to any solution to the IT Debt challenge.

Why not just rip it up and buy one that works already?

On a recent Micro Focus webinar on the topic of IT Modernization, an attendee asked “why not just remove the difficult systems and replace with a package?” It is certainly tempting, faced with an overwhelming backlog, to consider “starting over”.  However there are a number of extremely important considerations affecting core systems strategy:

As significant as the “lights on” burden may be, the core systems being maintained continue, in the vast majority of cases, to provide unique capability for the organization. Often, this capability is part of its competitive edge. Replacing such systems with an off-the-shelf solution runs a major risk of losing any competitive advantage.

Additionally, while a “package” may seem at face value to be a simple, low-risk undertaking, the implementation of a package that works for the client’s own unique requirements is far from simple – Standish Group’s Chaos Report[5] mentions a 40% rate of failure where new packages were delivered late, over-budget or missing key functionality.

A Micro Focus client undertook their own study looking at the relative merits of package replacement compared with continued evolution (modernization) – according to the four major decision criteria of cost, risk, time to market and competitive advantage, package replacements were considered inferior to the application modernization approach, which they chose.

Why not keep the function, but rewrite it in a new language?

Where organizations have expanded their IT footprint and now possess a wider range of technical and language skills, it is tempting to consider writing from scratch the core systems in a different language. Such an approach may appear appropriate in terms of skills and technical strategy, but again caveats would need to apply.

First, in rewrite projects, it is extremely difficult to “phase in” replacement functionality until the entire system is ready. This means waiting until the project is finally completed and delivered before retiring the incumbent system. Often, this is a long wait.

The risk of failure for such projects, according to the same Standish Report, runs at over 70%. The figure is high because the complexity and effort of such projects is seldom fully understood at the outset.

Furthermore, it is worth pointing out that the full cost of such a project is not at the point of delivery, it is the life-cycle of that system. An illuminating report by CAST Software discovered that systems written in COBOL are up to 4 times cheaper to maintain than an equivalent system written in Java. Determining an ROI for a rewrite raises a number of very important questions about the viability of such an approach.

Why not just do what we are doing today – but better?

The problem with existing systems is the amount of new work organizations still need to do. In reality, that is not a problem to do with the existing system at all; it is a problem to do with how busy an organization is – this points at resource or organizational challenges rather than purely technological ones.

In many cases, while not without their challenges, core systems work. They embody and enable the day-to-day running of the business, and continue to provide value and support revenue generation. They are, as the name suggests, core to the success of the organization.

A modernization approach nurtures and evolves those core systems, but does this in a way that is efficient, streamlined and forward-thinking, which helps protect existing value while supporting innovation.

The process of application modernization is shaped by the key challenges facing the client, as this can dictate the start point for the journey. Whether the issue is to do with knowledge of the systems, the ability to execute change, the pace of delivery, challenges with testing, or even the effort of managing production workload, there are ways of improving processes and supporting technology to help reduce the backlog and support new initiatives. Micro Focus has worked with hundreds of clients to help them evolve their core systems by tackling difficult operational challenges while protecting core IT assets.

But COBOL? Really? It’s 2013!

COBOL is often regarded by those who don’t know it well as great in its day but a generation out of date. One measurement of this is how current the language is: COBOL provides equivalent capability and support in the latest industry IDEs as well as supporting the most recent platforms including .NET, JVM, Cloud and Mobile[6]. Moreover, the fact that COBOL is behind many core systems and runs the vast majority of all global business transactions rarely raises an eyebrow. COBOL also has seen something of resurgence in terms of academic training[7], and in September re-joined the top 20 most popular languages as measured by the TIOBE index[8].  The notion that COBOL is out of date is itself an outdated idea.

Modernizing trusted core COBOL systems can help address IT Debt. Micro Focus offers technology to enable organizations to streamline their lights on activities. Is your IT backlog continuing to grow, despite significant investment? Do you face significant barriers to modernization? Perhaps it is time to take a fresh look. www.microfocus.com