We have two readers ask similar questions of our Help A BA! staff concerning extracting business rules from legacy systems; so let’s help them both out.
Reader 1: As rules are mostly hardcoded and code walkthrough is too time consuming in mainframe systems, what is the best way to extract business rules from legacy systems without using the tools?
Reader 2: In most modern systems, business and processing logic/rules are defined in a separate Business Rule engine; but in Legacy systems it’s the other way as their logic and rules are hard coded or defined in the code itself. So how does a BA who is suppose to work on a legacy modernization project gather the requirements for these rules and logic as he can’t go and see the code and then understand?
Aaron’s reply:
These questions come quite timely as I have just completed a legacy modernization project for one client and have begun another one for a new client. The one thing I believe is that there is no substitute for the code walkthrough. The first reader doesn’t want to take the time to do a code walkthrough, but if you want absolute correct requirements, and business rules you must go through the code walkthrough. Now, I am not saying it has to be a formal code walkthrough nor have several people involved. The more people you have involved, the more correct your requirements and business rules are apt to be. The fewer people you have involved to faster the process is likely to go. I am not sure what tools Reader 1 is referring to, but I am not aware of any tool that can read legacy code and extract business rules; that will take a trained human being.
I actually suggest a two prong approach to legacy modernization projects; technical and functional. The technical is the code review/walkthrough. Have a Developer/Analyst, or a team, walkthrough the code and extract the business rules from the code. The second prong, functional, is having a Business Analyst (BA) interview the business people who interact with system under investigation and extract the functional rules from them. The business people who use the system every day know how the system acts. They know the “quirky” things that the system does. The BA should observe the business people interacting with the system, which could lead to more questions about the system.
The BA and Developer/Analyst can confirm with each other what they learn about the system. As a Developer who has transitioned into a BA role, I performed both the functional and technical reviews of a legacy ERP system for a client, to draw out the business rules and functional requirements of the system, as the company was preparing to replace their ERP package.
While interviewing and observing the Order Entry business people of the company, I learned that during order entry they would type the word “USUAL” in the ship via on the order. The system would see that, go to the Preferred Carrier table for that customer and retrieve the name of their preferred carrier and replace “USUAL” on the order with that carrier’s name. The Order, Invoice, Bill of Lading and other documents would print with the actual carrier’s name. Being the technical person on the project, I was able to confirm this during the code review, and see exactly how the system went about accomplishing that task. If I were not the technical person on the project, I would compare business rules with the Developer/Analyst and see if he/she found the “ship via replacement” rule of the Order Entry system. If it was not listed in their rules, I would ask them to confirm the rule as I received it from the Order Entry business people.
So you have two take-aways from this:
1) Like it or not, there is no substitute for a code walkthrough/review to help ensure you get the business rules correct.
2) Take a two prong approach to legacy modernization projects; technical and functional.
>> Learn to Ask the Right Questions
Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.
Click here to learn more about the Requirements Discovery Checklist Pack
Aaron,
I like your approach to finding business rules and I agree that the idea of a code review is important and the busienss people or BA’s are the key people to identify rules. There is one tool that can help in this process. evolveIT (www.blackboxIT.com) is a mainframe code understanding tool that identifies the interfaces to the business process such as screens, reports and the data containers behind them. Once you have these data containers identified a mainframe analyst can trace the output fields from the screens and reports to identify the specific source code the produces the output. This is called Data Logic Trace and makes the code review much faster since you don’t have to try to find the source code that matters to the output field. This is provided in an XML format that enables you to see only the source code snippits in the order that they execute.
These specific buseinss data traces into the mainframe system make a business rules project much more reasonable to accomplish. The whole project can be better planned since you have the business interfaces defined and can ignore everything that doesn’t impact the business (ie. thousands of lines of code that make up system architecture).
Bob et al,
In our book, “Smart (Enough) Systems,” James Taylor and I tried to make the case for abstracting business rules from applications for more than programming efficiency. With the right tools, your SME’s can maintain and enhance the rules without having to resort to opening the code. There are many business rules management systems available today, even some pretty good open source ones. Another added advantage is that the business rules engine operates separately from the application(s) it(them)self(ves). This provides the opportunity to stitch together decision management type processes that combine the results of predictive modeling, rules firing and execution as well managing continuous improvement of the rules through things like A/B testing and champion/challenger arrangements.
-NR
There are all some business rules extraction tools that can at least ease the task of unwinding embedded business rules in legacy code. They aren’t perfect, but I think the value the bring is worth it to get started. Of course, you need SME’s and BA’s to curate the stuff as much of it turns out to be irrelevant in a new system anyway, but that depends on the situation.
Bob, you make some very good points. That entangled mess is what makes ti difficult and time consuming to extract business rules or business logic from legacy system code. That along with years of modification makes one big mess we call “spaghetti code”.
Bennett, thank you for your comments. Good suggestion on validating requirements.
Adrian, good point about extracted business rules no longer being valid for the business and they should be validated and confirmed.
Then there are ‘ business rules ‘ – if they can even be called that – that are rarely if ever executed in the code. These are the ‘ else ‘ buckets that developers have to code to avoid confusing the computer.
Aaron,
You make some very good points!
I agree with your points above. The one thing I would add is that, in my experience, the fact that a business rule exists in a legacy system doesn’t necessarily mean that the rule is correct (or even still valid). In fact, I have worked on projects where business users have been “working around” incorrectly coded business rules for years!
Therefore, I like your suggestion of a two-pronged approach. The addition I would make is that all the “as is” rules that are extracted (either from the system or from interviews/observing users) should be sense-checked and critically reviewed. Ideally, complex business rules should be boiled down to their simplest essence so they are easy to understand and there is no ambiguity.
Kind regards,
Adrian.
Agree with above,
1. Don’t get bogged down by ‘ program logic ‘. This could easily absorb oodles of your time
2. Seek out business aspects from legacy program
3. Confirm findings by running input transactions and observing output produced. These are your surest business rules, in case you misunderstood the code
Aaron, I agree with your two suggestions. I would add a couple things: First, one reason that newer systems have separately encoded business rules is that hardcoded rules tend to be “entangled” with other code and “scattered” about the code base; in other words, everyone should be made aware that this is a problem and not expect that you can excavate the business rules as easily. Second, the two pronged approach is very important, because rules that are excavated from code can be wrong (or more precisely, they might not be real rules, but rather be assumptions or constraints related to the old system — not the business).
If I might add one more thing, do whoever comes after you a favor and document the business rules separately somehow, so they don’t have to go through the same thing you are going through when the system you are working on is retired.