Keith Swenson has a nice post on the representation of human choice in BPMN. He objects to the use of a gateway to represent a human decision at the end of a task, like clicking either Approve or Reject. Instead he proposes a new boundary event for this purpose (he suggests the None boundary event, currently not used in BPMN). He raises some good points, and the comment thread generally agrees with him, but on balance I don’t agree. Here’s why.
BPMN constantly has to balance expressiveness and complexity, while maintaining some measure of consistency in the metamodel. Compared with other modeling notations, BPMN is notable for its expressiveness – ability to distinguish in the diagram fine differences in meaning – and has been rightfully criticized for the notation’s resulting complexity. So there is a “cost” to adding any new shape or variant of a shape, such as Keith is proposing. I am not in principle against enlarging the notation; I’ve proposed several additions myself. It’s just that there must be a good reason why the existing notation is inadequate.
Keith is fine with the following:
… but he objects to this:
What’s the difference? To BPMN, there is none. A gateway does not perform work. It has no “performer.” It just directs the flow down this path or that based on evaluating a data expression. Keith is fine with the first one, because the item to be purchased is implicitly a data element of the process. For some reason, however, he does not consider the hiring decision variable to be such an implicit element. I can sympathize with his logic, but I disagree.
The hallmark of what I call “Level 2” modeling is going along with BPMN’s hidden assumptions, of which there are many. A big one is that even for processes that are not automated in a BPMS, the notation acts as if it is. This should not be an issue for Keith, because Fujitsu also assumes a BPMS. Apparently Fujitsu’s process engine does not implement human choice by populating a variable with an enumerated value and testing it in the routing logic, but I would surmise that most BPMS’s do it that way. In any case, this mechanism is a hidden assumption of BPMN., built into the semantics of gateways.
Keith suggests instead something like this, because it more directly connects the user’s decision to the subsequent flow:
Well, it does, but it has other issues. On the consistency side, a boundary event on a task implies the task completed “abnormally.” In fact, here there is no “normal flow” exit from the task, just two exception flows. This is not technically illegal, but I would maintain it is inconsistent with the usual semantics of boundary events on tasks.
This is mostly about methodology and style, which I have come to see is really at the heart of using BPMN effectively. (Hence, my upcoming book, BPMN Method and Style…) The letter of the law, as stated in the BPMN spec, allows inconsistency in the notation, but it is better if you apply principles consistently throughout.
In my method and style, a gateway following a task that completes normally is usually testing the end state of the task, as in the human decision example. But it could be simply testing a property of the instance, as in the first example. A boundary event on a task, whether message, timer, or error, means the task was interrupted before it completed normally. That is, it does not imply a normal end state of the task. That is not what Keith intends in his proposal, and thus I believe it is inconsistent with the rest of BPMN.
Even if you still like the boundary event for this, is a new None boundary event the way to go? BPMN 2.0 provides a new event type, Escalation, which on a user task boundary implies an ad hoc user decision in the middle of a task. It is normally non-interrupting, meaning the task continues in parallel with the exception flow, but it could be drawn as interrupting, and I suppose one could interpret this as a “human decision” at the end of the task. But to me at least, it implies an exception, not normal completion. So I just don’t think a boundary event is consistent with the rest of BPMN if the intent is to describe one of N possible branches that could be taken following normal completion of the task.
Bruce-
I think there were really at least two elements in Keith’s post:
1. the idea of using declarations to identify important choices
2. some criticisms and suggestions for how to model human choice better
I think he identifies a legitimate shortcoming in BPMN – that the decision points don’t, by definition, clearly indicate whether the choice is a result of the human activity immediately preceding, or the result of some other piece of data completely unrelated to that human activity.
That can certainly be addressed by convention – for example, I try to use very clearly labeled decision points that are obviously related to the outcome of the previous activity – but this relies on good naming practices. How many times do you see poorly named decision points and poorly labeled outgoing lines/choices? 🙂
Still, it seems to me you could have the same problem with Keith’s suggested changes – because, while they would allow you to signify, potentially, that the output / choice is due to the human activity, I can’t see how it prevents you from abusing it to make it based on some other piece of data – and then you’re right back to convention…
In the early days of Teamworks the “service layer” (below the BPMN layer) allowed for a combination of exiting from a nested service and a decision gateway at the same time. It seemed a bit odd at first, but it was pretty useful for keeping the diagrams efficient. However, I noticed that that feature has become much less used since people have become more comfortable with the BPMN normal approach of one outgoing line from each activity.
What’s the best way to represent Keith’s idea and keep consistent with BPMN? Got me. But if there isn’t going to be a notational support for it we’ll at the least have to keep education the BPM community about how to represent their human choices clearly.
I am amazed at you guys … I thought you knew this stuff. Isnt Keith talking about what is already essentially in the spec in the form of Conditional Sequence Flow.
Quoting here from p98 of the 1.1 Spec
“A Sequence Flow MAY have a conditional expression attribute, depending on its source object. This means that the condition expression must be evaluated before a Token can be generated and then leave the source object to traverse the Flow. The conditions are usually associated with Decision Gateways, but can also be used with
activities.
° If the source of the Sequence Flow is an activity, rather than Gateway, then a Conditional Marker, shaped as a ?minidiamond,?
MUST be used at the beginning of the Sequence Flow (see Figure 10.2).
The diamond shape is used to relate the behavior to a Gateway (also a diamond) that controls the flow within a Process.
More information about how conditional Sequence Flow are used can be found in ?Splitting Flow? on page 111.” There is more detail … but go check it out.
Isnt that exactly what Keith has been suggesting. Isn’t that also what Scott was suggested happened in Twks.
I am answering here since the conversation seems to have moved here. And I was amazed that nobody had spotted that yet in Keith’s post (Bruce I sort of assumed you would point that facility out … but clearly it is not in your usual modeling course ;-/)
Thank you, Brother Derek, for chapter and verse, but I’m afraid your bit of scripture does nothing to ease Keith’s suffering. Conditional sequence flow out of an activity is exactly the same as a gateway following the activity. An OR-gateway, actually, rather than XOR, because the conditions are independent not exclusive. (Students in my training all know that, by the way…)
The condition on each sequence flow is a boolean expression of process data – i.e. variables or properties. So we are back to where we started: BPMN imposes the hidden assumption that human choice populates a variable that can be tested by a gateway (or by conditional sequence flow, if that makes you happier, Derek)… rather than considering it an event.
Scott, your comment is more to the point. Expressiveness in the notation ultimately comes down to convention, or as I call it, method and style. I like the terms method and style because it implies a personal choice (combined with correctness, best practice, and good taste) rather than by recommendations in the spec for general usage.
The heart of the issue is this: When BPMN is used for “modeling”, as opposed to executable design, the modeler may want to ignore distinctions important only for execution, and may want to express other distinctions that the process engine doesn’t care about. Keith’s situation is a variant on the second: He wants to express a distinction that his process engine cares about but BPMN’s assumed process engine doesn’t care about.
You ask, “BPMN assumes a particular type of process engine?” And the answer is yes, just like BPEL does. BPMN 2.0 semantics are quite similar to BPEL (including BPEL4People), without the block structure limitations. And this isn’t new to BPMN. Remember it started out as the design language for BPML, which is also similar to BPEL.
If you want to show human choice as an event, the new Escalation event will do. I once suggested a User Action event (on my wish list posts), and even though I have since withdrawn my request (Escalation I think makes it unnecessary), Steve White still likes it and it may get added anyway. In Keith’s situation, both Escalation and User Action suffer from the 2 problems I mentioned in my post: 1. Boundary event implies an “exception” and abnormal completion, not a human choice at normal completion of the task. 2. An activity with no normal flow out is considered an implicit end node; I believe that without a third exit from the task – a dummy flow to an end event – the diagram is technically illegal in BPMN. By convention or “style” one could choose to ignore these problems. I think the cure is worse than the disease, however.
Bruce, Good post. I think you have represented my original post fairly, and I can respect your position on it.
I only wanted to draw your attention to the circular logic you employed. Of course what I drew was illegal, because there is no legal way in BPMN to draw this concept. If course is it not “consistent” for the same reason: consistency is based on precedence and there is no precedence for a human choice in BPMN. When one suggests a new notation is will be by nature inconsistent with what existed before. But don’t get wrapped around that point: if we can find a MORE consistent way to represent this I would certainly consider it. I will take a look at the escalation event to see if that might fit the bill.
Events on the edge do not necessarily represent abnormal completions: there are many cases of activities that are “normally” ended by timeouts, some are even mentioned in the BPMN spec (please see BPMN 1-0 spec figure 10.39).
I disagree that this is “engine specific” modeling. I believe a very fundamental part of drawing a “true” business process diagram is to draw the salient decisions that must be made by a person. If I describe a business process in prose, I might say “The editor decides to approve or reject the document”. I don’t say “The editor stores the value ‘approve’ or ‘reject’ into a variable which is later used for branching.” I know this example is ridiculous, but my point is that the closer we can model to actual language we use, the more this makes sense to the users. The “store in a variable, and later test the variable” is a standard software engineering technique, but something not familiar to non technically trained business users.
The Fujitsu Interstage BPM certainly offers both modeling patterns. We advice people that they can use both, one, or the other. Some choose to exclusively use the gateway, but most find this direct representation of the decision to be made to be a very powerful technique that is both clear in meaning and functional.
Thanks for responding to Derek. He does not seem to see that the conditions on an arrow provide “Inclusive OR” semantics, but as you correctly point out, I am looking for “Exclusive OR” semantics — quite a different thing. Furthermore, a condition can test any variable, while a “choice” is specifically the decision made by the assignee.
A lot of people believe that is simply not possible to create a executable business process without programming. One of the reasons is that most approaches require variables and variable manipulation for even the simplest of decisions. Imagine you could represent decisions without having to use variables! There are a number of simple processes (document approval for instance) that can be modeled and executed without programming. It is very powerful.
Only time will tell whether it is “justified” to have this notation. That will be determined by whether users demand this way of representing choice or not. For now, I am happy that Interstage BPM has a powerful way of representing choice that apparently almost no other product has.
Keith
You raised an interesting question: exactly how could users express their preferences? By voting at OMG website, supposing they provided it some day? I’m afraid BPMN would have “design by crowd” label instead of current “design by committee”. By bringing money to particular vendor? There are too many of them for this to work.
=AB
Anatoly, good point, design by crowd would not seem to work. What I am hoping to do is to encourage debate on these subject among the key people. I know from experience that the people that dedicate themselves to driving such standards really do want to produce the best standard. “Best” depends upon their on experience, and upon their vision for how the thing will be used. My only hope is to encourage discussion of the important subjects to get the key features into the consciousness of the “experts” designing the standard.
Success of a standard depends upon fitness of the entire package. Sometimes standards with great ideas fail because the entire package is somehow unsuitable. I think back to X.400 which was clearly a superior standard for exchange of email, but SMTP became the dominant standard anyway. I also think to WSDL 2.0 which has essentially not been adopted while most software kits still include support for WSDL 1.1.
Keith (re your first comment)… Well said. I can’t disagree with anything you say, although for me the semantic distinction from the data expression approach is too small to warrant the change. It is too late to get into the 2.0 submission, but here is one possible proposal for your human choice semantics, using a variant of conditional sequence flow, not boundary event. (Boundary event would require semantics on subprocesses, service task, etc. Don’t go there…) Currently sequence flow has a child called conditionExpression. You could either create another child humanChoice (or whatever) and give it a different symbol on the tail, to distinguish it from conditional sequence flow. I personally doubt you could push that through, but you never know. Alternatively you could try to promote a convention, perhaps via WfMC. For example, you could specify some format for conditionExpression values to signify human choice – that would be entirely within the spec – and in addition you could suggest a new sequence flow tail notation to distinguish from conditional sequence flow, signifying exclusive human choice semantics. The latter would be outside the BPMN spec but you could probably get XPDL to support and then let the marketplace decide. If there is enough demand for it, that would be the most likely route, in my view.
If the empty events are leading to a consistency conflict I suggest to follow the Bruce´s proposal for another type of sequence flow for showing a user decision and to support process engines to offer a button or context menue entry in respect to the modeled lable for this flow.