With the advent of Generative AI, transformation projects that once seemed challenging are now emerging as viable solutions to long-standing legacy modernization issues. One of the primary hurdles with these applications has been the uncertainty surrounding their underlying structure. Today, with the ability to accelerate knowledge curation phase, extracting business rules within defined timelines has become potentially achievable. In this blog, we will discuss the various factors and scenarios that impact the Reverse Engineering (RE) phase of legacy modernization and explore practical ways to address them. We will also talk about how Infosys Live Enterprise Application Development Platform can help bridge critical gaps during this phase and reduce complexities.

1.     How should we position the rule extraction phase in an application re-write/migration program?

a.     Although rule extraction phase should be treated as the initial phase in an application re-write program, it should not commence too early. It should start only after all the downstream phases are ready to go onboard. Reverse Engineering activity should begin only after there is complete clarity on how the extracted output will be utilized and once the solution design has been finalized.

For e.g., in a three-to-5-year transformation program completing all Business Rules Extraction (BRE) activities within the first 6-8 months is not advisable.

                                  i.         Ideally in an agile methodology if requirement three is being developed, requirement two should be in build and requirement one should be in testing.

                                ii.         In reverse and forward engineering (FE) programs, the requirement life spans across reverse engineering, forward engineering, unit testing, user acceptance testing, production and warranty. The effectiveness of the reverse engineering (RE) exercise improves when the end of RE phase is positioned closer to deployment or warranty, while still balancing other influencing factors.

b.     Another crucial factor in positioning the BRE phase is the potential number of changes the application may undergo during the In-flight programs. It is critical to establish a clear plan for reconciling these recent changes with the documented requirements.

c.     A short PoC phase should ideally be conducted to finalize the tools, processes and artifacts expected from the Reverse Engineering phase. The outcome of this phase should be mutually agreed upon by business analysts and forward engineering stakeholders.

d.     Ensure that the final BRE team members are not released before system testing begins. As and when they are offboarded, they should transition their knowledge and artifacts not only to the remaining BRE members but also to the business analysts and forward engineering team members.

e.     Typically, 40 % of Reverse Engineering phase should overlap with Build & 20 % of Reverse Engineering phase should overlap with Testing.

2.     Composition of BRE team:

While it is essential that a BRE team consists of developers proficient in the native legacy languages such as COBOL, PL1, RPG, Assembler, building the entire team with only legacy developers will not deliver the desired outcome.

a.     The primary goal of the BRE exercise is not just for legacy developers to comprehend the application, but also to ensure that business analysts, forward engineering architects, developers, testers, integration teams, and data modelers clearly understand the insights gained,

b.     The team composition recommended is

i.     60- 70 % – Legacy language developers.

ii.     20 -30% – Business Analyst (depending on availability)

iii.     10 % – partial or full representation from Forward Engineering lead, who can begin the journey together and carry it forward.

 iv.     5-10 % – Representation from the testing team.

 v.     One BRE team member may serve as a full-time reviewer responsible for transforming requirements into technology-agnostic terms. This helps reduce or prevent rework.

3.     Keeping the To-Be State solution in mind:

a.     Reverse Engineering artifacts for an application rewrite will vary significantly depending on whether the To-Be solution is COTS, Low-Code/ No Code, pre-packaged software or a combination of multiple strategies.

b.     When modernizing legacy applications such as Mainframe or AS400 by rewriting them into technologies like .NET or Java microservices, the new application   typically retains 60-70% of the original functionality. In most transformation programs, there is limited scope to change data structures and application logic. In such cases, the business rules documentation should aim primarily at helping To-Be development stakeholders understand the AS-IS application. This requires a bottom-up approach where the code becomes the first point of analysis.

c.     When the To-Be solution is COTS or pre-packaged software, the business rules documentation should focus on identifying the gaps between the legacy application and customizations needed. This requires a top-down approach where process or use cases are the first point of analysis.

d.     When the To-Be solution is a mix of COTS and application re-write, a hybrid strategy should be adopted. It is essential to clearly define integration touchpoints between the COTS product and the rewritten components. It is advisable to simulate the integration by using sample test data for data interchange and include these prototypes as part of the deliverables, rather than limiting the documentation to code structures.

4.     Document Size & Format:

a.     Format:

i.     The forward engineering approach will determine the format of documentation to be created. For example, if the forward engineering tools and processes require pseudo code, file layout definitions, or similar inputs, reverse engineering team should generate them.

ii.     Each customer will have a pre-defined format of capturing requirements, so it is better to adhere to the format.

1.     In case there is no predefined format, below sections should be included:

·       In-scope/out of scope section

·       Detailed business rules section.

·       System architecture section.

·       Dependence section.

·       Interfacing system section.

·       Files layout screen.

·       Database section.

·       UI/Screen section.

·       NFR.

iii.     The focus should be on capturing requirements with higher priority. Since Reverse engineering phase is time-constrained, the other sections can be captured at a summary level and elaborated in later phases.

b.     Document Size:

i.     Very large documents running into hundreds of pages often become non-starters for consuming stakeholders because they may lose interest or find it difficult to navigate.

ii.     A practical guideline is to keep the documentation concise and crisp. Additional details can be expanded and clarified during review sessions.

c.     Text vs Flow chart

i.     Visuals often make a stronger impact than plain text, but teams should avoid creating flowcharts or diagrams for every requirement, as this can lead to unnecessary effort and delays.

ii.     Flowcharts should be created primarily to explain end-to-end workflows.

5.     Requirement Traceability:

a.     Requirement traceability is always a concern, and there are no fully proven methods to achieve end-to-end tracking. However, placing excessive focus on traceability during the BRE phase can divert focus from the primary objective of understanding and documenting business rules.

b.     Conducting requirement reviews with SMEs, complemented by brainstorming sessions involving the BRE team, business analysts, forward engineering developers and testers, can help identify requirement gaps at an early stage.

6.     Capturing NFRs:

a.     Capturing NFR’s like performance, throughput, execution time is often neglected during requirement gathering & is sometimes assumed to be out of scope.

b.     NFR’s of the current applications are closely tied to how the application is built. There should be a clear placeholder in the Reversing Engineering phase to document these NFRs.

7.     Leveraging Tools & GenAI:

a.     Many third-party tools can automate and accelerate the reverse engineering process, making a fully manual approach impractical. Tool selection should depend on client preferences and the availability of suitable solutions. A short Proof of Concept (PoC) is recommended to validate the effectiveness of the chosen tools.

b.     GenAI brings significant flexibility, speed, and efficiency to the Reverse Engineering process. Unless the client explicitly restricts the use of GenAI or disallows sharing source code outside their network, GenAI should be leveraged extensively in the reverse engineering engagement.

c.     Key considerations when using GenAI include: –

i.     GenAI responses can be stochastic and may produce inconsistent outputs, non-repeatable standards, hallucinations, or incomplete interpretations of code.

ii.     The team should avoid accepting GenAI outputs as final requirements. Instead, GenAI should be treated as an assistant. At times, GenAI may misinterpret context without domain knowledge or introduce business terms that do not fit the scenario.

There may be other factors other than those included in this blog, but we have highlighted some of the most critical ones. The reverse engineering phase is the first step in any transformation program, what starts well ends well. Infosys GenAI augmented Infosys Live Enterprise Application Development Platform can significantly accelerate the Reverse Engineering journey for large mainframe modernization programs in a seamless manner. Many of the concerns discussed in this blog, such as requirement traceability and visual flowchart generation can be easily addressed with our platform.

About the author

Virendra Shambharkar is a Senior Technology Architect with Infosys and has 22 years of experience in mainframe technologies, mainframe modernization, data base migration, MIPS optimization, performance and DB tuning, Application portfolio assessment, Mainframe Rehosting, product conversion.