Integrating Business Rules and Business Processes

The topic-du-jour in BPM circles is the handling of human and automated decision making in processes. Two major areas that intersect here are the management of business rules (such as “customers with more than 100,000 frequent flier miles receive priority treatment when flights are oversold“) and business processes (such as “rebook voluntary denied boarding customer“). There has been plenty of work done in both domains, but until very recently they did not talk to each other very much.

That has changed quite rapidly, as the business rules community realized that it needed some ways to represent the structured order of long-running decision-making activities (as typically found in workflows), and as the process community realized that modeling decisions and rules using activity networks, BPMN, or Petri Nets results in rather bloated and complex diagrams.

On the research side, my colleague Marta Indulska from the University of Queensland and I have studied the expressiveness of process and rule modeling languages using representational analysis (i.e. we used a formal ontology as a benchmark) and found that the combination of process modeling and rule modeling languages generally offers higher expressive power than either of these languages by itself. We found the combination of BPMN and SRML particularly useful, but since SRML is an abandoned effort we would recommend the combination of BPMN and SBVR. Our paper on this topic was presented at the VORTE’07 workshop and can be downloaded here.

In practice, you can do some process management with a rules engine. Natalie Glance and colleagues have written some intriguing papers on Generalized Process Structure Grammars in the mid-1990s that essentially allow the modeling of processes using a constraint language (saying things such as “the start of activity B must occur after the start of activity A”, which are difficult to express using languages such as BPMN).

In the same vein, you can handle quite a bit of decision making using graphical process modeling techniques, by building gateways into your processes. This way, your process diagram becomes (partially) a decision tree, with alternative pathways for different cases.

Coming from the process side of things, I found the formal logic and languages used in rules management standards such as RuleML rather intimidating. So when I was offered the opportunity to speak on the integration of rules and processes at the IIR BPM conference a few weeks ago, I tried to approach this topic from a pragmatic perspective:

Say you are a process modeler: How do you approach the topic of rules?

Most process models I’ve dealt with contain at least some aspects of decision making, typically found in splits (decision gateways). In particular two general types of decisions can be distinguished:

• Decisions that affect the activities to be performed (Control Flow Decision). These types of decisions determine which process steps are appropriate for a given case (workflow instance). For instance, if you are dealing with a new customer and a large order you may want to perform a credit check, whereas you would skip this step if the customer is known to you. The decision in this case has an impact on the routing of the workflow instance.

We can distinguish some sub-cases in this scenario:

• Single-criteria decisions where we only need to review one parameter
• Multi-criteria decisions where we use decision tables or similar mechanisms to determine the case type

Similarly we can distinguish between:

• Manual decisions, made by a human (e.g. when judgement is required)
• Automated decisions that can be formalized

• Decisions that affect the assignment of activities to performers (Assignment Decisions). These types of decisions determine who gets to perform a particular activity. For instance, a customer service representative may review an order up to $5,000, but above that value we want a manager to review the order. The review activity in both cases is identical, the difference lies in who gets to perform the work. The decision in this case has an impact on the assignment of the workflow instance.

So what is my point here? Whether you model these types of rules in your process modeling environment or not depends on your context, the availability of a separate rules management environment, and most critically, the frequency with which these rules change. There is no universally right or wrong way to manage the intersection of rules and processes. If your decision rules are as stable as your process, great, leave them in your BPM development environment. But if your business users want to manipulate the parameters, separate them from the process and handle them in a separate rules management environment. You’ll be glad you did.

My presentation from the IIR conference is available on slideshare.net (see embedded presentation below). And for some well-informed outside opinion you can refer to Sandy Kemsley’s timely blog post on the presentation.

This entry was posted on Wednesday, November 21st, 2007 at 5:06 pm and is filed under BPM, Presentation, Rules, Standards. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.