<< Gradual COBOL to Java migration: one piece at a time | Home | Feedback Area for: 16 Translator features Essential for successful COBOL to Java projects >>


COBOL to Java/C# - Comparison of Approaches

Pros and Cons of Business Rule Exctraction, Modelling tools, Auto-translations

There are many advantages in moving old COBOL applications to Java. The purist development teams will always argue the best technical solution would be to rewrite the application. But at what cost is that path justifiable? Are such project successful? What is the path which offers the most predictable outcome (cost, risk, maintainability of the target). Does size of the application matter (Smaller applications more suited to one approach, larger ones more suited to other approaches).
We come across organisations which follow all different paths. Here is what I've learned.

Automatic Translation
First lets qualify: We are not talking about a tools which COBOL code line by line, and write it (line by line) as java. But I am talking about tools which can generate code with sufficient quality to be maintained by developers. This would allow clients development teams to focus on testing – and to ensure the new system can be moved into production quickly. Any re-architecture work is only done after completion of testing phase - and only then the development team may look to further enhancements.
In this approach the project costs/risks are easiest to manage and predict. And thus the approach is applicable to medium and large projects as well as the smaller ones.
However, in order to be successful – the generated code needs to be legible and maintainable by any new developers – without their retraining in legacy systems. (You shouldn't need to send the Java developers to CICS or COBOL course).

Business-Rules – Extract Functional Specification – for manual rewrite code.
This is the ideal choice of Java (or C#) development teams. It leads to brand new application which uses all the latest technologies, and is devoid of any legacy architecture or legacy dependencies. Once again this is an admirable goal but there area many pitfalls to watch out for. First issue is the Business extraction toolset, and how to ensure if all the rules have been captured, or whether rules have been captured "correctly" (no important information missing from a rule). Then there is the question of project itself – rewrite of smaller applications may be viable. But medium / large software projects have a tendency to go over time and budget.

Use of a tool to model the code – and then generating code manually/semi-automatically.
In this case the tool parses code and generate a model of the original code. The model is often in form of a proprietary modelling language – and not UML. This is because UML is not suited for representation of COBOL code where data-structure utilise sub-grouping, REDEFINITIONS, and code uses GO-TO, ability to use implicit flow-logic control, and etc. None-the-less, idea is to allow the Java/C# developers to play with the model, generate code from the useful parts, and rewrite the rest.
Again this approach would be desirable to the development teams as it provides them with certain level of control over the target project. The question which rises is: how is this approach different from a Business-Rule extraction/manual rewrite described above? For a Medium to large project – is it realistic for developers to analyse the mode, and manually write the code required to tie system together? Is the semi-automated generated code maintainable? What are the project timescale and costs?

Business-Rules to migration to a Rule-based system:
"Rete" based rule system are inherently difficult to implement. The automatic extraction of rules and re-organisation into rete rules is near impossible. This is because in a typical system, in order to achieve reduce code duplication and increase performance – the rules are defined with dependency on sequence of execution, and within context of other rules (e.g. multi-level IF-CONDITION). Hence, whilst the end goal is extremely attractive, the approach is only suited to the simple applications.

Re: Options for moving from COBOL to Java/C#

All the above system have there own if and but's . I am not saying that it can not be done. What i mean here, still rewrite has a long way to go.

Add a comment Send a TrackBack