Blog Posts Decision / Rules Management DMN

Ruleflows Considered Harmful

Blog: Lux Magi - Decision Management for Finance

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

Typical Simple Ruleflow
Typical Simple Ruleflow

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. 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:

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:

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:

One Eligible Ruleflow Expressed in BPMN

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:

BPMN alternate sequence

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:

A BPMN Ruleflow Expressing a Partial Order

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).

Equivalent Rule Structure as a DMN Decision Requirements Diagram

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

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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="https://www.businessprocessincubator.com/content/ruleflows-considered-harmful/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×