Federated Processes and BPMS Topology

[Howard N Smith <howard.smith@ontology.org>]

At 12:30 AM 12/4/2003 +1000, Andrew Berry wrote:
>I agree with the focus on defining processes at an appropriate level of abstraction.  We must be careful, 
>however, not to build-in the assumption that processes are executed or controlled by a central broker.  
>In terms of execution/operational semantics, this is the big jump that must be made when moving from 
>a single-organisation process/workflow management environment (where a central broker is practical 
>and appropriate) to an environment for processes than span autonomous and physically distributed organisations
>(where a central broker is often neither practical nor appropriate).  The issues we're raising with respect to 
>Pi calculus semantics are related to the latter type of process when there >is no central broker.  I would be 
>interested to know if you have attempted to implement/use BPMS without a central broker.

Good question. 

Firstly, I have to say that I am totally in favour of federation and distribution:

1. In respect of end to end process design

2. In respect of end to end process management

3. In respect of end to end process execution

All three are in fact different. I can see the need for shared BPMS, distributed BPMS's talking to one another,
and/or a distributed BPMS execution environment. Similarly, a BPMS, distributed or otherwise, will need to 
support distributed process design activities, as well as management activities, for different companies may
wish to work together to collaboratively manage processes, such as taking different responsibilities for
different aspects of a process design lifecycle - from discovery, reengineering, deployment, operational
management, analysis, optimization, etc.

Well, the question is, with all these topologies, to what extent can the vendors of different solutions agree
on what is needed in standards. I know of one BPMS vendor who is doing p2p agent based BPMS. 
I know of another doing a very centralised transactional environment, similar to a database. I think
different vendors will have different requirements for emphasis in standards. So, the approach we took
at BPMI.org was to develop a model that didn't require one approach or another, and I don't think BPML does. 

At CSC, we have proposed BPML-based, BPMS topologies as follows:

- a single enterprise BPMS, clustered for performance
- a shared BPMS among several firms
- a federated BPMS topology, where end to end processes span BPMS systems owned by different agencies
(where swimlanes are actually different BPMS systems, just as in a centralised model swimlanes might represent
different enteprises ERP and SCM systems)

At the level of BPML I see no limits to the creativity vendors will make in allowing their BPMS to be centralised,
distributed or otherwise. 

Now, this is quite different from the issue of interoperability between different BPMS products. 
I think the approach we took at BPMI.org was to assume that, as with databases, end users would
be less interested in BPMS to BPMS interoperability then they would the opportunity to consolidate processes
from multiple systems (as with RDBMS data aggregation). We saw BPMS as being the enabler to practically
share processes, as Web Services allows the sharing of functions and RDBMS the sharing of data. In this
respect we were not in the p2p, b2b, very extended, very loosely-coupled camp. Although, we accept some
vendors might be. Rather, we would see a gorilla in an industry managing BPMS operations on behalf of
a trading group, and, last mile connectivity into the value chain might be provided by, for example, deploying
an agent based approach at the periphery. In fact, we would treat such agents as participants (swimlane sense)
in an end to end process managed on BPMS. In fact, CSC is currently brokering a conversation between
an agent based BPMS company and a centralised BPMS company for that very reason. We want to develop
a projector for the agent coupler so that it can be included in end to end processes managed on a BPMS.

Does this help clarify? Clearly, massively distributed topologies will impose different requirements, and 
for some in the b2b world this is the dream. I have to admit to not being in that camp, but this does not mean
that I am not in favour of distributed BPMS from either an execution, platform or process management perspective.
And as JJ points out, I am only one voice.

Howard


>Ciao,
>
>AndyB
>
>On 03/12/2003, at 10:56 PM, Howard N Smith wrote:
>
>>
>>Guys,
>>
>>I would like to respond to the thread of messages that my "workflow/pi" paper
>>has created at wschor. It's difficult to respond, because most of reaction is to the title
>>of the paper, and not the substance. Along the way, I'd like to say some things
>>about Phase 2 of BPMI.org.
>>
>>Let's get some things straight:
>>
>>1. The paper was written to get the attention of the workflow community.
>>It succeeded. For months and months we had been discussing joint work
>>between the BPMI and WFMC and getting nowhere. In addition, and before
>>that, WFMC had said BPML could not model workflow. So, I found Wil's
>>pattern work and asked BPMI members to show how to model it. We did
>>that first on pieces of paper, then asked Wil to do some, and when that
>>went wrong, we did it ourselves, using a practical BPML tool, and even
>>built executable versions of the patterns, and elements of a workflow engine
>>implemented only in BPML.  It was to update people on this work that
>>we wrote the paper. The work exists, whether people like it or not.
>>We believe BPML can do the same for many other types of processes.
>>Indeed, CSC is delivering operational systems based on this technology,
>>today.
>>
>>2. The title of the paper was intended to get a reaction. Papers are not
>>read unless they are moderately controversial.
>>
>>3. Pi Calculus was an inspiration for the development of BPML.
>>The focus of the work to model workflow patterns in the paper was
>>on BPML, not Pi-C.
>>
>>JJ said:
>>
>>>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)
>>
>>It is possible to approximate to domains of control in BPML dependent on how the model
>>is modelled. However, there is no doubt that more work is required on domains of control,
>>and I suspect this will be part of BPMI Phase 2 activities. At present, CSC has not encountered
>>serious barriers from this point in practical projects however. BPMI.org is a very practical
>>group, not developing standards in isolation, but implementations in parallel. While we are
>>not unique in that, we are focussed upon it. Thus, untill clear requirements emerge from
>>project work we wont put effort into standards on that basis.
>>
>>JJ said:
>>>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.
>>
>>I'm not sure what you are implying here JJ. Choregraphy is inherent to BPMS, at every boundary
>>of every swimlane.
>>
>>AB said:
>>>The key problem with pi calculus is that its operational semantics assumes a global namespace
>>>and arbitrary synchronisation on names shared by processes. While you can create a modelling
>>>layer above this that uses conventions to provide partitioned namespaces (e.g. ensuring that names
>>>are not shared by distributed processes), any semantic analysis of such models you make based
>>>on the pi operational semantics is potentially invalid.
>>
>>Again, I recommend we focus on BPML and the evolution of BPEL towards BPML, rather than
>>this Pi C debate. I have certainly encountered no problems using BPMS that arise from these comments
>>about Pi C.
>>
>>SRT said:
>>>I understand Howard's attraction to a simple unifying model of computation, of which the pi-calculus
>>>is a candidate. So Howard is correct in asserting that workflow is a pi-process but it's just not a useful
>>>thing to say for most people.
>>
>>I think the point is Steve that BPMS requires a formality. The one I am using has a formality, inspired
>>by the Pi C. I think the BPMS vendors need to keep focussed on formality because otherwise they
>>are dragged into arbitrary schema/tag debates. But really, I dont talk to customers much about Pi C.
>>I just demonstrate the power of a BPMS to solve their problems.
>>
>>SRT said:
>>>On the other hand JJ's point does beg the question "is it useful to model workflow using the pi-calculus?.
>>
>>Of course it is not useful. But it is useful to use a single process language, BPML or BPEL, to build
>>a run time capable of executing models of various things, including workflow, ERP etc, and for those
>>to be choregraphy together to create end to end processes, even to include email-like collaborations
>>as part of end to end transactional processes. Its what BPMS is for.
>>
>>JJ said:
>>
>>>Steve, you might understand a bit my fustration, after 5 years, of attempting to contribute to defining
>>>a business process models at BPSS, BPML and WS-CHOR, I very sadly see that we are going pretty
>>>much nowhere, completely ignoring the basics of what we are doing. I was at a meeting in Paris last
>>>week, where one strong BPMI player was responding to my comment that I could not understand why
>>>after 4 years of efforts we still did not have a business process standard that had the concept of a
>>>"user" and "organization" like WfMC had in 1995. His response was "errare humanum est" and that
>>>was being fixed. How is it possible that someone designing a "Business Process" specification forgets
>>>about the "user" like BPML and now BPEL? Well it is possible, once you take an approach like Howard
>>>is taking. Sadly, it is only a few individuals that decide what approach to take, in one of the most
>>>undemocratic way.
>>
>>I want you to take this seriously JJ. I think you have an immense grasp on this subject and have made
>>a great contribution. But I'm not sure why you are frustrated. Firstly, in your own slide set you acknowledge
>>BPML is your preferred standard, and indeed, made a contribution to the BPML 0.4 effort. And BPML
>>products exist, and are being used, in practice, for real things, really ....
>>
>>As to concepts like user and organisation, we don't have high level "business" semantics in BPML
>>because they are not needed. They are just processes, and are defined in the model approach
>>taken by different organisations. I can assure you that the systems CSC is building using BPMS
>>does not forget the user. And I am sure vendors like Intalio ares looking at the enterprise modeling
>>tools like Popkin, ARIS, Case, MEGA and developing a meta level of support that leverages an
>>enterprise architecture model (Zackman) so that the user and organisational model can be leveraged
>>to create skeletal swimlane models, accelerating development. And CSC are also integrating
>>process repository environment like Popkin etc to our BPMS-based architecture.
>>
>>As for being undemocratic, I am no more in charge of BPML, or BPEL, than you are.
>>But I am focussed on using what works, and BPMS is working for me. Much more can
>>be done, and all voices are heard (that's the point of OASIS as well) but only those
>>vendors that actually implement stuff can have the final say .... and what is not CSC I can assure
>>you. I think you have over-stated this democracy thing in the past JJ and I think the time has
>>come to drop it. OASIS is presumably taking all views into account. As for BPMI.org, its a
>>small core group that is thinking through Phase 2, but you are more than willing to help.
>>
>>JJ said:
>>>So I reiterate my request: why are we spending all this time to create specifications that are
>>>vastly incomplete and overlapping. Why can't we all come to a point of discussion where we
>>>finally tackle this problem, creating a solid infrastructure foundation (BPEL,ws-cdl,...) on which
>>>the "business" semantics (i.e. the sugar) (BPML, ebBP...) can be built? I think answering this
>>>question would prove very fruitful.
>>
>>Well, in respect of OASIS, there is no intention to intervene across TCs as I understand it.
>>OASIS TCs are able to pursue overlapping, or even conflicting work. That is a matter for OASIS
>>leadership team to decide. As for W3C, I think there is a real effort to create coherence across
>>the work. As for BPMI.org, we are only focussed on one things, a complete stack of BPM standards
>>for BPMS, from wherever useful pieces can be found. As for across the groups, well, there could
>>be more coordination. But coordination requires purpose, and your purpose may be different to
>>ours, and different to others. For example, not everyone doing BPEL will ever build a BPMS.
>>Many BPEL implementations will be extensions to existing products, and quite different from each
>>other. We faced this too, at BPMI.org. So, let's just accept an imperfect world and do what we
>>can to build a better one. Frankly, BPMI.org has moved on from this execution stuff. Something
>>will turn out ok, and BPMS vendors are turning to the next hurdle, which appears to be in the
>>area of managing the process data itself.
>>
>>Standards tend to go from theory, to innovation, to standardisation process. Once in the
>>standardisation process, OASIS, a lot of fun is lost. Fun is in innovation. You have innovated,
>>I have innovated. Let the standards thing play out, and let's move on to the next fun. BUT ...
>>let's keep customers along the way, so that the fun helps them. This is BPMI.org philosphy
>>and you'll probably see that formalised for Phase 2 if we can get our act together. I hope
>>you, and others, will join us for the Phase 2 fun.
>>
>>Best,
>>
>>Howard

---

New Book - Business Process Management: The Third Wave
www.bpm3.com

Howard Smith/CSC/BPMI.org
cell +44 7711 594 494 (operates worldwide, dial UK)
office +44 20 8660 1963