What did really get my little grey cells going was a comment on Tom's blog left by Ronald van Kuijk:
"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."
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
(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.