Picking up from the rule harvesting we started in part 3 and part 4 of this blog series, we should now take a look at what kind of metadata we need to record per rule in order to make the implementation in BRFplus as simple as possible. There could be a variety of different attributes that an organization wants to capture on their business rules. Depending on what kind of things need to be tracked this task can go from being easy to very difficult. The following is some details on what I think are the basic attributes to track per rule as you harvest.
Rule Source Documentation
This can be as simple as stating the section of a policy document where a rule was sourced from, to as tricky as sourcing the actual program code from the legacy system. What is important to keep in mind is the difference between details you need during the rule transformation, and details you need for long term management. During a rule harvesting and documentation project there may be multiple translations of a rule from its source to the new documentation format. Whether or not an organization wants to keep track of each translation explicitly, or refer to a more general source in the long term is up to them.
Associated Process Task(s)
Since every business rule is called by a business process at some point we must make the connection from the process task to the rules somehow. It’s critical to note here that only the rules which are directly called within the task should have this mapping, and not the dependent rules. For example, if process P1 calls rule R1, and rule R1 calls rule R2, we would capture the link between P1 and R1, but not P1 to R2 since R2 is not directly called by the process. When you document rules in a declarative repository such as a wiki, the links between rules are automatic, so all we need to consider is direct links between processes and rules.
Functions and Rulesets
While this mapping might not happen until realization depending on what blueprint methodology you follow, a business rule must be mapped to either a function or a ruleset in BRFplus. If you are calling a BRFplus function in either ‘Functional’ mode or ‘Event’ mode with a single ruleset, then I would map the rule to the function. In those scenarios the function is effectively your process task. However if you configure a function in ‘Event’ mode and specify multiple rulesets, then I would map your rule to the specific ruleset for better traceability. We will visit this more in my blogs on realization.
To be clear here, the rules you build in BRFplus will not match 1:1 with the rules documented. It’s just not possible technically speaking. In fact many of the documented rules might not even end up being BRFplus rules, but rather ABAP, standard SAP customizing or other things. What you need to note for each rule, is technically how you think you will build it in SAP. If you documented a decision table in your wiki, then it would be fairly simple to note that you will also implement it as a decision table in BRFplus. However you might want to add some technical notes in here too around what technical requirements are needed to make this decision table work. I.E. what kind of expressions might be called in the condition columns, what kind of actions will be fired off etc. Once realization starts these details will be greatly expanded upon depending how you end up implementing the rules. During blueprint you will mostly be noting ideas to get a count of certain types of rules. I.E. we need 100 rules, 40 decision tables, 50 search trees etc. These details will help validate the scope of realization and well as prepare for the implementation.
Every business loves to keep the ability to manually override their rules. On a per rule basis we must note which rules can be overridden by the business and how to achieve this override. This is very important to understand before creating a technical architecture for the rules, as overrides can sometimes be tricky to implement.
Discussion and Comments
As business rules change the author should keep a log of what kind of changes are being made. Somehow in your rule repository you must keep a discussion or comment log to trace back on changes that occur to each rule.
Unit Test Case(s) and Results
Finally you need to document unit test cases and results for the business rules. This is pretty easy since if you decompose your rules to the most atomic level possible, the number of conditions for testing against in a particular rule should be relatively small.
Bringing It All Together
Below is an example of how a rule could finally be documented in a wiki with metadata included (click image for larger version):
So to summarize our progress so far in our blueprint, we have talked about which tools may work better than others and selected an appropriate rule repository. We have ironed out the businesses vocabulary and the relationships between terms. We also used our goals and decisions to create some business processes and began harvesting rules from these processes. Finally we decomposed the rules into their most atomic pieces and today we added the required metadata to each rule in order to make the rule implementable in SAP.
In my next entry I will finish this series on blueprinting by looking at other considerations you must take when preparing for your BRFplus implementation.