I did something foolish recently… I criticized someone for an analysis diagram that, I felt, didn’t use “standard” workflow notations.

Granted, the diagram looked very different from the kinds of diagrams that have been coming out of workflow tools, and it definitely wasn’t compliant with UML Activity diagrams, but that still didn’t give me the right to be critical.  How can I tell someone to “follow a standard” when a standard doesn’t exist?

There are some links to an emerging standard, however, that I would like to share.  First off: the Business Process Modeling Notation (BPMN) specification (currently in v1.0 draft status) is an open source initiative to create a common diagramming standard that (a) doesn’t have the limitations of UML as it applies to human collaborative workflow, while (b) provides a good standard for business process modeling that can be mapped to BPEL.


On that site, you would find a good (fairly short) paper comparing BPMN and UML Activity diagrams written by Steven White of IBM.  I heartily recommend this paper.

One problem that I have with diagrammatic standards to date, including BPMN, is the lack of clear determinism in the diagrams themselves.  Unfortunately, I can’t level my criticism in this blog, very easily, because I haven’t quite figured out how to embed an image in the blog!  I will, however, try to explain.

In Code, we can show the beginning of something, and the end of something… we call it scope.

public void myroutine(int param1)

{ // myroutine scope starts here

   if (condition == true)

   {  //if scope starts here

   } //if scope ends here

} // myroutine scope ends here

However, in workflow diagrams, this is not so easy to do.  Workflow diagrams are graphs.  Pathways can snake through a diagram without respect to starting points or ending points.  Process A can branch out to two parallel processes, B and C, which then merge back together in process D.

This looks good in a small excerpt.  However, if we put in semantics, and a real world scenario, we can end up with lots of hidden rules.  For example: let’s say that we have the process described above (A -> (B or C) -> D)… Now, let’s add the workflow pattern of a synchronization… this means that process D cannot begin until both processes B and C are complete.

That’s all well and dandy, but what if B loops back around and merges with A? Would this be legal? 

If B calls A, and when A is done, it is expected to use some form of “return” notation to denote that we should return to B, and then continue on to D?  Is this legal? 

The reality is that there is a scope for the parallel split that occurs when the workflow process branches from A to both B and C.  That is the scope of the join at the end (from B and C down to D).  That scope needs to have properties, to be respected, to make sense.  The engines need to know what processes are related, what processes are required to complete.

The diagramming standards provided don’t enforce that sense.  There are no constraints. 

As a result, it is trivial to take a workflow model, as diagrammed in the BPMN and create a structure that works very well… then add a perfectly legal link and create a structure that works very poorly or not at all.

In software development, we learned this lesson the hard way, in 1968, when Edsgar Dijkstra published a paper titled “Goto Considered Harmful” (see http://www.acm.org/classics/oct95/).  This is one of the key triggers to a series of changes in language innovations that led, ultimately, to structured programming.  I would posit that without the “culture” of questioning language design that arose out of this transformation, the innovations that led to Object Oriented development, and now Aspect Oriented Development, would not have been possible.  Constraints are good.

Of course, I am no expert in UML 2.0 or in BPMN, so it is quite possible that there is a rule, somewhere, that says that my assertion would not be legal.  I have not seen it, and if it exists, I encourage my fine readers to point it out to me. 

My concern is that we have created two standards for workflow notation (BPMN and UML 2.0) that are no different in their fundamental constraints than BASIC and FORTRAN were… they both appear to be at the same level of evolution, where it is still more important to diagram what can be done, than to constrain the modeler from represeting flows in a way that should not be done.

B+ for effort.  C- for results.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “The infancy of workflow diagramming standards”
  1. Hi Richard,

    I don’t disagree with the notion that you want a workflow diagram to be able to illustrate an existing system, no matter how poorly it is designed.

    I am not actually arguing against the ability to model an existing system. In fact, I would posit that nearly all existing systems ARE deterministic… it’s just that our workflow notations are not, which means that we are not COMPELLED to discover the way in which the system actually does work.

    Because most as-is systems work. They may work poorly, but mostly, they work.

    A diagramming structure that forces the modeler to describe the way in which the as-is system is supposed to actually work is useful in discovering the weaknesses in the current system.

    That said, if we say that a link, no matter how "bad", has to be described in the diagram, perhaps we can assign some kind of visual indicator to the fact that the link is "non-compliant" with scope. This would illustrate, visually, where a weakness is in the current flow design, and focus the business users on where a process should be fixed.

Leave a Reply

Your email address will not be published. Required fields are marked *

3 × five =

This site uses Akismet to reduce spam. Learn how your comment data is processed.