Comments on: BPEL4People Revisited

By: Francis Ip

Francis Ip — Wed, 01 Mar 2006 14:36:30 +0000

Retro-fitting human elements into BPMS are just another IT legacy that persists when IT mindset prevails. As long as users are always outside the boundary of a system, that is what one would expect. Not everything can be or should be automated. Technologies are just tools that assist human beings to perform work more efficiently. It would be interesting to see how the BPEL4People will support “job shop” and “flow shop” scheduling for people. There are several classes of scheduling problems that are intractable. In essence, no optimal solution exists for those problems. Priority of work keeps on changing when unforeseen events arise. Moreover, many people don’t work with computers most of the time.

By: Ismael Ghalimi

Ismael Ghalimi — Tue, 28 Feb 2006 19:45:22 +0000

Tom,

Thanks for the feedback! Much appreciated!

By: Tom Welsh

Tom Welsh — Tue, 28 Feb 2006 11:43:56 +0000

I’m surprised, given their previous record, that they didn’t call it “BPEL4ppl”. Seriously, thanks for the great blog and all the useful articles â€” I’m finding it most helpful, as I’m sure are many others.

By: Managing knowledge processes

Managing knowledge processes — Thu, 16 Feb 2006 11:37:08 +0000

BPEL4People revisited…

Interesting thought about the BPEL4People (an extension to BPEL2.0 proposed by SAP and IBM) by Bruce Silver in ITRedux.BPEL4People revisited and the white paper:BPEL4People…

By: Steinar Carlsen

Steinar Carlsen — Thu, 16 Feb 2006 08:29:21 +0000

I think something like BPEL4People definitely is needed, but it confuses me that the starting point is at the BPEL level â€” actually I think we also need something like BPMN4People. I have used BPMN a lot over the last year, and it is not very good at describing user-driven processes and human decisions.

Computas has delivered process support solutions to thousands of users in (primarily) the public sector in Norway over the last 10-15 years. Our solutions so far have been based on our own FrameSolutions framework. We market these solutions as “knowledge support systems” based on human-driven processes, as an “offering” to the user.

In these solutions, we often need to embed functionality similar to a “process cockpit” where users are served a set of “process fragments” of which some are mandatory, some are repeatable, some are optional etc. A consequence of the user starting, or performing, one of these fragments might be the starting of other processes and changes to mandatory, repeatable, conditional properties of other fragments.

One way of bringing this into BPMN could be to extend the notation to cover more aspects of adhoc processes, i.e. allowing to describe some constraints wrt. to the composition of an adhoc subprocess.

With the BPEL-focus, adhoc processes tend to become uninteresting since they cannot be automated, but in the real world they often are the most interesting and valuable processes â€” and they can be supported!