Business Rules Extraction …. or Not?

Consider you have a mission critical business application consisting out of 10 million lines of code (LoC). The application has been developed using a legacy programming language such as Natural (or COBOL for that matter) and runs on a mainframe. Over the last couple of years, you have experienced that it’s getting increasingly hard to find the necessary skills to keep the application running, let alone to extend it with new functionality to meet your continuously evolving business requirements. Hence you would like to transform the code to a modern language, say Java, while preserving the business logic.

Business Rules Extraction (BRE) is an approach through which an application’s business logic is redeveloped in new technology based on the original source code with some automation tools and a significant amount of human intervention and interpretation.

BRE is theoretically a very attractive proposition for organizations, and we are aware of moderate success stories for applications consisting out of 200K – 300K LoC. However, we have not seen any case of projects with more than 500K LoC that were completed in less than 2 years. This limitation of applicability of the BRE process stems mainly from its semi-automated nature: most of the work still needs to be done by the developers with application knowledge.  

Applications developed using the aforementioned Natural technology are typically much larger in number of LoC though, and it would take probably 10 years or more to refactor let’s say 10 M LoC – if at all feasible.

Compared to this, the alternative solution of a 100% automated migration would take considerable less time and be considerably cheaper and less risky when applied to projects of this magnitude. Moreover, once the Java code is in production, this code can be refactored step by step without any risks or huge costs.

There is also another very important aspect to consider when modernizing such a legacy application: the application’s maintenance history. In Natural, the modification dates of the code are kept in the repository, that is why it is easy to have accurate data. Every argument made here holds for COBOL or any other legacy language also.

What would be the average number of days since the last modification of each of the application’s sources?

This graph shows real-life data from the last Natural customer we migrated to Java/C#. The percentage of Natural code that had not been touched in the last 5 years or more is a stunning 80%! If (most of) these programs are hardly ever maintained – why go through all the effort, costs, and risk of a migration project using BRE? It is hard to imagine one would invest a huge amount of money in a risky project to refactor code that hardly ever changes.

Choosing the right modernization approach is one of the biggest challenges facing IT leaders when planning a digital transformation project. At Astadia, we use a proven methodology to help organizations assess their options, develop a plan, and successfully migrate to modern programming languages. Take a look at our Resources to learn more or contact our experts to get tailored advice for your project.

‍