RE: Terminology - What is a process

David said:

 >What the PI CALCULUS approach has going for it is a sound theoretical base.
 >What it does not have is an easily visible message flow in the definition,
 >which is at the heart of choreography design. Instead you have to infer the
 >message flow by matching up the sends and receives over the same channels.

I think it is more than a sound theoretical base per se. The reason these types
of formalisms are so important is that they yield a type of process description
(and therefore a type of process instance data) which is manageable. And I
realise I am being imprecise. By "manageable" I mean that it would be possible
to use tools and manipulate process designs and instances to support
complex system2system and business2business reengineering. For
me, BPM is going to be to the IT industry what CAD/CAM/CIM was to
the auto and product design industries. IT today is like manufacturing was
before CAD/CAM. Customers have worked out the cost of IT is too high
and are looking for a simplifying step. BPM is a modest step in the right 
direction,
but it depends on being able to cast all the IT-litter that is out there 
into a standard
form that can be manipulated as easily as if it were relational data.

 >What the EVENT DRIVEN approach has going for it, is that it mirrors what you
 >actually do since just about everything, sending a message, processing a
 >message, handling timeouts can be described as an event. What it hasn't got
 >(I believe) is a sound theoretical base that would allow one to prove tha
 >correctness and completeness of a design.

In an event driven system, I dont see how I can combine and manipuate processes
on my BPM platform. I'm back to making changes to the code in ways where
local impacts might have impacts of wider scope. I am still in the world of
"normal" programming. This is the world I need to break out from if I am to
approach a BPM capability.

 >What the MESSAGE FLOW/STATE TRANSITION approach has going for it is that it
 >is much closer to the message/work flow models that business analysts use to
 >define a choreography. I don't believe that many business analysts tend to
 >think in a co-operating process stytle that is required for PI Calculus. On
 >the other, hand, there could be issues around how you compose one message
 >flow out of another with this approach.

I think business analysts will use tools of all kinds that are convenient 
for a host
of different purposes. For example, some processes might look like project 
plans.
Some processes might look like swimlanes. Some processes might look quite
different: they might be be levers I can push and pull to get work done. 
Underneath
all these process interaction types I still need a formalism. I want to 
implement
a host of process tools (discovery, design, deployment, execution, interaction,
optimization, analysis ...) on top of processes, on top of BPMS. I think
business analysis is changing, and will change, as a result of BPM.
After all, let's face it, the way we are doing it now is ugly. It's a pre 
CAD/CAM
approach isnt it? It depends on knowing too much and encoding too much
and being too prescriptive and too manual, and not having tools to accelerate
our BPM activities, whether they are development, B2B integration, workflow
optimization or whatever they are.

 >NET, NET ...
 >I guess that **my** ideal approach (i.e. it's just my opinion) would be one
 >that combined the theoretical rigor of PI Calculus with the graphical
 >representations you can more easily see with Message Flow - I think that
 >this is what JJ was getting at. Who knows, it might even be possible to map
 >between a PI Calculus and a Message Flow approaches and back ... I don't
 >know. What do other folks think?

I think that different vendors may have different requirements for how they
express choreography depending upon 1) the heritage of their technology and
2) where they are heading next. For some message flow is a byproduct and
for others it might be critical.

Please forgive me if you think I am speaking out of turn, since CSC is not
a member of W3C (for reasons that escape me, sigh ;-(  but I do think it is
important to look out a bit into the "why are we doing all this" timezone. 
What
drove CSC to get into BPMI.org was not a marginal extension of existing 
technology
but a desire to push to the next level, to take the various dimensions of 
what today
we call applications (data, procedure, workflow, interaction, collaboration 
....)
and create a unified model and end to end, lifecycle, management approach. 
All I
am reporting is that in trying to make that step we found the process 
calculus work
and approach to have a lot going for it. It's more than a thoeretical 
issue. It's about
the direction going forward.

btw, David, those 3 clear examples were great.

Howard

Received on Wednesday, 16 April 2003 05:20:00 UTC