Books on process modeling generally warn against getting bogged down in detail. They tend to recommend a top-down methodology that starts with a big-picture end-to-end view and drills down just as far as you need for your modeling purpose. In preparing my Process Modeling with BPMN training I stumbled across a pretty good recipe for how to do this in Worflow Modeling by Sharp and McDermott – one of the only books on the topic I can recommend. My training overlaps slightly with the information-gathering phase that Sharp and McDermott talk about, but mainly focuses on how to put that knowledge into BPMN, so you can share it, run it through a simulation engine, or even generate an executable implementation.
Subprocesses are a very handy concept in BPMN. Besides providing a natural way to draw a condensed top-down view with drill-down to any level of detail, BPMN subprocesses also determine the boundaries of when an event can be received – a change to an order in process, for example. But I find that one really basic property of BPMN subprocesses gets in the way of top-down modeling, as described by Sharp and McDermott, or anyone else for that matter. That’s the basic fact that a subprocess in BPMN has one entry point and one exit point. Let me illustrate the problem.
Here is a familar diagram of an order handling process in BPMN – three subprocesses in a sequential flow. But when you drill down, you typically want to say that if Check Credit fails, you terminate the order. Something like this:
Unfortunately the diagram above is not legal in BPMN! A sequence flow cannot cross a subprocess boundary. Hmmm. Let’s look at the options. I’m not crazy about any of them, but I’m hoping BPMS Watch readers will help me recommend one as the “best”.
The first option, shown above, is to separate the top-level subprocesses with gateways. But to show the semantics you have to use a task to set the end state of the subprocess that is tested in the gateway. That means business analysts have to think like programmers. I don’t like it.
The second option, shown above, is to use Link events. You’ve never heard of Link events? They’re in the spec. A Link End event is a GoTo to a Link Start event or Link Intermediate event with matching LinkId in another subprocess of the same parent process. That’s what we have here. In fact, each of the top-level subprocesses can have a Link End that jumps to the End subprocess to kill the order. So I kind of like it, except that I heard a talk by Steve White who said OMG didn’t like it and they were going to replace it with something else in BPMN 1.1. The other thing is that my Process Modeler tool’s simulation engine doesn’t handle it today. But if you all like this, maybe they’ll put that in.
The third option uses an Error event throw-and-catch. Programmers get it, but I’m not sure business analysts would. Besides, I don’t think of bad credit as an error, but maybe that’s just me. So if the credit is bad, an Error Intermediate event in normal flow throws the error, and the attached Error Intermediate event catches the error, terminates the subprocess and triggers the exception flow, which terminates the order process. So that works, but I don’t like the idea of asking analysts to deal with this throw-catch business. Also, I’m not sure my simulation engine works with it yet, but again… they might, if this is the best way to do it.
So what do you think? Don’t be shy, all comments welcome.
My vote is for one not included. The Cancel Intermediate Event.
From the spec:
This type of Intermediate Event is used within a Transaction Sub-Process. This type of Event MUST be attached to the boundary of a Sub-Process. It SHALL be triggered if a Cancel End Event is reached within the Transaction Sub-Process. It
also SHALL be triggered if a Transaction Protocol ?Cancel? message has been received while the Transaction is being performed.
Semantically I think it would look like the third option, since it is an Intermediate Event attached to the Check Credit (Transaction) Sub-process.
Depending on what else may have happened, a Compensation Intermediate Event may be appropriate too (to update the Order with credit rejection status information and to inform the customer).
Page 60 BPMN spec has a nice graphic which touches on the use of both of these Intermediate Events in the context of a somewhat similar business scenario.
I would have included an xor gateway after “check credit” with a terminate end event as on of the options. The xor gateway here would be perceived as a passive construct, just splitting the flow dependent on a decision that was taken “inside” check credit.
The BPMN spec is not fully clear on the use of gateways; some of the high level examples use gateways as active objects. I usually prefer to think of them as passive.
Steinar
I think this sub-proces problem is an argument against gateways as they are defined in BPMN 1.0 spec. The trouble with BPMN gateways is, that the specification makes no difference between join gateway and split gateway, which in my opinion are two totally different concepts.
There are generally no problems with the join gateways: The flow can continue in just one way. The decision if it should continue is easy to make based on existence or non-existence of incoming events and/or flows. I also think that all of these join gateways can be of a predefined type AND, OR or XOR – no need for custom gateways.
The split gateways are quite the contrary. The predefined OR and XOR just by themselves make no sense (the AND gateway makes sense, but is a simple “start-more-parallel-flows-no-logic-needed” gateway). So most of the split gateways are custom ones with condition on them (such as “Bad credit?”).
The join gateways are used to express if a process should start. This is a process-external decision which the process being started does not need to even know about.
The split gateways on the other hand express where should the process continue to. This is a process-internal decision which is always (except for the dumb AND gateway) taken in the previous process. The gateway itself just visually emphasize that in the previous process a decision has to be taken. To visually move the fork outside of the previous process, the decision is saved in some sort of state variable and than used by the gateway. I think this is a very strange concept from the beginning – moving some parts of process outside just to emphasize it.
So in my opinion the first invalid BPMN diagram is the one which is consistent with the reality. The decision is process-internal and therefore it is just right to put it inside. The fact that it is not legal BPMN is a sad proof that there is something wrong with BPMN itself.
None of the suggested workarounds are perfect. The last two will only work if they replace a two way split gateway. Splitting to 5 possible directions and their 32 possible combinations would be near impossible to express with exceptions, cancel and link events so that any human being could read it.
I would choose the first suggested workaround if I had too. However I think it only explicitly models what I just described BPMN does implicitly and wrong – artificially moves the decision out of process by storing the decision in a state variable ( named “bad credit” in this example). This introduces redundancy (this time explicit, not implicit as in normal BPMN models without sub-processes – the “Credit OK?” and “Bad credit?” gateways model the same realy decision) and complexity which makes reading and understanding the diagram much harder.
I’m quite new to BPMN so I might be totally wrong with this. I would appreciate if somebody could prove me wrong so that I could use BPMN happily again.
Thanks for the responses so far. Vernon, I’m counting you as a vote for the Error event. I have a problem with Cancel, since this isn’t really a transactional subprocess; the goal is not to compensate activities inside the subprocess but abort the parent process. Also Cancel is supposed to be linked to a transaction manager such as WS-Transaction. Yeah, as if anyone has implemented that one. But that’s ok, I’m counting you as one vote for the intermediate event.
Steinar, I’m counting yours as a vote for the gateway. I should have shown the end event after the gateway. Any end event will do. In this case Terminate would not make any difference, since nothing is happening in parallel that needs to be killed. But I agree if there were other activities concurrent with the gateway, Terminate would be appropriate.
Vaclav, I agree with your comment re vagueness in the spec if gateway has multiple sequence flows in and and multiple out — in fact I previously posted that was illegal but a reader wrote in to say it is allowed by the spec. In all other cases, it’s pretty obvious what is a decision and what is a merge. My simulation engine has no problem with that at all. So I’m going to count your vote as against how BPMN has defined subprocesses. A legitimate point, but not too helpful to my immediate concerns.
Keep the comments coming in. You’re helping me think about this.
–Bruce
Hi Bruce,
If the model is intended to subject matter experts (and not to app. developers), I would definitely go for option 1, but simplified. Do we really need to introduce a variable “bad credit”? I don’t think so. We could just skip task B if the “credit OK” condition evaluates to ‘no’. Then, in the second gateway, instead of basing the condition on variable ‘bad credit’, we could just write again ‘credit OK?’ In other words, we could use the same condition in both gateways. Of course, in this case we need to invert the yes and the no in the second gateway so that “Check Stock” and “Fulfill Order” are only performed if “credit OK” evaluates to yes.
The need for an explicit variable (‘bad credit’) only surfaces at the implementation level. Let me here consider the YAWL system as a target implementation platform, because anyway standard BPEL does not have sub-processes. If you write down this process model in YAWL, you would indeed need to introduce a variable ‘bad credit’ in YAWL (or a similar variable); then, somewhere in sub-process “Check Credit’ you need to set this variable, so that it can be used outside the sub-process. But this is an implementation detail, of little value at the business analysis level.
We should remember that at the end of the day, BPMN is a language for high-level process modeling. At a more detailed level, we would use something like YAWL or BPEL, and this is where the details related to variable manipulation would surface out.
The third option is also OK, but I agree that “error handling” is not something every user of BPMN will be familiar with. Also, I agree with you that “not credit OK” is not an error, it’s more an “exception”, but unfortunately, the BPMN spec calls an “error” something that should be called an “exception”.
Marlon,
Your argument is compelling. I agree, insert the gateways, forget the variuble – ignored in simulation anyway (at least in my tool). For business analysts it’s the most understandable. Thanks for the insight.
I quite like Marlon’s solution. It’s the most elegant of all suggestions.
Still it’s not perfect as it really requires repeating stuff. I believe repetition in any model makes it much harder to maintain and keep consistent. Maybe not an issue in this simple example, but surely is in more complex ones.
Imagine the same example but with sub-sub-sub-processes in separated diagrams and many more conditions. Than one business analyst (maybe a different one than the original author!) one day decides to change “Credit OK?” condition to “Credit OK or a long time customer?” condition. He really has to change all the copy conditions, which he might not know about. If he forgets only one of them than some customers may be billed even if the item is out of stock or other weird disasters may happen.
So this solution might be the most elegant for Bruce’s training, but does not scale to real world. I’m sorry for posting another negative comment without a solution suggestion, but the discusion has not yet pleased my idealistic modeling point of view.
Vaclav,
I don’t think Marlon would claim his solution was ‘elegant’, nor would I. Nor scalable, either, in the way you mean. I think the overriding test was understandability to business people, where it certainly is best of the lot. For elegance and scalability, I think the Error event solution is best, where ‘Error’ is interpreted as a general-purpose exception condition, business or technical. But elegance is wasted on users who don’t know what you’re talking about.
Hi All,
First of All, happy New Year 2007!
I wold like to say it depends on how you want to design your process. Though I really don’t like the Li nk event solution which is for me avoiding the problem and not bringing a solution!
The question here is where do I want to have the decision taken and how do I want my main process to behave in case of a ‘No Credit’ situation.
The control is made within the subprocess ‘Check Credit’ but I can say that either the decision is made within the subprocess or within my main process.
If the flow inside my sub process depends on that decision then the decision is definitely inside my subprocess (I have a gateway designed in my subprocess that will split the flow in 2). And now I have to decide how that subprocess will communicate that decision to my Main process. Two possiblities here, from the main process point of view I may consider this as an ‘Error’ and here I am in the situation of the Error IE or I want my main process to consider it as another normal flow (Fits with Proposal 1 which I will comment later).
Now, you can decide that the flow of your sub process is not constrained by the decision. This means I have no gateway inside my sub process but in the end, the communication with the main process is solved the sameway.
Regarding the proposal 1, i would say that the need of an explicit task to set some values into some variables depends on the nature of my sub-process. If my subprocess in an embedded one than I don’t see the need to have such a task as information are supposed to be shared between the two processes. If my sub process is an independant one, than such a task must explicitily be designed as I need to explicitly design which information will be exchanged by the 2 processes.
Still on Proposal 1, why can’t we just have 2 different end events in my sub process? It would make it clear for Business people that I have two ways to end my sub process and that none of the ways are considered as error.
On Solution 3 (Error Event) why can’t I draw an Error End event in place of an Error IE linked to the End event? Does that mean The process is supposed to come back here once the error is solved?
Hope this helps,
Thanks and have a nice day,
Patrice
I am just a newbie, but I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers’ compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is ” not sure’ whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths (OR). Our discovery of analyzing the business requirements seems related to the discussion of the credit check scenario above. The business users understand gateways so option 1 seems like the best fit for us as the users have trouble with option 2 or option 3. Bruce, any chance you could post the final diagram you are leaning toward?
Thanks.
Bruce M.
[…] Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN. Since that original post I’ve worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc). As a reminder that our BPMN training is now available from bpmessentials.com, it’s worth reprinting his comment here and showing the solution. He writes: … I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers’ compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is ” not sure’ whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths…. […]
I like the exception handling. In my case it is a simple plausible or not question. But the problem is, that it occurs in a subprocess within a subprocess. In the case of not plausible the flow should jump out to the parent-parent-process, that is but two levels higher. I don’t know, how this can be achieved with an error intermediate event.
With a link-event, yes.
I know that this thread is now quite old, but comparing this to Bruce’s book it looks like its gone with the gateway option? I have to admit favouring this option as well from the point of view of a business user understanding it.
I also prefer it based on (a definition I read somewhere but can’t recall) the fact that the gateway in this instance is evaluating process data to determine the path to take. Business people will understand the input and output concept demonstrated by the gateway more readily than they may do the error event. I also recall in the book that Bruce states that gateways are best used to model business exceptions versus the use of error events to denote service task exceptions (I hope I’ve paraphrased that correctly, but apologies if I haven’t).