(RULE) HARVEST SEASON

In the Midwest, the end of summer traditionally represents the “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 considerably 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 (some of our customers have started new projects this way), then you will need to consider how to capture it.

At InRule, we have harvested executable business rules from a wide variety of existing data artifacts. That list includes:

*Conceptual requirements / decision modeling techniques provide the organizational 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 that document. Based upon the type of artifact, the organizational 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 output 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:

1. Ensure these fields exist in your data model
2. Use your rule artifacts to ensure that the data model makes sense for the business problems you’re trying to solve
3. Open irAuthor and build / import that data model
4. Create rules against that data model that match your rule artifacts!

Sound easy? Let us know if you have any further questions about harvesting rules. The ROAD Team is happy to answer any other questions you’ve got about harvesting rules!