Forgot to say, in my posting on BPM Focus, see if you can spot the error (in one of my models). To date, nobody has highlighted it (surprising given the fact that so many people have ticked through this book looking for errors), although I spotted the flaw when reworking the chapter recently for a deliverable.

It would be nice to see this not only in Intalio but other vendors as well. It’s for the good of the BPM industry. Without good implementation of the BPMN spec at an executable level, it’s often harder to do BPM than it is to just code it yourself. Some vendors (not calling out anyone specific here) only support task, 3 gateways, and maybe 2 or 3 events. This is only a subset of the BPMN 1.0 specification. I think that this is bad for the industry to only have partial coverage. Even worse is when a vendor allows you to use the symbol in a way that is against the design of the BPMN specification.

Before I started with Intalio I worked for another BPM vendor that was in the category of partial implementation and using symbols the wrong way. The end result is that the customers get locked into a vendor specific way of thinking and they had great difficulty migrating to another system. So when I started with Intalio it has been my quest to push for as much BPMN compliance as possible. Unfortunately I’m not the person making the decisions for product direction, so all I can do is campaign for features like signal event. When people take an interest in something like this and make a case for it, it gives me more support to push Intalio to get it done.

So poke away…

Also, as an update, the Intalio folks have the signal events on the radar as a feature candidate for version 6.1 or 6.2. There are many features that are candidates for upcoming releases, so it’s hard to put a timeline on exactly when signals will be available.

First I have to write the disclaimer that I am currently employed by Intalio. However this my personal site that I try to keep things straight to the spec and leave out anything vendor specific. My views on process modeling extend far beyond what any vendor on the market currently does. In many cases I have to work around this on my projects just like everyone else. But I can tell you that there are many patterns in BPMN that come pretty close to the signal event. For example, try using the message event on a subprocess border. In many cases I’ve found this to be a suitable substitution. Sometimes the answer is to use various levels of error events with intermediate catching events. But of course, the BPMN signal event makes life a lot easier.

While keeping my vendor-neutral hat on, might I suggest that if you want a feature from a vendor maybe you should help make a case for it. I seem to recall some of your previous postings that made some nice points. Why not make a case for Signal Event?

Now if I may for a moment put my Intalio hat on, I can only say that “its on the drawing board but there is no specific timeline”. Intalio is driven by customer demand.

With that being said, and taking the Intalio hat back off again, the problem here with the signal event is that people don’t understand it and don’t understand the need for it. Therefore they don’t know how to ask for it. Instead they ask the vendor how to make it work while ignoring the bigger problem that we in the process modeling industry need something like this. In fact, I’ve found that most BPM professionals don’t understand signals, compensation, and cancellations correctly (more on transactions in an upcoming post). So if we, the so-called experts, don’t understand it, how can you blame the vendor for not implementing it? My gut feeling tells me that nobody is asking for it by name.

David