Eng 
日本語
Br
DeThe promise of automated business rule extraction (BRE) from legacy systems and re-use in Business Rule Engines has been here with us for decades. Without killing the joke, we can safely assert, this has – similar to other promises of complex information processing solutions e.g., automated language translations, – always been just a few years away.
What is BRE?
Business rule extraction is a process of analyzing a piece of legacy application and creating a description of “what it does”. The “what” part includes context, use cases, functionality, data being processed, interactions, I/O, computational formulae, boundaries, constraints, etc. Everything that is necessary to be able to reproduce the exact functionality in its entirety in a new environment.
The output of such an endeavor is in any format, usually diagrams and plain English, as formal as possible. As if it was a system plan to begin with.
These business rules take on their meaning when they become part of business processes.
Why and when do we need it?
During legacy modernization, application transformation projects, if the decision is to refactor/rewrite – as opposed to rehost – the applications, developers and business analysts must have a really good grasp of what’s happening in the code.
Fundamentally, a customer may have two directions for modernization from BRE perspective:
- either touch the code and refactor/rewrite that requires BRE
- or rehost/replatform, take the legacy code and move it to the new world, one way or another.
We at FreeSoft vouch for moving away from legacy languages and databases as fast as possible. Once in the new world the availability of expertise, technology and tools is abundant, and the impact of modernization is immediate.
Depending on the customers’ number one priority BRE may be necessary. We all wish it would be simple, painless, fast and possibly automated. Oh boy!
What’s the motive?
As I mentioned above BRE is a useful step when a customer decided to rewrite the application. While rewriting an application (I mean hundreds of them) is a time consuming and risky endeavor, there are companies with sufficient “selling power” and charge for T&M. There is a legit reason for BRE though: when a company decides to use a business rules engine, like PEGA.
What’s the promise?
Be alarmed when a company promises to be able to do automated BRE and implement these in Business Rule Engines. Let me be as blatant as those that claim it can be done: outright lies. Have them make a PoC and see if they didn’t exactly mean what they wrote on their white pages. They need certain artifacts, some SMEs to explain and put their result in context or give proof of the extracted rules are indeed meaningful and usable by developers and BAs. Let us know if you’re satisfied. Let us know if they can scale up from a few hundred thousand lines of code to the magnitude of 10 million.
Can it be automated?
The short answer is no. A little longer answer is not really. Scanning and analyzing the code can be done and may yield some insights, but without human understanding no meaning can be given to the results of such an analysis. Major pitfalls being:
- Naming objects for human understanding:
let’s assume the code is nicely structured and objects are named congruently. Good luck with assigning a meaningful name to “AUSATRN”, “C200-EVALUATE” and alike. And what if the names are not even close to being readable and the code flow is a mess.
- A static analysis of code is inherently incomplete because the code flow may depend on data stored somewhere and accessible through layers of abstraction (JCL, logical names.)
- A business rule is not a business process. A process may involve business users to do this, to do that: download/FTP a CSV, edit (and sometimes break) it somehow, upload an Excel sheet, etc.
- A corollary to the previous one, correctness: one cannot be sure that a business rule, even though properly extracted, is valid. Business users may workaround some quirks, incorrectly coded business rules for years. We’ve been there, we’ve seen that.
- An automated BRE process is no substitute for an application documentation… and documentation is – to put it mildly – a bit lacking. Honestly, does anyone remember why the code was changed in 1993 around New Year’s Eve by John? Was it a bugfix, following up on a change in law, a new product model or some specialty with a distributor somewhere? Was this change reflected back in the system documentation? Maybe. But just maybe. But even if it was, how can an automated BRE use this info?
And the list goes on….
What can be done then?
There is no substitute to human understanding. Various companies and experts have developed methodologies to BRE, but all involve developers, business analysts, subject matter experts and business users to get a good gist of what’s happening buried in the legacy code and to put it in a format that can be used. These processes take time. Sometimes very long time, proportional to the amount of code. Due to scarcity of subject matter experts and legacy language developers, the process cannot really be shortened by getting more people involved. We’re talking years here.
So! What can a reasonable decision maker do in complex situations like these? We suggest taking a divide and conquer approach: convert legacy to java and do BRE only on those parts of the system that require agility in the very near future.