VOSibilities

This week, Michael Rowley presented “Using requirements gathering tools with a BPMS,” an interesting look at the relationship — and the possibilities — of using model-based BPMSs with requirements gathering tools.

We have posted three formats of the webinar replay. First is an iPod-formatted .m4v file. Also, a Flash file that can be played from the blog and/or downloaded. Finally, we have included a Windows Media 9-encoded .wmv file.

Please join us every week at noon ET, 9am PT and 17:00 GMT for CTO Tuesdays.

 CTO Tuesday #10 Using requirements gathering tools with a BPMS [40:59m]: Download (155)

 

 CTO Tuesday #10 Using requirements gathering tools with a BPMS [41:00m]: Play Now | Play in Popup | Download (128)
 CTO Tuesday #10 Using requirements gathering tools with a BPMS [41:01m]: Download (131)

Bruce Silver has written an excellent post about the current state of BPM standards (with an emphasis on the “M” being Modeling, rather than Management). I am going to nitpick a little, however.

Bruce writes:

Because BPEL is more “technical” than BPMN, it is favored by developers who find nothing more annoying than business-types wanting to “collaborate” on implementation.

I disagree that developers don’t want to collaborate with their business-minded colleagues. This is the stereotype, of course, but in my experience it really hasn’t been true. The real question is whether or not business analysts and developers need to work on same model. Neither the developer nor the business analyst really wants this since they have different needs.

Bruce talks about one of these differences: business people using unstructured graph-oriented control flow vs. the structured control flow favored by developers. It’s clear why these different users would need different ways to diagram control flow.

So these difference needs dictate different representations. With the unstructured control flow, it is pretty easy to get into trouble (where “trouble” is defined as something that’s unclear at execution time) . For example, some modelers prefer to use conditional sequence flow (small diamonds on outbound transitions) rather than XOR gateways. Kieth Swenson has a good example and a couple blog posts (here and here) that discuss this. Unfortunately, with the current semantics, it is easy to get into trouble.

Think about this process model:

The business analysts might not think very hard about whether the thing could be red and blue, so at runtime it turns out that both paths could be taken and then you would end up with two simultaneous executions of “D”. That is legal, but probably not what was desired and difficult to debug.

It is the transition from unstructured to structured — as the model is handed from the business analyst to the developer — that causes these issues to surface. The developer will still use something that uses the BPMN notation, but with limitations that basically make it look structured. So yes, round trip is hurt. The developer doesn’t hand back to the modeler the same picture. It has been unwound a bit. This is a less comfortable style for the business analyst, but it’s certainly still understandable.

I don’t think Bruce disagrees with most of this thinking, because what he concludes is exactly in line with my thinking:

We need to recognize that standards for process modeling and process execution have different purposes and benefits. They should be linked, but with proper attention to those differences.

Rich Seeley has written a very interesting article about how visual modeling of business processes enables IT to work more closely with business users. Rich also points out how ActiveVOS has achieved great results for Fastenal.