RE: Why workflow is NOT just a Pi-process

We may also want to keep Phil Wainewright in the loop, he is keeping track
of the debate and already wrote a very good summary:

http://www.looselycoupled.com/blog/2003_11_23_lc.htm#107015401001130588

This article could also be titled: "why pi does not matter..." 


2. I think what we meant to imply by using the title "Workflow is just a Pi
process" is that there is something foundational about the Pi concepts that
allow us to model higher level processes, including workflow-like processes.
We could have equally written papers with the following
titles:

ERP is just a Pi process
SCM is just a Pi process
B2B is just a Pi process
Adding Up is just a Pi process
Managing A List is just a Pi process
EAI is just a Pi process
Data is just a Pi process
etc

<JJ>I think we should define what "models" means. If it means express all
the semantics of the things listed above as a pi-process, Intalio's N3
designer tool might be falling a bit short.

For instance, I understand that a PO business object can be modeled as a
process, actually it will require that all instance variable of this object
be a pi-process itself, not to mention the database in which it is stored,
and so on...

I am wondering why SAP and PeopleSoft have not yet released a pi-version of
their ERP system?

</JJ>

Just to clarify. If you look at some of the swimlane diagrams in the paper,
each swimlane is a BPML process in its own right (the XML form and
notational form being just alternate notations).
<JJ>I think you just touched the fundamental issue I have with pi, BPML/BPEL
and Intalio's product

As I understand it, Pi and Intalio's product do not allow for role
separation (since a role IS A process). Since everything is a process, there
is no way to introduce the notion of domain of control or independent role,
everything is capable of exchanging messaging with everything at all levels
(that looks pretty evil to me, though Howard seems to argue that this is
great in the paragraphs below),

I can easily conceive that choreography is not not needed as long as you
have process composition, but what choreography buys you is precisely this
notion of domain of control that does not seem to exist in what I have seen
so far. Pi works wonders in a wireless system where the levels of nesting of
pi-processes are relatively low. However, I cannot imagine the disaster for
an ERP system or a workflow where the level of nesting could reach infinity
(in computers terms). 

This is precisely because this notion of domain of control does not exist
that BPEL/BPML are going through excruciating pain to create the concept of
an abstract process, to precisely define the boundaries that do no exist in
the theory. As a matter of fact, pi just by itself, cannot cross company
boundaries. I think that this is what howards says in the next two
paragraphs.

Maybe there is a business opportunity to run Intalio's Process Virtual
Machine in an ASP model, running all pi-processes in the world. Then the
problem will be solved.

</JJ>


The process virtual machine within the BPMS creates end to end processes out
of piecemeal processes at all levels. This is where the Pi concepts come in,
since the interaction between swimlanes is of course mobile behavior as
defined by Milner. We chose email as an example as it is a recusive process
with this characteristic. We have found similar characteristics with change
management processes, record keeping processes etc. We see no correspondence
between these and typical workflow processes as WFMS have been typically
applied in business. 
It feels very different to me in practice.

I believe that the significance of choreography lies at the heart of this,
which is kind of why a subset of BPMI.org members submitted WSCI, based on
BPML, to this group, as a first step towards unification. After all, it is
WSCI-territory that allows multiple technologies from existing players (even
if they have no intention to build a BPMS) to be used in conjunction with
each other. 

Howard