BPMN and Business Rules

In his comment on my post What’s Wrong With This Picture?, FairIsaac’s James Taylor asks many of the right questions about BPMN and Business Rules.  I thought it deserved its own thread.  He asks,

- how do I differentiate between decisions that are simple ?Customer is New/Not New? and complex ?Customer?s credit is good/bad?? One of these is about routing rules, one is about decision rules

- are there any subsets of the activity box to allow me to show decision services as activities more explicitly? Has this been discussed ever particularly in terms of allow looser synchronization of rules and process?

Actually, BPMN barely deals with rules at all, and where it does, it does it in kind of a strange way. 

The BPMN spec defines an intermediate rule event, which can be attached to the boundary of an activity (task or subprocess) to indicate an exception flow triggered when a “rule becomes true.”  Here a rule is defined as “an expression that evaluates some process data.”  I have never seen this used in practice, but even imagining where it could be used, it’s not the way business rules are usually implemented in BPMS. 

Let’s count the ways in which BPMN’s treatment of rules is strange: 

  1. The most common use of business rules in BPMS is a decision service.  That’s like James’s second example – customer credit is good or bad.  In BPMN that would be modeled as a task (with a web service implementation).  It has nothing to do with the rule event.  In many examples used for descriptive modeling (i.e. no intention to drive an execution language like BPEL), the rule evaluation is implicit in a gateway.  For example, a gateway might split paths for customer credit good vs bad, but the decision task (credit evaluation) is not even drawn… it’s just implied.  That’s bad practice but very common.
  2. BPMN rule events refer, not surprisingly, to event-triggered rules.  In BPMS these are less common than a decision service invoked by the process.  Some BPMSs (e.g. Cordys, Pegasystems) use event-triggered rules to model constraints on runtime business objects.  When instance data is inserted or updated, a business rule is triggered.  The other place they’re used is BAM, where the rule is triggered by an update to a performance metric or KPI, i.e. an aggregated measure of process data.  But I know of no BPMS that uses BPMN rule events to describe this behavior.
  3. What seems to me would be a good use of the BPMN rule event might be response to an external event such as update to an external database or content repository.  In these cases the external event is generated by the database or CM system, not by a ”rule”, so the rule event is not reallydistinguished from an intermediate message event… the normal symbol for an external event triggering an exception flow.
  4. The other interesting thing about a BPMN rule event is that the event must occur within the context of a particular activity (task, subprocess, or entire process) to have effect. For example, if the business event that would cause a “customer credit is bad” rule to fire occurs prior to the activity where the BPMN rule event is attached, it’s as if the event never occurred. Also, the rule event’s effect is to interrupt (abort) the normal flow of that activity and launch the exception flow.  But this is just a subset of things business rules can do.  For example, what business rule management calls a declarative rule might say simply “if A and B, then C”, where C might just set the value of a variable.  So BPMN rule events don’t map well to declarative rules.

In short, BPMN’s rule event does not seem a particularly useful construct.

  1. VernonSVernonS10-21-2006

    I think there are some good uses for ‘rule’ in the Intermediate Boundary Event context. As a specific example consider an activity such as an approval. One might attach a timer to an such an activity to remind the approver to act on the activity on a timely basis. If after some number of notifications (let’s say 2) the approver still has not acted on the activity, a rule (as an Intermediate Boundary Event) could be invoked to escalate the activity to an alternative approver or supervisor.

    Actually I perceive this type of ‘rule’ to be a fairly common event condition, and the rule as an Intermediate Boundary Event models this well. It’s also consistent with the BPMN definition of a Event, which is to the effect of “An event is something that ?happens? during the course of a business process.”

    Part of the confusion between this approach vs. what’s referenced as a rule in the context of ‘?Customer is New/Not New? and complex ?Customer?s credit is good/bad?? One of these is about routing rules, one is about decision rules’. While we may refer to these as Business Rules, I wouldn’t necessairly consider it a rule in the context of an ‘Event’ which is the general way I understand rules to be intended within the context of BPMN (as quoted in the paragraph above). Instead, I would consider these to be business logic. This logic could be implemented by invoking a rules engine or through the Gateway constructs, but trying to implement it using the an Event rule seems inappropriate.

    I think the key here is making sure we don’t confuse business rules with a BPMN event rule. While they share a word in common in their general definition, their intent is quite different.

  2. brucebruce10-21-2006

    I’m in total agreement with you about the use case, but still the rule event seems superfluous and mismatched to the way BPMSs work. In your approval reminder example, the first reminder would be a timer event where the exception flow sends the reminder and loops back to the original activity. The escalation “rule” is just a second timer. According to Steve White, this should be modeled as a “multiple” event – I’m no fan of the multiple trigger because it hides the semantics from the diagram, but even if you attached 2 intermediate events to the activity (Steve says no), the second one could just as easily be another timer as a rule.

    My frame of reference is usually the way BPMSs work. You are correct that there are 3 types of rules involved. Routing rules are gateways in BPMN. Decisions are tasks in BPMN, e.g. invoke a decision service on a rule engine, or perhaps a scrpt in the process engine. Where do you see event-triggered rules in BPMS? The one place I can think of is BAM. To have relevance to BPMN, the BAM event action has to affect the process flow. The BPMSs I know can do this in one of 2 ways: start a process (ok that’s a rule start event) or invoke a web service. I suppose you could twist the latter into an intermediate rule event by saying the web service sends an event to a process activity. But then why not call that a message event? I could agree that if that’s what you mean, a rule intermediate event is appropriate. But I think that implementation is pretty rare.

    There are some BPMSs that use event rules more generally than in BAM, for instance Cordys and Savvion. See my reports on those products in the 2006 BPMS Report series for details.

  3. VernonSVernonS10-22-2006

    Agreed that the first case (reminder) is a timer event, however while the second event can be implemented as a timer event expressing it as a rule event seems more consistent. Escalation occurs if the reminder has triggered some number of times. Implementing as a rule allows the time event to be changed without having to worry about making any change to the escalation rule: the escalation logic is independent of the timer value. Personally I think this is a better approach. Easier to communication with a client, and clear in purpose. Decoupling unique requirements is a good thing.

    I also still see both of these cases, timeout and escalation (based on a rule) as good examples of intermediate events, and BPMN supports modeling them quite well. I was focusing on this more from the modeling/BPMN perspective instead of a BPMS perspective.

    From the BPMS perspective, BEPL of course supports timer events but doesn’t provide direct support for rule events (as I understand the specification). Of course you can implement these using service invocation constructs, but personally I prefer the conceptual approach provided by BPMN and see the lack of support for rule events more as a weakness of BPEL, but that’s just my opinion.

  4. MohammadMohammad07-19-2010

    Hi Bruce,

    Can we say that every conditional logic in a business process is a business rule?


Leave a Reply

− four = 5