Virtually all the modeling notations and tools I know, including BPMN, as well as executable process design tools (both workflow-style and BPEL-based) follow the activity flow paradigm, i.e. like a flowchart or UML activity diagram, in which the flow is generally in one direction. Moreover, to create a valid executable process diagram, many (including the BPEL language itself) exclude arbitrarily looping back to previous steps in the diagram.
But for many real-world processes, particularly those characterized as “event-driven”, that no-loopback rule doesn’t work. They are better modeled as “business state machines,” similar to a UML statechart diagram. Nodes in the diagram are not process activities but states of the process instance. In each state, the process listens for various events, which trigger a specified action (process activity) and transition to a new state (or back to the same state). The triggering can also be conditioned by a rule. This event-condition-action (ECA) paradigm is the hallmark of event-driven processes. UML provides a diagram to let system architects model them, but I don’t know of any tools for process analysts to model them. Maybe the concept is too “complicated”?
Very few BPMSs support business state machines natively in their design tools. In Vitria BusinessWare, it’s actually the default. In IBM WebSphere BPM Suite, it’s provided as an alternative design tool in addition to their conventional BPEL editor, although it has no corresponding modeling tool in WebSphere Business Modeler. The interesting thing about the IBM implementation is that the business state machine is expressed as BPEL. I always wondered how that was done, but an article on DeveloperWorks provides the clue, which was subsequently verified to me by Matthias Kloppmann, one of the architects of WebSphere BPMS.
States are represented in BPEL as variables. Each state can have predefined exit and entry actions. Between the start state and the end state the BPEL is a While loop containing a giant Pick, with a separate Pick branch for each event in the state diagram. Each branch performs the following sequence of steps:
- Validate the event for the current state
- Evaluate the condition if any
- If transition to a new state, perform the exit action of the old state
- Perform the transition action specified in the state diagram
- Perform the entry action of the new state
- Update the state variable
For any arbitrary state diagram this works in BPEL without violating the rules. If you viewed the BPEL in a normal BPEL editor it would be much less clear what is going on in the process. It’s much clearer in the state diagram.
It seems to me event-driven processes are not too complicated for process analysts, and would benefit from a business-oriented modeling tool. (Actually IBM’s business state machine editor doesn’t seem too complicated, but it’s buried inside a tool that probably is.) BSMs and conventional activity flows can even be combined in an overall process description. Screenflows defining a single “user task” come to mind, for example. For now the BPMN world probably has higher priorities than this, but extending modeling to event-driven processes or process fragments seems like a good idea.
I can remember creating arbitrary loopbacks using this same method in FileNet’s Visual WorkFlo back in the late 1990’s: basically, a while loop with an embedded case statement.
The problem with this modelling “trick” is that it makes the process virturally non-understandable to the average business user who might have to interact with the process in some way. As you say, viewed in a normal editor, it is much less clear what’s going on, but I don’t think that state diagrams are a good representation for end users either. If a BPMS provides a runtime view of the process to the user with a “you are here” sort of functionality, or if you provide business managers with a graphical process governance tool, they’ll be totally confused by this sort of process structure.
I think that the thing about loop backs is that markup languages just do not really lend themselves to looping. Usually marking languages are hierarchial and do not fit into a looping structure. Meanwhile other types of BPMS systems which are petri net based have been built with looping mechanisms, but they do not have a largely adopted standard for the exhange of workflow/BPM design information such as XPDL.