Another Good BPMN Example from Anatoly

Scott Francis
Next Post
Previous Post
Anatoly has posted an example regarding orchestration and collaboration, and he has two particularly good pieces of advice at the end, though the whole post is worth reading:
Rule 1. If your attempts to model a process are unsuccessful because some significant aspects are missed repeatedly then stop and think – maybe in fact it’s not a single process but two or more? Rule 2. Do not overuse collaboration – stay within the orchestration as long as possible. Never introduce collaboration into a diagram just because you’ve recently learned how to do that.
Both of these are excellent.  Rule #1 is exactly how I approach splitting something into multiple processes.  Rule #2 is just a good rule in general for any piece of functionality you’re not overly familiar with, or any advanced functionality.  Start with the basics, and only go to the more advanced features when you clearly need to.

Tags:

  • As @StephenAWhite suggests here http://bit.ly/lezWcQ there’s a Rule 0: Not all processes can be modeled with #bpmn

    • I would rephrase: Rule 0: Not all processes need to be modeled in #bpmn (doesn’t matter whether they can be).  Someone should figure out if BPMN is turing complete.  If it is, then you can model anything that can be computed.

      However, The BPMSes that implement BPMN *are* turing complete if they include access to a fully-featured programming language or scripting language.  As a result, anything computable I can represent in an implementation that leverages BPMN.  The further you get to the right in Stephen White’s diagram, the less BPMN and the more “other stuff” you need to do the job (the remaining “BPMN” stays pretty abstract or generic).

  • Thanks for the endorsment, Scott.

    It’s a piece of my “BPMN trivia”: rules and patterns so simple that it’s amazing how can people be unaware of them. Yet they can!

    • Sometimes the simplest rules are best, and yet least often followed… :)