Not just a nip and tuck, application modernization extends the lifecycle of legacy code assets

Read a transcript of the podcast.
When enterprises reach back in time, to the outer reaches of their code assets, they don't necessarily have to see things as they once were. Due to application modernization techniques and methods, scattered legacy applications can be rationalized for lifecycle-level support by newer, more efficient platforms and practices.  
The proper hygiene of these applications becomes especially useful and cost-efficient as enterprises and governments move toward datacenter consolidation and also services oriented architecture (SOA). To explore the nuances of application modernization, and to determine the business case for such undertakings, I recently moderated a sponsored discussion with two executives from Hewlett-Packard (HP).
Rick Slade, the America’s practice principal for HP’s Application Modernization Service, and Paul Evans, the worldwide practice leader for application modernization for HP Services, explain how the targets for modernization efforts extend well beyond mainframe and COBOL code. The goal is to deeply examine any older applications -- built on linear, monolithic architectures -- and transform them for production on platforms and server architectures that promote long-term flexibility.
Here are some excerpts from Evans, Gardner, and Slade:

The more of these processes that [the business managers] agree are no longer required, the less money is spent on modernizing and maintenance, and the more that can be spent on real innovation. And that is where we have seen some really significant strides forward ... . That comes from the rationalization of the application portfolio and by retiring applications in a well-managed and graceful way. You are not walking in on a Friday night and turning it off. This is communicating to people that, as of a certain day, an application is going to be shut down, and that you’ll be using a new application that is probably centralized and that works across a group of organizations rather than in a siloed one.
It takes IT organizations too long to respond to business-change requirements today. We, as IT professionals, have to determine how we can be more responsive back to the business. Quite often the only way to do that is to change the software architecture -- to use more modern architectures that allow us to make changes fast.
I think that is what this is all about. So cost certainly is an issue. I certainly believe that we can reduce the cost every time. I think that’s been proven out time over time. But I think the big issue that is causing organizations to look at this today is their inability to respond as fast as a business would like. It’s been an age-old problem between the business users and the IT departments -- businesses always complain that IT can’t respond quickly enough. And the problem is, typically, because of the time required to do impact-analysis and impact-testing on these very monolithic, linear software applications. If we can reduce that time-of-maintenance, we can improve their time-to-market as an IT organization.
 
... The first thing we may have to do is to perform an inventory of what are the critical applications a customer has, and how they constructed them. We perform an applications rationalization. And what we are looking at here is the intersect of the criticality of an application to the business, versus its technical quality.
What we are looking for is applications that are critical to the business, but that their technical quality is below par, below standard, holding the company back. A typical example would be a mainframe-based application running in COBOL, monolithic in nature, very difficult to make significant changes to, where the documentation may have been lost or may have been never been produced, in which maybe the original architect no longer works for the company. And therefore it becomes quite a challenge if you are going to make significant adds, moves, and changes to those applications.
It’s amazing what we have found ... that applications have been identified as being redundant and not supporting the current business processes. It's amazing. As soon as you claim that an application is redundant, then overnight it becomes strategically important. But you’ve got to get through that. You’ve got to understand the business processes that you are really looking for. And, of course, the challenges here are with the older applications, those business processes that are embedded in COBOL.
They are not exposed. They are business processes that are just mired away in millions of lines of code. And in the market today there are tools that can bring to the surface these business process. So you can say to a business unit manager, "Do you need this, really? Do you want us to spend 500,000 pounds, dollars, Euros, or whatever, per year in keeping this alive? Is it necessary for your business?"

Listen to the podcast, or read the full transcript for more information on application modernization. Sponsor: Hewlett-Packard.