Feedback from Common Business Process Group on Boston schema

[Bob Haugen <linkage@interaccess.com>]

I was deputized by the Boston metamodel face-to-face meeting 
to get feedback from the Common Business Process work group 
on the "specification schema" developed in Boston. Here is my
report.

I got most of the comments on the Wednesday CCBP-Analysis
conference call.

Attending the conference call were:
Bob Haugen
Brian Hayes
David Welsh
Jim Clark
Jenny Xu

Further comments after the conference call came from
Mary Kay Blantz and Jim Clark.

I will not attribute most comments to particular individuals,
but as a consensus list of issues and comments. (It was
a lively discussion.) Some people will be named where I thought 
it would help to clarify the meaning, or followup might be needed,
or it was not clear that this was a consensus statement.  David
Welsh's slogan below was definitely consensus, I just wanted
to give credit where due.

1. Comments on the diagrams in the file ebXmlSpecificationModel08.pdf
    included in the zip archive in the message:
    http://lists.ebxml.org/archives/ebxml-bp/200012/msg00029.html

    In the diagram on page 1, the classes Package and Package Content
    do not appear in the metamodel nor in any of the other submissions
    from the Boston meeting, nor did they make sense to the group 
    in the context of a business collaboration.

    Likewise, the diagram on page 2 appeared to be a deviation from the
    metamodel and the other diagrams from Boston.

2. In general, names should be the same from the metamodel to
    the specification schema to the DTD (where the names refer to
    the same concept).  (This was a consensus policy agreement, 
    not specifically directed at anything in the Boston documents.)

3. There was a long discussion here which repeated those in Boston
    about the different termination states of a business transaction -
    Success, Control Failure and Business Failure - and the various
    causes of each.  I tried to summarize this discussion, but concluded
    that the best summary was the suggestion during the meeting to
    provide a "Primer" to explain all of this stuff.

4. The name Document Transition Vehicle was disliked; the group liked
    the original Document Envelope better.  There was a long discussion
    over whether double-wrapping of documents was necessary (business
    Document Envelope in addition to transport packaging).  At the end,
    double-wrapping seemed to be justified for process-to-process 
    security and multiple documents in one Envelope.

5. A related question: is Document Envelope required?
    Answer: yes for Requesting Activities and substantive responses,
    no for business signals like acknowledgments.

6. Does RosettaNet use Document Envelopes?  Jim Clark says
    there is a similar structure with a different name.  He will research
    what the exact name is and if there are any significant differences.

7. An unanswered question:  will transferring from one e-commerce
    framework to another be trouble?  For example, X12 or BizTalk
    or Commerce One or RosettaNet to ebXML.  Jim Clark says
    that RosettaNet to ebXML will be no trouble; the others will
    require translators (at least).  

8. All views of the metamodel should be able to be registered
    and retrieved from registries, not just the elements in the
    specification schema.  The BRV and BOM views will be useful
    for process documentation, analysis and queries.  Tracking and monitoring
    software may be developed using higher-level views of collaborations,
    if nothing else.  
    Mary Kay Blantz: "Our vision is that companies/industries who wish to 
    standardize their implementations would be able to find their business processes 
    in the repository.  We will recommend that they develop models and essentially
    'match' the models.  I don't see how this can be done if they are not
    using the same methodology." (This comment applies to this issue,
    storing all views of a business process in the repository, as well as
    to the issue of a standard methodology.)

9. Being able to monitor the current state of a transaction or collaboration
    will be critical to successful electronic business. (I interpret this as
    a requirement for ebXML collaboration software to keep track of
    the state of the collaboration.)

10. The infrastructure release with a limited specification schema
      should not be regarded as the end of the road for ebXML; there
      is a lot more to do - in particular, higher levels of collaboration
      such as order, fulfillment and payment.
      How is the infrastructure release going to be different from
      traditional EDI?  What the added business value?
      There was general concern that the infrastructure release
      was no more capable than RosettaNet.  

11. Can other methodologies be accomodated besides UMM -
      in particular, IDEF?  The consensus was that IDEF diagrams
      could be derived from UMM models, but not round trips.
      The metamodel was too dependent on UML semantics
      to be completely specified in IDEF.

12. A related question:  has UMM been adopted by ebXML or not?
     (The significance here is that the Common Business Process
     and Methodology subgroups have adopted UMM as their 
     methodology.)  

     Mary Kay Blantz: "I thought that UML (and therefore UMM) was chosen.  
     Seems very late in the game to consider alternatives."

     Jim Clark: "The UMM is supported by, has incorporated the metamodel. 
     Not the other way around.

     "The way to think about it is as follows.
     1) The metamodel precisely defines the syntax and semantics of a business domain.
     2) The patterns constrains the use of the semantics into well structured
         artifacts of common use.
    3) The UMM prescriptively defines a set of steps to follow to assure that
        processes defined using the patterns are complete and well formed.

     "The UMM is based on or uses a set of patterns that are based on or defined by 
     a set of semantics (metamodel).  The metamodel does not require the use of a
     certain methodology, however the UMM has been developed to efficiently answer the
     questions and define the requirements that occur in eComm domain."

Respectfully,
Bob Haugen

"ebXML is about doing business, it's not about transport."
-David Welsh

P.S. further comments and corrections should be directed (at least)
to the BP list.