Now that the BPEL4People specification has finally been released, it is important
to clarify exactly what it covers, and what it doesn't cover.
Let's start with something my fellow ebizQ
writer Michael Dortch said recently in his blog (12 April 2007), following
some comments I made to an earlier post of his:
"I think I now think there are two classes of processes - task-driven
and human-driven. I think I also now think that task-driven processes define
and/or how tasks get done, often by IT systems and resources, while human-driven
processes define and/or describe how people do things. Both are essential to
successful business operations. However, they are very different from one another,
and cannot likely be equally effectively addressed by any common set of processes
or technologies."
Why are BPM experts like Michael making such a dramatic division? Because all
mainstream BPM languages, including graphical notations like BPMN, are based
on carrying out steps in a pre-defined sequence - and this is not what happens
when humans work together.
Turning to BPEL4People, it claims to support patterns for "human interactions."
However, in terms of the above division, these are human interactions in "task-driven"
processes. In other words, what the specification authors mean by "human
interactions" is interactions between humans and systems (H2S) - not interactions
between humans and humans (H2H).
Let's take an example. Suppose a document is escalated by Joe to Jane for approval
- a typical application for BPEL4People. What happens is this. First, Joe tells
the system "this document needs higher approval". Then, the system
works out that Jane should do it, and adds the approval task to her worklist.
Finally, next time Jane accesses her worklist, she sees a new document for approval.
There is no direct interaction between Joe and Jane at all. Everything is mediated
by worklists, or notification managers, the logic behind which is largely set
in stone at the time the processes were originally implemented.
This is an entirely separate issue from dealing with interactions between humans
and humans (H2H). Such work is collaborative, innovative, and adaptive - and
cannot be supported with a language such as BPEL, no matter how it is extended.
Let's take another example. Suppose Joe uncovers a new opportunity with a client.
He knows that to realize the opportunity he will need support from others, including
Jane. He needs to start a new work process to deal with the opportunity - and
this work process will involve a number of people, although at the start the
only person Joe knows he will need is Jane. Others will be included as they
go along - similarly, they will define on-the-fly the various responsibilities,
activities, and deliverables of each person. If you know anything at all about
BPEL4People, it will be immediately obvious that it could never be used to support
such a work process. Rather, H2H interactions are the domain of Human Interaction
Management (HIM).
1
Solution Center Resources
Print this article
Email this article
Talk Back!
Write to Editor
