Problem solve Get help with specific problems with your technologies, process and projects.

Web-enable iSeries-based legacy applications

Moving from legacy applications -- an approach

Table of contents

1 INTRODUCTION 3
2 UNDERSTAND YOUR LEGACY APPLICATION 4
2.1 UNDERSTANDING THE LEGACY APPLICATION SHOULD INVOLVE FOLLOWING
ASPECTS: 4
2.1.1 Understand Overall Business Cycle: 4
2.1.2 Selection of the Sample program: 4
2.1.3 Understand the Business Logic of the Sample program 5
3 SELECTION OF TRANSFORMATION PROCESS: 6
3.1 SCREEN SCRAPING TECHNIQUE: 6
3.2 USE MAXIMUM USE OF THE EXISTING BUSINESS LOGIC: 6
3.3 RE-WRITE THE ENTIRE APPLICATION: 7
4 POINTS TO REMEMBER 8
4.1 UNDERSTANDING THE BUSINESS LOGIC 8
4.2 SELECTION OF 'PROCESS OF TRANSFORMATION' 8
4.3 SELECTION OF ARCHITECTURE: 8
4.4 COST BENEFIT ADVANTAGE - 8
5 CONCLUSION: 9

1. Introduction

This paper is written with an aim to assist all those involved in the project of building a Web-based application for a standard legacy application.

Legacy applications are monolithic applications written typically on IBM or VAX mainframe machines or a midrange machines, such as the iSeries, using either standard languages like COBOL or proprietary languages like RPG II/III/IV/400/ILE.

Often the need arises to design a Web-based application out of an existing green-screen legacy application. In this paper effort is made to generalize a process and steps required to be taken in the typical legacy transformation project.

2. Understand your legacy application

The most important point in such a project is fully understand the legacy application that you are planning to transform. Persons with very strong analytical skills are required to achieve the same.

2.1 Understanding the legacy application should involve following aspects:

2.1.1 Understand overall business cycle:
As a part of this step identify how many components are involved in the entire application and try to obtain classification of the same as under:

 Program type      Number 
______________________________________________________________________ 
Screen programs
Report programs
File update programs
Inquiry programs
Control language programs 
Screens
Total number of database/files
Data areas used (if any) 
Data queues used (if any)
Any special feature specific to the hardware in 
Analysis being used 
Message control system used 
Special routines developed (if any): Example - date validations, data computations, cheque printing, alpha to numeric conversion etc.
Machine language routines (API) developed (if any)
Number of closure procedures: Example - day end, weekend, month end, quarter, yearly etc. 

2.1.2 Selection of the sample program:

Selection of sample program is a crucial step in the project.
Typically, after understanding the overall business cycle sample program selected should be such that -

* Which is being used most frequently by the application.
* Which has more number of screens to capture data.
* Which has more file I/O's and in general and is updating more databases.
* Which is trivial as far as the application under consideration is concerned, example: Policy maintenance in case of insurance or account creation in case of banking application.
* Which is relatively complex and has lesser documentation available.
* Which has been changed most over a period of times.

2.1.3 Understand the business logic of the sample program

To understand business logic of the sample program, analyst have to go through the program in detail and should write down the following details:

* Screen wise list of fields.
* Field wise validation conditions and split them as: Either field level validations -- i.e. Less than or greater than some value or database validations -- i.e. Check for valid value or check for duplication.
* Against each field write down: How it is being used, i.e. input, output or both, i.e. input and output.

* Write down to which field in database it is related to? Or if it's a temporary field used for holding temporary data.
* Write down all subprograms being called by the sample program

Prepare a detailed table from the sample program as follows:

Program name: Sample program
Program type: COBOL / RPG etc.
Lines of productive code: xxx (Count procedure division lines / C specs in case of RPG)
Number of files being used:
How many of above files are used as: Input: , Output: , I/O:
Number of screens being used:
Number of sub-programs being called and their types: i.e. CL's, API's etcz Data Areas used:
Data Queues used:

 ___________________________________________________________
 Field Name  Attributes  Where Used  Validation Condition  
   Type Length Dec Screen/DB/ Description 
      Temporary: Include all dependencies.
 ____________________________________________________________

3. Selection of Transformation Process:

Once legacy application is fully understood and Matrix as described in section 2 is drawn. The next step is selection of process for legacy transformation. This process is the most important process in the entire project. Especially in today's world when every day some new technology and hence product based on that technology is getting launched in the market.

There are various methods in which one can proceed for legacy transformation. There is a lot of material already available on the market for each one of these methods. Here is a summary of these methods.

3.1 Screen scraping technique:

This is probably the most famous technique to achieve the required Web enablement in smaller time frame and also at a relatively smaller cost. 'N' numbers of tools are already in the market launched by IBM and even by independent vendor companies in the market. One of them is JACADA, which claims to have been used by many MNCs over the globe.

This technique aims at using the existing programs business logic and just replace green screens by GUI interface, hence it is fast and also the customer is at lesser risk since he is comfortable with the business logic that has not been changed.

This technique is popular when the budget is less and the need for open system is urgent.

Here the only draw back could be, any new modification or enhancement to the existing system has to be well planned.

3.2 Use maximum use of the existing business Logic:

This is another technique, which involves following steps:

1. In addition to step 2 analysis, we need to further analyze the program in following categories:

1.1 Programs involving only screen interaction (I/O).
1.2 Programs, which are purely batch programs i.e., have no interaction with the users. Example: submit job

1.3 Programs, which are complex i.e., involve heavy I/O through the screens and also have complex business logic.

2. After step 1 is complete, often logic applied is following:
2.1 Change all screens to GUI using HTML
2.2 Comment out all screen I/O in the program and use HTML screens being developed instead
2.3 After all the input is being available through HTML, call existing program to carry out remaining functions.
2.4 Programs which are too complex category 1.3 described above, best way to get around these programs is by way of rewriting them using chosen technology Microsoft / Sun-IBM. Which requires decision from the customer.
2.5 Programs, which are purely batch, oriented no need to touch them as it can be called w/o any problems.

3.3 Rewrite the entire application:

This is naturally the most costly but most effective process from long term perspective. This requires the customer to be totally aware of the efforts involved, business logic of the existing system, decision-making ability for selection of architecture. These three factors are important since, often the customer is unaware of the efforts that will be required to analyze their existing legacy application because of various reasons such as: poor documentation, person dependent programming and inadequate skills hence unstructured programming etc.

Also, most of the time existing hardware on which legacy application is being run will play a decisive role in selection of architecture. Also, skills availability with the customer are also a major factor but that is relatively simple since people can be trained on the skills, which are not available with them.

Cost of the new hardware is another factor, which also plays a major role in selection of architecture. Since a customers budget is directly linked to this particular factor.

In this method, after analysis as required in step two are being done extensively and followed by the customer interviews and discussions, often a consultancy firm has to come up with the architecture, which is mostly three tier in nature. Most of the times, the customer prefers to use their existing database as back end or last tier in the new architecture, that way -- he ensures that no data migration is required, which otherwise becomes another small project. And also he is sure that new systems output can be checked using reporting tools on the 'existing known database'

Only catch in using existing database is: the database or its newer version itself should be able to with stand the new architecture requirements.

4. Points to remember

4.1 Understanding the business logic.
This step is extremely important and whatever Matrix we will prepare must be signed off and totally agreed upon by the customer representative. No further action is possible unless this step is being fully accepted by the customer. Because this is the only point at which customers interaction is taken from the consultant, once this report is approved then there will be full fledge development cycle w/I any interruption.

4.2 Selection of 'process of Transformation'
The customer should be involved in this event to make him understand the pro's and con's of the each and every process.
4.3 Selection of architecture:
This is also a complex process, which has two dimensions.
1. Consultancy firms expertise in a particular framework or architecture.
2. Existing hardware available with the customer and general trend with its organization towards use of particular brand of products like IBM or Microsoft.
May times, customers existing hardware finally plays a decisive role in selection of architecture.
4.4 Cost benefit advantage -
Another important factor, which is crucial from the customers management perspective. Since, No business runs for charity, hence cost benefit analysis or return on investment is some thing that a consultancy firm should always keep in mind before suggesting any solution or product. Something might be useful from technology perspective, but if it is costing a ton than that might be crucial factor for decision.

The best solution could be to provide the customer with all the possible alternatives in a tabular form with clear indication of the cost involved to benefits achievable.

5. Conclusion:

Prototype is a must for any such complex project involving so many steps. Hence selection of sample program as stated earlier plays a major role in getting confidence of the customer that 'Yes we can also move from legacy application to a open-system architecture'.

Another important factor is convincing the customer that open-system architecture is finally going to useful for its business over a long term.

______________________

==================================
MORE INFORMATION ON THIS TOPIC
==================================

The Best Web Links: tips, tutorials and more.

Ask your programming questions--or help out your peers by answering them--in our live discussion forums.

Ask the Experts yourself: Our application development gurus are waiting to answer your programming questions.


Dig Deeper on RPG iSeries programming

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close