Another Good BPMN Example from Anatoly

  • May 25, 2011
  • Scott

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.

Related Posts
  • March 14, 2018
  • Scott

We're heading to IBM's Think! conference next week, and we want to share some of the sessions that jump out to...

  • March 14, 2018
  • Ariana

The Importance of DevOps from BP3 on Vimeo. What is DevOps, what does it mean to customers and how are pe...

  • March 11, 2018
  • Scott

One of the things our engineering team does really well is keep improving the rough edges of any product they ...

  • As @StephenAWhite suggests here 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… 🙂