IN THE MIDWEST, THE END OF SUMMER TRADITIONALLY REPRESENTS "HARVEST SEASON," WHEN FULLY GROWN CROPS ARE HARVESTED FROM A FARMER'S FIELDS. WHILE THE CONCEPT OF "RULE HARVESTING" BORROWS METAPHORICALLY FROM THE NOTION OF PRODUCING CROPS, HARVESTING RULES FROM EXISTING RULE ARTIFACTS IS A CONSIDERABLE DIFFERENT EFFORT.
Where Rules are Often Found
Once you’ve determined that you wish to use a rule engine (or any other software) to execute your logic, you need to find a way to turn your existing rule artifacts into rules logic. If your business rules project revolves around data that is not currently being captured , then you will need to consider how to capture it.
We have harvested executable business rules from a wide variety of existing data artifacts. That list includes:
Paper forms (!)*
Word documents
Process diagrams*
PDF documents
Excel spreadsheets
Legacy system code
Database queries
Visio diagrams*
Decision Management Notation (DMN)
The Decision Model (TDM)*
RuleXPress*
PowerPoint presentations
*Conceptual requirements / decision modeling techniques provide the organisational context for creating automated rule structures and execution patterns in InRule. Detailed, field-level rules are often a byproduct of field-level analysis of these requirements.
An Example of Initial Business Rules The table below represents rules that a business analyst has identified and tagged. But what else needs to be done with these rules to get them ready for a rule application? How can these rules be translated into action?
The Process of Harvesting Rules
Whichever legacy document you’re looking at, the process you follow in order to harvest that document is still going to be largely the same:
1. Identify all of the business rules from that document. Based upon the type of artifact, the organisational techniques you use will likely be different.
2. Determine which business rules (pieces of logic) you wish to bring into a rule application
3. Analyze those business rules to determine the inputs and the outputs you wish to see
4. Start to match these inputs and outputs to a data model, either an existing one or one which you’ll create
5. Identify all possible combinations of inputs and outputs for each rule (accounting for possible null or bad data), and how you wish to have the rule engine respond to those combinations
6. Finally, start putting those decisions into rules!
Our Example: Creating Rule Logic from Specific Requirements Using our previous example, it’s easy to add a column to the existing table of rules and begin to identify the specific logic required to make programmable rules out of business logic. For the purposes of this example, a third column (“Rule Logic”) has been added, and words have been bolded where we could narrow this down to a likely field or collection name.
Practical Next Steps Once the list of likely fields has been collected, the next steps are:
Ensure these fields exist in your data model
Use your rule artifacts to ensure that the data model makes sense for the business problems you’re trying to solve
Open irAuthor and build / import that data model
Create rules against that data model that match your rule artifacts!
Sound easy? For any further questions about harvesting rules or if you require more information, please contact us. We would be happy to help! *Original article: https://www.inrule.com/resources/blog/rule-harvest-season/