My experience on Mainframe modernization for major US Bank

Background on Mainframe modernization:

      After computer revolution started in Banking, Insurance and other major sectors Mainframe was one of the biggest revolutions to store and manage data in more secured way. Even now many major Banks and Insurance companies still maintaining the Mainframe system.

      As time flies on, technologically so many changes came, and world became more digital, and users/customers wants to access data within fraction of seconds and no time to go into traditional way of Banking and other services. So, Banks and other Industries are forced to move towards Digital way.

 In this Digital fast world to access data from Legacy systems like Mainframe becoming difficult to provide fast services to customers, so Clients are looking to go for modernization.

Major Initiatives to be followed for Mainframe Modernization are:

1. Re-Engineering: Disruptive Transformation to Digital Platforms like Cloud and Micro Services
2. Re-Hosting: Re-platforming qualified applications to Distributed Platform retaining Legacy Architecture and Code ​
3. In Place Modernization: Leverage System z and System I modernization capabilities with a right mix on Legacy
4. Replace: Replace the application with a suitable COTS product after doing thorough fitment analysis​

This blog describes about the Re-Engineering scenario. In this scenario we need to extract the Business Rules out of Legacy code which Forward Engineering team will be used as Requirement Document:

How to convert the Mainframe code into Business Rules?

1. Template Preparation:

     Whenever we start any Legacy conversion the first most challenge is to understand the existing business logic and bring that to proper format which Forward Engineering team can understand and come up with their coding way.

The template is key to put the business rules together, if template can describe the below it would be helpful:

1. Job Summary (JCL Summary) which should describe the below –
   1. Job functionality / Description
   2. Files Used in Job (Read/Write)
   3. DB2 Tables used (program wise)
   4. Scheduling information
   5. Job Flow (probably Tree structure)
   6. Restart Instructions
2. Business Rules - it should describe the rules associated with the specific function from the specific program
3. Record Layout – Record Layout/File Structures used in the program
4. Field Mapping – It should describe either in pictorial or in a table format how the source to target mapping done in the business logic/program

   2. Writing the Business Rules:

     Analyze the code and understand the logical flow of the program. Don’t try to write each paragraph as a Rule, if needed we may have to combine the paragraphs to bring the business logic/rule in a logical way.

The below needs to be considered while writing the Business Rules:

• Map every transaction and Job to a business function   
• Once rules are captured, map them to level-4, level-3, level-2, level-1, and level-0. Level-0 being the highest and it is combination of levels 1 to 4 to achieve the feature (example: customer onboarding will be leve-0)
• Headings, Subheadings – Headings and Subheadings are very crucial while writing the business rules for ex: in General, Processing Paragraph will be there to process the core logic, all the functionalities under this section /paragraph will come as subheadings, you will be able to understand the entire flow or logic by seeing the heading and sub-headings.
• Temporary Variables/Working Storage Variables – Make sure give the reference for any Temp variable, mention the rule number where we will be using or referring this variable 
• IF Conditions and EVALUATE Statements – In Old programming style for IF conditions END-IF would not be mentioned, so make sure to mention the END-IF and use the colors in case of nested IFs. Break each condition into a specific rule.
• PERFORM Loops – Mention clearly about the Loop when it is starting and when it is ending
• ARRAYS/Tables – Mention all the declaration in case of Arrays/Table and its associated usage for a specific function.
• Database – While writing Database related logic, better to write the DECLARE CURSOR and any other SQL Statements as a Rule and give the reference wherever you need referred. Mention the meaning of SQLCODE while adding the logic in Business Rule.
• Error Handling – Make sure error handling is properly documented along with DISPLAY statements.
• Common Routines - Common Routines Rules can be placed in one common sheet or document so that Forward Engineering team can build them one time and use it.

Presenting Business Rules to Forward Engineering Team:

       The main challenge how effective you can explain the logic to Forward Engineering team, if you get some Technical BA who has knowledge on the system you are lucky enough! So that you can explain the logic and BA will understand and can come up with Use cases.

The better way from Mainframe side is to come up with some flow diagram with very high-level flow on job level. So that it’s easy to digest to Forward Engineering team on the whole flow and easy to Mainframe guys to explain about the flow also.

Make sure explain all the logic to BA and Forward Engineering team. And if Low-level design would be created in Forward Engineering side, then in their own way of working. It would be useful to the team.

Converting Rules to Java:

      While converting the Mainframe COBOL to Java, one should understand the difference between COBOL and Java. First, COBOL is Procedural Language, and it would have defined the steps in sequence. Whereas Java is Object Oriented Language which follows OOPs concepts.

Consider the types of applications that are well-suited for COBOL. The term COBOL is an acronym for Common Business Oriented Language. The language was designed to support business functions like reporting, number crunching, and processing data. This does not mean that COBOL cannot perform other types of processing; it can. Just that some types of programs may be better developed using another language.

    Java is an object-oriented programming language that is suitable for multi-purpose computing, with the added benefit of being portable across multiple hardware platforms. The ability run the same program on different computers (if a Java Virtual Machine is available for the platform) is one of the reasons that Java is one of the most popular languages for new development today.

The below considerations to be done from Java side to convert COBOL code:

1. Understand the java coding standards as per Client environment
2. The difference between COBOL & Java Data Types
3. Equivalent Functions between COBOL and Java.
4. What database connection to be used in Java in case of Legacy database calls (either JPA or JDBC)?
5. Is there any Query optimization can be done for the DB Queries?
6. Is there any Parallel Runs (between steps) can be possible?
7. Can we implement Chunking logic on DML operations?
8. Any common routines/services need to created and re-use them