Order-Fulfillment-Settlement patterns

[Bob Haugen <linkage@interaccess.com>]

I am sending this to the BP list for Tuesday's Specification Schema
conference call, and also to the BP-CC-Analysis list for that group's
Wednesday conference call.

I think members of both groups need to be involved in this problem,
which is how to provide enough support for business collaboration 
patterns in ebXML version 1.0 (spec due to QR by Feb 17) that 1.0 
will be credible for modeling some simple real world cases. 

**** Table of contents:
      - Ambitiousness of implementation
      - Expression scope
      - Document references
      - Responsibilities of work groups

*** Ambitiousness of implementation

There are several possible levels of ambition, from simplest
to more elaborate and probably more useful. The levels of
ambition build on each other.

1. Simplest:  permit arbitrary strings in pre and post conditions,
    and have the software keep track of them as something like
    "facts" or "assertions", along with the documents they apply to
    (see below under Documents).  By "assertions", I mean in the
    sense of knowledge bases, not programming. Postcondition 
    expressions assert facts, precondition expressions can check them.  
    Business Process Editors could validate precondition expressions 
    to see if they were established by a postcondition.  We could 
    suggest assertion guidelines, but they would really be free-form.
    Some REA collaboration patterns could be expressed
    in this limited way, but it will be difficult to demonstrate
    recognition of accounting and legal events. 
    In addition, the expressions could become catch-alls for
    kludges of all kinds.  In other words, I do not recommend
    this level of ambition, but it may be the simplest thing
    that could possibly work.

2. Simple recognition of economic commitments and events,
    with a controlled vocabulary:
    We establish a vocabulary, based on the Economic Elements
    in the metamodel BRV with maybe some subtypes like
    "Order", "Product", "Delivery", "Payment", etc.  
    I think that a sufficiently inclusive list of these elements 
    can be lifted from the REA ontology and core components, 
    so this should not slow down our process.  
    The only facts that can be asserted in postcondition expressions
    or checked in precondition expressions are those that use
    this vocabulary (in addition to expressions already permitted 
    under other rules, e.g. success or failure of previous transaction).
    The vocabulary could be constrained programmatically, such as 
    in Business Process Editors.  

3. Keep track of states of economic commitments and events:
    In addition to asserting that an Order exists, for example,
    postconditions could assert that the Order is in a particular
    State, e.g. Proposed, Accepted, Fulfilled, Settled (or Completed),
    etc.  Same for other economic elements.  This would 
    require the software to keep track of more-than-strings,
    that is, to keep track of entities and update their states.
    "State" could be just a string, or it could be part of a
    state graph.  State strings could be arbitrary, or constrained
    by lists that are part of some reference model.
    States would support contract/order negotiation as well
    as economic event disputes.  Keeping track of entities
    might require identities (e.g. more than one Order in a
    collaboration), or we could just support one of each
    type of economic element in an expression scope.
    (See Expression Scope below.)
    This and the next ambition level essentially require
    the creation of runtime objects with properties.

4. Allow expressions based on properties of economic
   elements, like quantity and dateAndTime.  This was 
   my original proposal for supporting business collaboration 
   patterns.  It is probably too much to do by Feb 17.  
   Expressions based on document contents could be done 
   with any of these complexity levels, as long as the software 
   layer was able to open the document envelope.  
   This level of ambition might require more metamodel changes
   than the others.

***Expression scope

I think it would be best to specify the scope of an assertion
to be the scope of the surrounding collaboration activity
graph, e.g. the current transaction for transaction assertions,
and the current collaboration for collaboration assertions.
So if you wanted an assertion to be usable in a collaboration
scope, you would need to publish it as a postcondition of
an included collaboration or transaction.

A related issue:  do we support different instances of the
same expression in the same scope?  If so, they need to
be identified and differentiated, possibly by Document
Envelope reference (if those are differentiated).

***Document references

What is passed to the enclosing layer of software:
Both the postcondition assertion as well as a reference to the
document envelope(s) that it applies to.  This could get a little 
kinky, because e.g. for an Order, you might want to get both
the Requesting document envelope and the Responding
document envelope, especially if you are supporting
order states like counter-offers.  (Question to business
requirements group:  when would bindings to multiple document 
envelopes be necessary?)

I am assuming here that assertions are initially expressed
as postconditions of business transactions, so the requesting
and responding document envelopes are known.  (That could
also be a way of differentiating assertions with the same
expression.)  Collaborations of many transactions should be
able to raise the same assertions to their enclosing software
layer, including the same document envelopes.

Any of the above ambition levels seem to me to require
references from asserted facts (or created economic
elements) to document envelopes.

*** Responsibilities of work groups

I propose that the Analysis and Methodology group be responsible
for the business requirements and Business Process Editor changes, 
and the "Metamodel" group be responsible for changes to the 
Specification Schema to support the business requirements.

Actually, depending on the ambitiousness of implementation, the 
UMM metamodel may already include almost everything required 
to support collaboration patterns, except for some minor
refinements (which may just be documentation improvements):
* how to express economic elements in post and preconditions;
* how economic elements are related to CommercialTransactions;
* the scope of post and precondition expressions;
* the connection of postcondition of expressions to DocumentEnvelopes.

I also very strongly urge the preservation of the UMM metamodel as 
a reference model for both Specification Schema and Business
Process Editor.  In other words, the mechanisms for supporting
business collaboration patterns should be the same or at least 
strictly derivable from metamodel to specification schema and BPE.

Respectfully,
Bob Haugen