Application renewal has become an increasingly attractive option to many corporate CIOs.

Application renewal is IT’s ugly ducking. After all, it’s counterintuitive to the mindset of an industry that has long been replete with new products and upgrades.

Yet, application renewal has become an increasingly attractive option to many corporate CIOs. Forrester Research, for example, reports that the volume of client interest in vendors that offer wholesale improvements to legacy applications has increased an estimated 25 percent.

Application renewal has grown dramatically in direct response to the need of CIOs to attack their problem areas. They want to know “How do I do more with what I have? What do I do with my application base?”

We’re not saying that old is good and new is bad. Rather, application renewal is about taking an application, harvesting its value and extending its useful life. Companies end up seeking application renewal for three primary reasons:

•  They have a cost problem where they need to take the cost out of their IT infrastructure.
•  They have a risk problem where something has gone “end of life,” or they are losing people who understood it. 
  
• They have an agility problem where they have an application that needs to do more but can’t – and replacing it won’t work because it’s either too expensive or there is no other option.

There is a time and a situation when a mainframe may no longer fit a company’s needs. But, there needs to be business drivers for making that decision. Companies can solve that dilemma by taking a fact-based approach. When it comes down to it, they really need to let the code do the talking.

According to a recent Gartner Report, in 2006, 7 billion lines of COBOL code were written – a large number for a language that is supposedly dead.

Take the CIO of one large Midwest company who was convinced he needed to shut down his mainframe because of cost and age. He was asked if he had any financial info about their application portfolio, so consultants could take a closer look. They wrote down the names of the billing systems and the percentage of revenue they drove. They also wrote down how many encryptions they had supporting each of these, the payroll cost, the non-payroll costs (e.g. maintenance, licensing). Looking at the whole picture, it soon became clear that the mainframe was the best thing he had going. It was driving 65 percent of his revenue. Comparatively, it was very inexpensive to operate.

As a result, organizations need to look at their legacy application in terms of the following aspects:

•  Functional health – Is it doing what it’s supposed to do?
•  Technical health – Is it a healthy platform?
•  Financial health – What is it costing?

Addressing Different Scenarios
Application renewal should begin to cross a CIO’s mind when exposed to any of the following scenarios:

•  The deadline for conformance to the latest regulatory changes within the industry is rapidly approaching. Have appropriate plans been made to change your legacy applications?
•  Costs for maintaining existing hardware, software or database platforms have escalated. What will be the impact on your organization once these costs become unsustainable?
•  The platform used is nearing the end of its life, and the chief technician who operates the rest of your legacy systems is preparing to retire. Is there a contingency in place to cope with changes in available technology and skills?
•  Application maintenance continues to absorb more and more resources. Have you underestimated the level of required testing needed to maintain efficient operations?

Application renewal methodology typically supports a two-part process. This begins with an analysis of the application portfolio. The “renew” phase follows, which may take the project through any of these likely approaches:

•  Replatforming – Place the existing application on a new platform. Accenture uses a proprietary set of tools that may migrate, for example, a billing system running on a mainframe to a Windows environment.
•  Remediating – Resolve issues with the application code itself without changing functionality.  This may mean removing dead code or restructuring it to become SOA-compatible.
•  Consolidating – Combine applications and/or platforms that are performing similar or repetitive functions.
•  Replacing – Substitute the existing application and platform with a new custom or packaged application.
•  Enhancing – Address the technical or functional health of the application through an extension or enhancement to an existing architecture.  

There may be things that an organization needs to do, say, for compliance reasons that create challenges and offer little value. Yet, it can all become very risky if you break down the mainframe application that does your core business processing without looking at all the facts.

You have to remember that the reason many of these legacy applications have been around for 30 years is because they work, and, in many cases, the fundamental core of what they do hasn’t changed.