Ruleflows Considered Harmful

For some time users of Business Rule Management Systems (BRMS) have used rule execution sequence as a means of binding together and orchestrating the rules in a set—providing a ‘top level’ view of their content. Nearly all BRMS products have enshrined this idea in the ‘ruleflow’ concept. In many of these products the creation of a ruleflow is seen as a standard step in packaging a rule set and many rule authors find it a natural activity.

We argue, using an example, that not only are flows rarely required, but that they are frequently harmful to the agility of a rule set, can introduce harmful and hard to find errors and can make rule sets difficult to understand by business users. Furthermore, users frequently misunderstand the goal of ruleflows and misuse them.

We show that there is an alternative to ruleflows that orchestrates rules (especially large rule sets) more effectively and is easier to understand—the business decision model.

Introduction

At some point during the creation of a business rule set (or definition of a decision service), rule authors feel obligated to specify the execution sequence of rules using a ruleflow. For many it will feel like an intuitive necessity to impose an order on the sequence of rule execution; it would feel odd not to do so. It seems very natural to say “do X, then do Y and then do Z.” and to imagine that the order of these tasks is vital, even if it isn’t. The need for sequence often derives from nothing more than historical precedent—“this is the way it’s always been done”. It can also arise from the fact that, when requirements are expressed, an absence of sequence is hard to represent.

However, the order of execution of rules is not the primary concern when analyzing and designing rules. The necessary dependencies between them—the way in which the outcome of one rule is required by another— is the more fundamental, underlying issue. If there is no real dependency between the sequenced items then no sequence should be imposed. Unnecessary sequences are a barrier to flexibility, agility and understanding.

Therefore capturing inter-rule dependencies, which arise from business needs and which are reflected in the structure of individual rules, is a better way of structuring rules and can often be used to derive execution order. We will show that the habit of imposing sequence using a ruleflow is misguided, is very rarely necessary and can often lead to mistakes.

Instead of a ruleflow, we advocate using the decision model to structure a rule set. Decision models capture the dependencies that each rule has, both on input data and the outcome of other rules, and express these explicitly. They do not focus on procedural order of execution. Armed with these inter-rule dependencies, a ruleflow is, in nearly all cases, redundant.

By dependencies we mean both static dependencies (when one rule always requires the outcome of another as an input condition) and dynamic dependencies (when one rule sometimes requires the output of another, depending on the values of other data inputs).

Why You Are Better Off Without a Ruleflow

The drawbacks of manually defining and asserting execution order using a ruleflow are:

• It can cause subtle errors if it is wrong. If your ruleflow is inconsistent with the real dependencies between your rules, for example if it stipulates that a dependent rule executes before those on which it depends, then your rule set will not behave correctly. In many cases the error will be subtle and hard to locate. An example of this follows below.
• It has to be maintained, reducing agility. Every time your rules are changed there is a possibility the dependencies between them will be impacted. Consequently, there is a risk that the ruleflow will be undermined by an inconsistency as described above—the ruleflow is ‘brittle’. Therefore the ruleflow needs to be checked after every substantive rule edit, increasing the time to implement changes. In some BRMSs business users cannot change ruleflows so IT must be involved in these edits contrary to the agility ethic of business rules. Because decision models represent the innate dependencies between rules they do not share this maintenance issue.
• Ruleflows don’t tell us much. When a business user looks at a ruleflow (in some BRMSs this is not possible) it dictates the order of execution but doesn’t justify it, explain what information interchange is occurring or describe anything else. A decision model on the other hand shows the structure of the business logic and the nature of the rules’ cooperation. It can be used to perform impact assessments for proposed changes, show the usages of specific data items and the degree of rule reuse.
• Ruleflows are hard to scale. Composing large rule sets using only the concept of sequence is a weak method of managing complexity. Very large ruleflows are hard to understand, even if they are hierarchical, because they represent an imposed order of execution, rather than an inherent quality of the rules that stems from their definition.
• Ruleflows are often over-specified. For a given set of rules there are often not one but many correct sequences of execution. This is because the execution sequence of independent rules just does not matter. This over specification of ruleflows can pose unnecessary restrictions. We’ll show an example of this later.
• There is no standard ruleflow notation. Ruleflows are represented using a BRMS specific notation and decision flows are similarly . Decision modeling has an internationally recognized standard: DMN.

Why You (Almost Certainly) Don’t Need a Ruleflow

Consider below the likely reasons for a using a ruleflow and consider how you could use inter-rule dependencies instead:

• To determine rule execution sequence. Correct execution sequence can, almost always (see later), be derived from a decision model. In fact a decision model constrains execution sequence often defining many correct candidates. If one rule uses (depends on) an outcome of another then the latter must execute first. Otherwise the execution order is irrelevant (any will do).
• To determine if a (conditional) rule should execute. If rule A depends on the outcome of rule B only under certain conditions, then A can determine if execution of B is required. If, under specific circumstances, the outcome of a rule is not required (it has no dependents) it need not be executed. There is no need to impose a sequence here and to do so repeats logic that is already in the rules.
• To optimize rule efficiency: occasionally ruleflows are used to ensure that resource intensive rules are only executed when absolutely necessary, or to prevent needless repeated executions (i.e., reuse of data determined once). However, execution sequences derived from inter-rule dependencies are ‘lazy’ and only ever execute logic when the need for it is unavoidable.
• To provide an ‘overview’ of the rules: As we explain in another article, decision models are far more potent for this purpose than ruleflows.
• To define the rules packaged in a decision service. On occasions a rule set will define multiple decision services, each of which packages a different subset of its rules. DMN provides a better means of specifying decision services which obviates this application of ruleflows.
• To integrate data capture and integration with rules: BRMS often use ruleflows to set up input data streams and integrate defined processes into the rule execution path. This activity can be specified in the input data nodes of a decision model or in a business process. Often, however such activity is very implementation specific and best divorced from business rules entirely.
• To determine the invocation sequence of decision services. The sequencing of high level business services should be controlled in a business process, not within a ruleflow.

Exceptional Cases

The very few cases where a ruleflow is genuinely required involve run-time optimizations that cannot be derived from rule dependencies alone. We argue that these cases are rare and to place such configuration at the center of BRMS functionality is contrary to the key benefits of rules. Therefore, although these cases necessitate the stipulation of execution sequence, this should be viewed as a technical optimization and not made the focal point of the BRMS environment.

Example

Consider a grossly-simplified, example rule set from the domain of ‘pay day’ loans. The purpose of the ruleset is to determine the maximum loan amount we will extend to an applicant. The logic is completely specified by four decision tables:

1. Determine Persons Employment Record: which classifies someone’s (an applicant’s) Employment Record using details of their employment history that has been provided.
2. Determine Persons Personal Credit Rating: which uses this Employment Record, a person’s annual salary and record of debt to determine their Personal Credit Rating.
3. Determine Branch Lending Limit: which determines the Branch Lending Limit for the location in which the application was received, using the provided branch details and the overarching company policy.
4. Determine Personal Loan Limit: which uses the Personal Credit Rating and the Branch Lending Limit to determine the maximum loan to offer them.

From the expression of dependencies noted between these rules, one valid ruleflow (represented in BPMN) for these decision tables might be:

Determine Persons Employment Record is executed before Determine Personal Credit Rating because the latter needs the outcome of the former. However an equally valid sequence is:

This is what we mean when we say that the ruleflow over-specifies the problem: it provides too much irrelevant detail (in this case the precise sequence of Determine Branch Lending Limit). A more appropriate (less specific) ruleflow is:

Unfortunately this requires a understanding of BPMN parallel gateways (or worse whatever ruleflow nomenclature your BRMS supports) and could hardly be said to be business user friendly.

By contrast, consider the equivalent decision model (in DMN). The Decision Requirements Diagram (DRD) of a decision model is shown below. It is a representation of how decisions rely on one another (and on input data), not their execution sequence.

Notice that the decision model is superior to the ruleflow in that:

• It depicts all the of data dependencies between decision tables (depicted in yellow) using arrows that point toward the dependent.
• It depicts the dependencies rules have on input data (shown as green round rectangles).
• All of these data dependencies can be used to infer an execution order, even if it is dynamic.
• It depicts the dependencies rules have on external policy documents, local or external business expertise, legal and regulatory constraints (here shown in blue).

Conclusion

There is a common misconception among business rule authors that a ruleflow is necessary to capture the execution sequence of a rule set and provides the best overarching view of business rules. In the vast majority of cases decision models are a better means of achieving the same goals because they represent a more essential and meaningful relationship between rules in a rule set. Rule sets can be improved and maintenance issues avoided by using decision models instead. The use of ruleflows should be confined to optimization and sidelined in BRMS.

Refer to this article for other ways in which building a decision model can benefit business rules.