3 Strategic issues for BP Spec Schema

[Bob Haugen <linkage@interaccess.com>]

This is the overview of three strategic issues with the 
ebXML Business Process Specification Schema V0.99
that I believe are highest priority for ebXML BP right now.

[Preface:  if I thought the situation was hopeless, 
I would not be submitting these issues. I don't.  
The transaction issues, which I think are most 
important, could be easily resolved in an hour.]

I consider resolution of the first two issues listed below to be 
critical success factors for BPSS. 

There is also a third issue listed below which I believe
is important but maybe less so than the first two.

I am stating these issues here in general and strategic terms
instead of document line numbers because the same
issues have taken on several different forms over the course
of the BP work group.  I think it is time to resolve these 
issues with firm agreement in principle, followed by 
compliance in detail.

(Document line numbers will be included in two
of the followup messages.)

1. One and only one metamodel.

    The firm agreement I seek is that the BPSS must be
    a strict subset of the UMM Metamodel, so that 
    BPSS-compliant XML runtime business process specifications 
    may be derived from UML models that conform to the UMM 
    Metamodel. In other words, we need one and only one
    metamodel. This is an issue of conceptual integrity so
    everything fits together smoothly.

2. Integrity of transaction model, or, the ability to form
    legally binding contracts and enact legal events.

    The firm agreement I seek is that the BPSS must
    conform to the requirements for the commercial use
    of electronic document interchange of UN/ECE and
    the ABA.  If the BPSS conforms to the business
    transaction semantics of the UMM Metamodel,
    then I believe this issue should be resolved as well. 
    But I want to raise it in particular because I believe 
    it is the most important business requirement on the
    BPSS.  If we get the transactions right, the rest is
    gravy.  If not, the rest doesn't work either.

3. Separate service levels for transactions and collaborations.

    Support for ebXML business transactions will be a great
    leap forward for the state of electronic business practice,
    and will handle many business scenarios.  Support for
    collaborations, especially the BPSS multi-party design,
    splits, joins, etc. will be not only more difficult for software
    developers but also for business analysts.  
    I recommend designating separate service or compliance
    levels for each degree of difficulty, so that simple transaction
    processors can be developed quickly and inexpensively.  It's not
    that far beyond what people do now with RosettaNet PIPs.

Further discussion of these issues will follow in separate messages.

Respectfully,
Bob Haugen