Ever heard of the term ‘IT Debt’? All those who have been following Gartner, would have an idea what it means. For all those who are not Gartner fans here is what it means. IT Debt is the cost of maintenance backlog of an enterprise. It’s the cost of upgrading enterprise applications to their latest releases and operating versions. In other words, it’s the cost of bridging the gap between the current state of IT architecture and its ideal state.
Now Gartner has estimated this IT Debt at around $500 billion for enterprises at global level. Their research shows that enterprises across the globe have $500 billion worth of updation activities left unfinished or completely ignored over the past decade. And the number is swelling with every passing year!
So why is IT upgrade procrastination an issue? Because the results of such procrastination are more than one – the gravest ones being new market opportunities slipping away, non-compliance with regulatory provisions, and loss of competitive edge. And what’s even more frightening is Gartner’s prediction of the debt doubling up to $1 trillion by 2015.
While we do agree that it’s practically impossible to find an IT enterprise without any maintenance backlog, the deferment has compounded to a near unmanageable level. And it’s still compounding! One of the reasons for such deferment is utter lack of structured review process for application portfolio of an enterprise. So Gartner has suggested application overhaul – a process for reviewing, managing, and rationalizing application portfolio.
So how do we start about with this so-called application overhaul process? A great way to start would be to make peace with the fact that business and IT are two sides of the same coin. Despite being different from each other, they still have to go hand-in-hand. IT cannot turn a blind eye towards business aspects of an application and go on a rampage. Similarly, business should not expect return on all IT expenditure.
We then need to draw out a detailed application portfolio. This portfolio should classify the applications as currently used, newly added, withdrawn, and obsolete. Carrying obsolete applications and processes in your portfolio will only add to the cost without any positive return. Deck them from your portfolio. Next, identify projects and applications that support business requirements and focus more on these. We recommend a strategic level change in planning so that only those projects that hold business value get undertaken. You can further use this portfolio to identify redundant applications or processes. Having different applications perform and duplicate the same process just doesn’t make sense.
The portfolio is also a good tool to map the relevance of different applications. Application overhaul does not mean we reduce the number of applications used by the enterprise. On the contrary, application overhaul insists that we increase the relevance of the applications in our IT architecture.
Another area where we can improve is learn to differentiate between platform and application. Usually it’s the business side of an enterprise that decides which application stays and which gets discarded. Now when they discard an application, they also, at times, discard the platform with it. Just because an application has no more use for the enterprise, it does not mean that the platform too is worthless. It may hold value for other enterprise applications. They do not realize that platform and application are two different things independent of each other. So here, IT needs to step in and decide when to pull down the curtains and on what. This can help us cut down our platform cost.
Now let’s focus on quality management. Typically, enterprises have well defined quality checks and benchmarks in place. These checks and balances come into picture during the testing phase of an application. But is quality only a testing phase prerogative? Absolutely not! We need to focus on building quality throughout the entire application development lifecycle and not just during the testing phase. We can do this by using latest development kits and licensed tools for development. This will lower the maintenance requirements in the long run.
So when we are trying to build quality, let’s not make the mistake of giving up the competitive edge of our applications. We have to be careful that we do not lose out on the competitive differentiation of our applications in our bid to build and enhance their quality. Instead, we have to improve this differentiation and make it a value addition. Also when we talk about application lifecycle we cannot ignore the series of changes that occur over this span. Keeping a hawk eyed watch on application source code alone is not enough. We need better change management procedures in place to reduce our maintenance costs of future.
And finally, we need a major mindset change at enterprise level. We are in the habit of treating applications on need basis or project basis. It’s like 15 seconds of fame. As long as an application is serving a purpose we shower it with all the adulation and attention. But once the purpose is served we just sideline it. That’s not how it works. Applications are meant for life and not for a project alone. We need to see them as an investment for life. The day we start doing this is the day we shall start taking their maintenance costs seriously.
Let’s not make the mistake of thinking that IT debt is an ‘IT’ problem and has got nothing to do with ‘business’. The best way to deal with IT debt is by inspiring a cultural change at an enterprise level. That is precisely why Gartner presents application overhaul as a critical strategy of the decade.