BPMN and Business Rules

Tom Baeyen's recently added his own thoughts to my blog entry on Routing Tasks to the Right Participants. Tom and I frequently vehemently agree with each other, so it's no surprise that we're in agreement again:

"Analysts provide a description of a business process. Typically that is a diagram plus free text documentation like e.g. this kind of task assignment rules. Then it is up to the process developer to come up with an executable process that looks exactly like the business analyst's diagram, but this time it is an executable process. Iterative development can then be realised on the executable process."

What did really get my little grey cells going was a comment on Tom's blog left by Ronald van Kuijk:

The task assignment example is indeed a valid one. But... would you want to do it with a 'processflow' (or a dsl based on an executable graph) or a rulesengine. I'd go for the latter but then again, that's just me

BPMN in and of itself does not capture the details of any decision... we use Gateways (splits, joins, etc) to indicate that the process can take many paths... but there is no standard for how to specify the decision logic. Lombardi Teamworks uses Javascript... but I have often thought that "the ideal" would be to plug in a Business Domain Specific Language for specifying the Rules that are associated with each Gateway (as well as the Rules associated with Task Routing).

(Obligatory disclaimer... I work for Lombardi, but everything expressed in this blog is my own fault, not their's)

I don't think that Ronald was suggesting an either-or conundrum between BPMN and Rules Engines... BPMN is a great DSL for the Process oriented aspects of an application, but for a complete solution it definitely makes sense to combine it with DSLs and Rules that are tailored for the Business Domain.

Those of us who implement Managed Business Processes just need to figure out how to architect our solutions to combine these complimentary technologies (Rules Engines, Business Natural Languages, etc.) in a way that insures that our clients can understand (and validate) what we've built for them. We also need to insure that those who will maintain our processes in the future will have a clear understanding of which technology we used to implement each aspect of the solution.