Conversion and modernisation of COBOL legacy applications

According to recent statistics about 75 % of the programs that are used in banks daily have been written in COBOL, a language that is poorly structured and considered as highly obsolete.

In fact there are lots of good reasons to change from COBOL to other languages and modern IT environments.

• Frequently the legacy programs are old fashioned, poorly documented, containing a high proportion of “dead code”, with a lot of tricks to save some bytes; this makes them difficult to understand when considering the structured approaches, that should nowadays prevail. As a consequence the maintenance of these applications is very expensive.
• The programmers who wrote the mainframe programs often have left the company, have retired or are about to retire. At present it is extremely difficult to find developers with a high level of motivation for writing COBOL code; young people leaving universities no longer learn this outdated programming language.
• There exists an ever increasing need for opening the legacy applications to new users, either to collaborators in other departments inside the company, or to customers who are eager to get online information or even to providers when trying to integrate the value chain. So it is important to move applications, that were designed a long time ago when “green screens” were the only available user interface, to the client – server mode and even more frequently to the Internet.
• The company, which uses the mainframe programs, may consider the possibility of making a shift to a greater technology independence, using universally accepted standards in “lighter” IT environments, like Unix, Linux, J2EE (Java) or .Net.
• The programs obviously have to be redesigned because their specifications do not meet the present needs. This may happen in particular when considering the various new regulatory constraints that are becoming mandatory in recent years, in particular in the banking sector (IAS-IFRS, BASEL II).
• There may be urgent reasons to horizontally or vertically integrate various legacy applications, that have been designed in the past as “application islands”, due either to their functionality or to the departments, where they were used in the company. This is a compelling motivation for restructuring the existing programs as flexible and reusable software components, in order to avoid an EAI type approach, which may quickly grow into an inextricable mess when trying to interface several applications. This integration may prove as particularly vital in the case, where the IT departments of two companies have to coexist after an absorption or a merger.
• The board of directors has defined an aggressive strategy and the IT department should ideally be in phase with this strategy, which generally implies an agile software development in a standards based environment in order to cope with the possibility for easy integration and fast change management, both in terms of user requirements and independence from constantly evolving technologies.

All these good reasons for replacing the legacy applications, which are often out-dated, but on the other hand contain information and rules that are still vital for the company, represent a real nightmare for the IT manager. A certain number of replacement solutions have been considered, including the transfer of the COBOL programs to other systems with a more modern technology, the use of “wrappers” that are able to simulate “green screens” over the Internet, the automatic line to line conversion of COBOL to Java or C#. Some managers even consider the possibility of manually rewriting the existing applications with the simultaneous integration of all the new requirements that appear as mandatory. Some of these solutions may be cost effective, but often they do not really solve the underlying problems or generate new kinds of problems, for example applications that are practically not maintainable. Other methods may eliminate the major drawbacks of the legacy applications but for a price which is not acceptable.

At CompoSys we came to the conclusion that there are only two valid methods for coping with the outdated COBOL legacy applications : either the existing applications are kept, but a serious effort has to be made to integrate them into a Service Oriented Architecture (SOA), or some or all of the existing COBOL legacy applications must be rejuvenated and transferred to other more modern languages on standard platforms.

The major interest of the approach chosen by CompoSys resides in the fact, that we are not directly transferring the COBOL instructions to the language and the deployment environment, that has been selected by the customer, but that we are targeting a Model Driven Environment (MDE) as an intermediate step, which makes a great difference. This scheme offers a certain number of vital advantages described hereafter :

• The conversion of the COBOL programs to the Model Driven Environment can be automated to a large extent, through the iterative use of a rule based inference engine; in general about 75 to 85 % of the COBOL instructions are automatically converted, thus reducing both the cost and the risk for errors during this operation.
• The remainder of the COBOL instructions, that were not converted by the inference engine, are then manually introduced into the model ; the completed model can finally be rejuvenated, generally in an automatic way, by separating for instance the client functions from the server side procedures.
• A certain number of other modifications are possible on this well structured intermediate model in order to cope with new requirements, to define Internet interfaces, to extract components or reusable services or possibly to implement a well structured security system.
• 100 % of the code for the final application is then automatically generated from the intermediate model, according to the customer’s requirements : languages of choice are C++, Java and C# in J2EE, Windows, Unix, Linux or .Net environments; it is also possible to generate properly restructured COBOL for the server part on the mainframe.

As this process is automated to about 80 % during the COBOL to MDE phase and to 100 % during the code generation from the MDE, it represents a highly valuable alternative to a manual conversion, with limited risks and at a reasonable price. Furthermore this methodology is able to provide valid answers to all the good reasons for rejuvenating the COBOL legacy applications that have been described at the beginning of this page. Hopefully it will help to solve the problems of an IT manager who complained in these terms : “The COBOL legacy applications are too valuable to replace and too big to rewrite”.