BPMN too Complex?

Scott Francis
Next Post
Previous Post
I’m with Stephen White on this one:
The process above is not an extremely complex or hard to understand BPMN Process, but it is a perfectly valid one. BPMN was fully intended to support such modeling. So what is the problem? Why are there complaints about BPMN?
Look, BPMN has more complexity than it needs to have for many uses, and less complexity than it needs for other uses, but I’m with him on this one. Is it too complex to use for simpler models? No. Do these simpler processes require too complex a BPMN model to be understandable? No, they do not. To me, the focus on complexity is a bit off.  The issue is expressiveness.  I don’t think that BPMN is too complex for the expressiveness it provides.  What makes one tool better than another has a lot to do with its expressiveness. Stephen has it right when he says “The burden, then, is not on BPMN as a specification, it is on companies that develop process modeling tools or methodologies to help their users effectively create business processes – using the BPMN language.”  (Of course, it would help if the spec writers don’t get too carried away, and actually take a break for a while to see how BPMN2 shakes out before starting on a new version). He has it right because often these simpler conceptual models evolve into more complex executable models (or just more detailed models), and it is reasonable that the same people who understood the simpler model want to be able to see and grasp how the more complex versions relate to the original simple model.  As we’ve commented before, most business users can get by on just a fraction of the BPMN language.  

Tags:

  • I agree with *most* of it, but there are cases where there is to much complexity. The flow objects are good, no remarks there, but the dataobjects? Waaaayyyyy to much BPEL/WSDL/YetAnotherAbstractionLayer in there, as wel as in the assignments. Those are the areas where you e.g. see that Activiti is providing ‘simplified’ ways of describing things besides supporting the ‘full version’.

    • You’re right, mostly when ppl discuss BPMN complexity they’re focused not as much on flow, but on data objects (et al), or the XML itself.  And, this is exactly where an enterprising vendor or product group (Activiti, in this instance ;)  can add a lot of value to the experience by providing a user experience that is simpler and just as expressive, while supporting the more complicated technical requirements.

      Even so – these levels of complexity aren’t necessary if you’re only documenting process vs. implementing.  Often the complexity arguments are presented in the context of a business person – but what the business needs to interact with in describing a process is typically the flow elements – where they can pick and choose from a smaller set of things to get the job done. 

      •  Agreed… there is a difference between documenting, implementing (making executable on a BPMS in this case). There is a usecase where it is not at all clear to people how to ‘document’ it. It is the ‘how-to-cancel-a-task-for-personB-by-personA-if-personA-found-out-what-he-did-in-a-previous-task-was-not-ok-and-personB-should-not-be-allowed-to-start-on-his-task’. The cancel event only works on transacted subprocesses, so either a signal or message should be used, This ‘simple’ and common usecase is hard to model if you do not know some details. Hope somebody takes a stab at this and blogs about it… (Yes, should do this myself, but lack of time)

      • Very good point – though I don’t think it is unreasonable for a business user to simply write a descriptive note if they run into something they don’t know how to diagram in BPMN.  But that particular scenario to me is something you really want to document when you’re documenting for the purpose of implementation, rather than when you’re documenting for the purpose of understanding…