In my last blog I showed how we use business processes to harvest business rules, and how the two are fundamentally different things. In this entry I want to cover how to harvest even more rules from vocabulary, as well as how to decompose all of the rules we are collecting in our rulebook.
Harvesting Business Rules from Vocabulary
While most rules will be harvested through the business processes, the vocabulary should be analyzed for business rules as well. The relationships between terms are critical for this activity to work. Take the following example ER diagram:
There are probably some rules which constrain this relationship, such as how many applications can be submitted by a student. A business rule for this relationship could be:
'A student may only submit one application per year'.
The business rules collected from vocabulary will be a major input to enforcing a data model within SAP.
Rule Decomposition
When iterating through business processes and vocabulary our goal is to harvest all applicable business rules and to break them down into their most atomic forms. This leaves us with very specific rules which cannot be broken down any further than they already are.
For example, take the following rule:
'A student must send in bank balance documentation if their bank balance changes.'
This rule is not decomposed enough yet because there is still gaps that are not defined here, which usually means more rules or missing vocabulary. What constitutes a change in bank balance? Is there a time point on when this rule should fire off? Right now the rule applies continuously once they have a bank balance change. The above rule might better be written as follows below:
'A student must send in a bank balance document when their bank balance changes.'
Using the word when instead of if in this rule adds helpful context on the timing of this rule. We don't want to continuously ask for a bank balance document over and over again, but instead only need to ask for it when their bank balance changes. Speaking of which, bank balance change must be defined as well since there is nothing in the above rule which describes what constitutes a valid bank balance change.
'A bank balance change is any change greater than $1.00 in the total of all bank accounts which occurred since the application was last edited.'
Many rules are initially written with assumed or missed logic. The activity of decomposition must happen for each rule to ensure all business logic is harvested and that each rule is simple to understand. This process takes a long time, but it will pay off major dividends once you start building your business rules in BRFplus.
The next step is to find patterns in your business rules which allow the logic to be expressed more optimally in other forms than just semantic rules. Take the below four rules as an example.
Award A must be disbursed at the midpoint of the study period for undergraduate degrees.
Award A must be disbursed at the beginning of the study period for graduate degrees.
Award B must be disbursed at the beginning of the study period.
Award C must be disbursed half at the beginning of the study period and half at midpoint of the study period.
These rules would be better represented as a decision table:
| Award Type | Degree Type | Disbursement % | Date |
|---|---|---|---|
| A | Undergraduate | 100% | Midpoint of Study |
| A | Graduate | 100% | Start of Study |
| B | N/A | 100% | Start of Study |
| C | N/A | 50% | Start of Study |
| C | N/A | 50% | Midpoint of Study |
Decision tables allow logic to be represented in a very simplified format with the conditions on the left side (grey) and the results on the right side (green). Fee tables and schedules are the obvious candidates for tabular rule logic, but with some careful analysis many business rules can be built using decision tables. Another example of alternative rule formatting is decision trees. Take the following rules:
The study period start date is term 1 if the student is enrolled in term 1.
The study period start date is term 2 if the student is enrolled in term 2 and not enrolled in term 1.
The study period start date is term 3 if the student is enrolled in term 3 but not in term 1 or term 2.
An agent must manually review an application which has no specified term for enrollment.
These rules would be easier to understand if the hierarchy is represented in a tree format as shown below:
While BRFplus offers a wide variety of expression types for representing rules, from a blueprint perspective I will keep the focus on semantic rules, decision tables and decision tree's since those are the most business friendly forms of representing rules and are also easily implemented in BRFplus.
So we are now harvesting our rules from processes and vocabulary and decomposing them into their most atomic parts, as well as representing them as optimally as possible in formats such as decision tables and trees. Coming next in this blog series is the topic of rule metadata so we know what kind of additional details we need to collect per business rule aside from the rule logic itself in order to successfully implement in BRFplus.
- SAP Managed Tags:
