Avoiding Application Modernization Disasters
April 22, 2014 Alex Woodie
|
When it comes to colossal IT screw-ups, there may be no better way to infamy than to bungle an application modernization project involving an IBM mainframe, AS/400, or other legacy host. It may not be the fastest approach, considering the years that are typically involved, but it will successfully leave the customer millions in the hole and feeling utterly helpless about the future. Miten Marfatia, CEO of legacy application modernization specialist EvolveWare, shared his secrets to avoiding the headlines. Marfatia has seen his share of modernizations gone awry as the chief executive at EvolveWare, a Santa Clara, California, company that specializes in COBOL rejuvenation. He watched as the Department of Healthcare Services for a major state waited patiently for a contractor to complete a 1 million-line application modernization project for a critical mainframe application. It was supposed to be done in six months, but after 18 months, the contractor–who Marfatia says decided to manually migrate the code due to the increase in billable hours–had not completed the job. He watched as the US Air Force hired Oracle and Computer Sciences Corp. to migrate hundreds of disparate legacy apps under a new centralized ERP system. In December 2012, five years into the project, the USAF canceled it. The cost to the US taxpayers? A cool $1 billion, according to this story. Marfatia watched as the Internal Revenue Service–sick and tired of trying and failing to get off its legacy mainframe apps–finally broke down and took charge. Instead of putting all its chips on one contractor in a “big bang” approach, the IRS decided to test its contractors with small chunks of the job. According to the IRS’ request for proposal (RFP), which EvolveWare participated in, the IRS wanted each contractor bidding for the job to modernize 4,000 lines of code in six weeks. Why would the IRS do this? “The goal is not to see the results,” Marfatia says, “as much as the process.”
Ah, right, the process. You see, you can have the best code analysis and generation tools and the biggest army of the smartest migration consultants in the world, and it doesn’t mean a damn thing if you don’t get the process right. That is the lesson that the IRS learned, and the lesson that IBM i, System i, iSeries, and AS/400 shops would do right to learn if they’re thinking of upgrading their aging RPG and COBOL apps. Regardless of whether the modernized RPG or COBOL application runs on a Power Systems server or another box, it behooves the IBM i organization to get the process right if they’re thinking of starting a big, invasive modernization project. Process and Balance According to Marfatia, one of the most important aspects in AS/400 or mainframe application modernization projects is to get the proper balance between people and tools. Both are critical to a successful project, but too often, companies get the balance out of whack. Sometimes it’s due to greedy contractors eager for billable hours, and sometimes by impatient companies putting too much faith in the limited power of automated conversion tools. “If someone goes in and pitches a process that’s completely manual, that raises a lot of red flags,” he says. “But at the same time if someone says ‘I’ll go in and do everything automatically,’ that also raises red flags. Because it’s not possible for an automation tool to derive business tools and create an optimized system.” It goes back to process, breaking the migration project into separate chunks, using tools where they can have their greatest impact, and not leaving humans entirely out of the equation. It’s about being common-sense smart and learning the lessons of the failures of big-bang implementations. EvolveWare uses code analysis tools to extract business logic from 16 different sources, including COBOL on IBM i and IBM mainframe systems and a handful of others. The code analysis tool outputs its results in an intermediate format based on XML. These XML documents are re-analyzed before another set of code generation tools are used to generate the final code, often Java, C#, or VB.NET. Tools that attempt to migrate COBOL or RPG directly into Java or .NET will not perform well for several reasons, Marfatia says. For starters, there’s a lot of old stuff embedded in that legacy code. After 30 years, there’s going to be things that simply aren’t needed any more. There’s no point in bringing this over. But more importantly, the dense nature of old RPG and COBOL coding styles simply don’t mesh well with modern code constructs. “When you’re running an RPG or legacy code, you could write multiple executable statements in one line. Now with the modern code, that’s not possible. Guess what happens?” he says. “You have a physical line in RPG with three or four executable statements, and it results in five to eight statements in Java or MS.NET. So one million lines of code is changing in five to eight million lines of code. That’s almost impossible to maintain.” Without humans stepping in to optimize the code, the resulting application will not perform up to expectations. “The processing power of the AS/400 is so large compared to a distributed platform that when you migrate that code “as is” and put it on a distributed platform with Java or .NET, that target code or target application is working like a dog compared to the source,” he says, echoing the comments of many iSeries professionals bemoaning the poor performance of early Java on IBM midrange machines. (IBM has since largely fixed the Java performance trap.) By encapsulating each RPG or COBOL routine into a separate XML document, EvolveWare is able to track all of the individual strands of business logic in a legacy application and figure out how they will best fit together in the new application. Marfatia says EvolveWare is the only code modernization vendor to combine the documentation and code generation components. With its acquisition of the X-Analysis product, Fresche Legacy is also taking that approach now. In any case, EvolveWare is not yet supporting RPG on the IBM i server. Marfatia says he’s considering developing the capability to migrate RPG on IBM i (really the only form of RPG any more), at the request of an insurance company. That insurance company had previously hired an Indian firm that was supposed to migrate its RPG application to Java in 1.5 years. After taking four years and exceeding the budget by a factor of three, the migrated application was not running at an acceptable level. Marfatia’s modernization proposal involved implementing a process with small steps, providing the customer with verifiable goals. “He was very happy with our proposed process,” he says. “Instead of wasting four years on another failed attempt, he said ‘If you guys are going to fail, I’ll know in three months.'”
|
