Legacy applications: millstone or gold dust?

So what about your legacy code? We've all got it. Should you modernise and consolidate? Most believe that doing so adds powerfully to the business benefits. But if so, how? Steve Craggs, European chairman of the EAI (enterprise application integration) Industry Consortium, says: "It's a bit of a bugger really. It's not a clean thing to do because there are all sorts of implications: like you'd prefer to do it without doing it all at once. "If you do a 'big bang' and it fails you're really stuck. You might think you can switch back, but if you've been running for a few hours how do you put all the transactions and change back into your system? What you'd like is a way to consolidate gradually." There's also the inevitable people management problem. "People with specialist skills will perceive that they are being put out of a job, so you've got to manage that very carefully because you need their help right up to the end when you switch off." And there's the resource it consumes and the fact that you've got to capture and convert your automated business processes from the old environment. "So many companies do not have a clear idea of how their business processes were implemented in a system installed say 20 years ago. You might be surprised how many tell us they don't have the source code or the documentation. And you can say that's very silly, but there's nothing they can do about it." There are ways around that. One is to use software to put a 'wrapper' around the existing code so that it stays more or less as is, but presents in the 'look and feel' of the new environment. "Which is fine but then you've lost some of the potential benefits of consolidating, like reduced licence costs, but you can certainly move your users up to say browser-based interfaces with all the benefits of doing that," says Craggs. Another way to attack the problem is to use software tools that automatically extract business logic and document it for you ready for transfer. But caveat emptor: "If you think you can just run one of those tools and it's all done, you're wrong," says Craggs. "These are mostly learning tools: they don't know what's there until it happens. So they'll catch 80% – the stuff that runs all the time – but they won't catch code that's only invoked under exceptional circumstances." In short, it can take months. So which to do? Steve Ashurst, European sales and marketing director for transformation tools firm SEEC, believes simplification and migration to Java is the way to go, but that it's still horses for courses. For example: "Companies grow by acquisition and they end up with a bunch of ERP systems around the world from different companies, and different variants from the same company. They could consolidate down to one, but it would be dumbed down, so they'd need a layer above with the detailed business rules." But there's only one instance, so you've stripped costs out, and the new layer – achieved by capturing existing business rules and improving where you need to – will be light. So that works. Don't rip and replace On the other hand, Ashurst cites Dutch chemical company DSM: "The company had many system variants, 12 different business units and many geographies." And that meant lots of instances of SAP and JD Edwards (now PeopleSoft). In this case, it made most sense to maintain multiple ERP systems and go for a unified front end using a portal environment. "With this approach, businesses can acquire companies and get them trading in an 'integrated' environment quickly." So that works too. Meanwhile, Mike Gilbert, director of product strategy at IT consolidation specialist Micro Focus, makes the very valid point that consolidation isn't, and shouldn't be, just about wholesale legacy 'rip and replace'. Manufacturers need to think carefully about what they consolidate and why – and specifically to distinguish between the platforms and the applications. Server and platform consolidation, he agrees, is a must, but the software is another matter. "Companies are looking to re-use what they've got – innovate and do more with less." And while he concedes that the trends are towards Linux, less Unix and more Windows and .Net, for him that means the issue should then be 'can I run my legacy Cobol applications on the newer, more powerful, better supported platforms?'. Legacy applications re-use is clearly valuable, but there are other drivers. At one extreme, platforms are simply reaching the end of their useful lives. HP 3000, for example, is being retired; likewise DOS VSE; and there are similar arguments around Unisys, Data General, Bull and others with legacy mainframe platforms. So the issue with these, more than consolidation, is managing the risk of application migration. European lighting fixtures manufacturer iGuzzini Illuminazione was one such running its bespoke ERP system on HP 3000 MPE. It chose to port its legacy Cobol applications to the HP 9000 Unix environment, using Micro Focus Server Express and Revolve to do so. Server Express was the tool that recompiled the existing application to run on HP-UX without requiring changes to the original source code – avoiding obvious cost and risk. Revolve provided the analytical tools to assess the application inventory and how it might be impacted by changes to the code, scheduling or the data itself. It's now up and running on the new platform. This is the fundamental message: while it may seem intuitively right for your consolidation cum modernisation programme to include switching away from legacy Cobol applications to much newer packaged solutions, it's neither always necessary nor safe. As Gilbert says: "Our role is to make it possible to leave the original Cobol business applications intact but move them to the modern value-adding environment." In his view it's perfectly OK to wrap legacy code, and there are two ways to proceed. One is to run it on the legacy platform using technology like IBM's MQ Series to provide a bridge to a modern platform such as WebSphere on Windows. The other is to reduce infrastructure costs further by replacing the legacy platform and moving the application code to Windows for a lower cost yet very efficient solution. He rejects the thinking that says otherwise: "That's the ignorance of business managers who want new business processes, reduced costs but don't understand the data centre." They can get the best of both worlds, he says, citing an example of a company that ported millions of lines of CICS Cobol to Windows and Microsoft .Net, leaving the business foundation unchanged. "Now they can exploit COM, Web Services – create a modern, agile IT infrastructure." He insists that legacy rewrites are hugely risky, and that it's a popular misconception that Java is better than Cobol, noting that even the 'write once, run anywhere' objective of Java was arguably enshrined in Cobol decades earlier. Indeed, he points out that over the years Cobol has evolved as a very efficient business programming language, pointing out that many modern ERP packages are themselves written in Cobol, yet are well equipped in terms of Web Services, integration, .Net functionality and the rest. Cobol: hard currency? He also notes that informed users vote with their cheque books, citing a large multi-national which recently invited 18 system integrators to tender for a substantial transformation from DOS VSE to a Windows environment. "Of those, 17 proposed porting the Cobol system using our compilers, and one bid for a Cobol-to-Java rewrite. The latter was far too expensive and was dismissed out of hand... This is the way to gain competitive advantage without the risk or cost." And he emphasises that once you've migrated your existing application code to the new environment you've got all the flexible access to the Internet and the rest. "In today's economic climate, few CFOs will sign the cheque for a very costly and high risk re-write that adds no business value to the IT function. Cobol can interface to the Internet and WebSphere and Java and .Net: it's a first class citizen on the Internet and .Net. Once you've ported to the new platform you can use the .Net framework and the Windows environment because what you have has become a .Net application." The obvious question – future-proofing: what about Cobol skills? "There are 1.7 million Cobol programmers out there," answers Gilbert. And he believes that the normal rules of market forces will apply, bringing more Cobol players should they be required – proved, he says, by bookings on universities' and colleges' Cobol training courses. He concedes there's a perception of old world and yesterday's computing, but says: "We live in a heterogeneous world of computing so as much as anything Cobol today is about integration." Indeed, he suggests that recruiting Java, C and Visual Basic programmers, and training them in the rites of Cobol is one way to go. "At the end of the day, it's just another syntax."