BPSS Strategic issue: one and only one metamodel

[Bob Haugen <linkage@interaccess.com>]

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

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.

<Tim McGrath>
the Quality Review team are concerned about the weak alignment of some of these
documents with the ebXML Specification Schema.  In many cases they either fail to
differentiate or clearly specify the relationship between the UMM Metamodel and the
Business Process Specification Schema.

We are concerned that the confusion these current documents may spawn within the wider
community will be damaging to the overall ebXML initiative.  For example, it is
perceivable that these documents could result in development of UMM Metamodel compliant
business process models, but not ebXML compliant models.
</Tim McGrath>

Why does the QR team have this perception, when the following
statement should settle the confusion:

<Specification Schema 0.99>
Lines 314-319:
The UML Specification Schema is a semantic subset of the metamodel behind
UMM as specified in UN/CEFACT TMWG's N90, expressed as a standalone 
UML profile. The UML Specification Schema will through the application of 
production rules produce an XML Specification Document is analytically, 
semantically and functionally equivalent to one arrived at by modeling the same 
subset through the use of UMM and its associated production rules. 
</Specification Schema 0.99>

Is it because there actually are easily-detectable differences, such that
the Business Process Editor developers are asking me off-line how
to resolve them?

Why is this important?

1. UMM is mandatory for modeling in ebXML.
From the approved ebXML Technical Architecture Specification v1.0.4:
Lines 315-328: 
"ebXML Recommended Modeling Methodology

"Business Process and Information Modeling is not mandatory. However, if implementers
and users select to model Business Processes and Information, then they SHALL use the
UN/CEFACT Modeling Methodology (UMM) that utilizes UML."

Given its mandatory status, for the BPSS to diverge from the UMM
Metamodel opens a hole in the body of ebXML specs.

2. ebXML does not work in a vacuum.  It must be integrated
with business collaboration processes beyond the 1.0 specs
and also integrated with internal business apps.  Many people
will want to do this in UML.  Many organizations that will want
to use ebXML have already adopted UMM. Besides being
mandatory, UMM is a actually a good methodology for 
developing business systems in which ebXML
will be one of the collaboration technologies.  

3. For some people, UML is overkill.  For them, the BP group 
as a whole has agreed with the concept of a simpler 
Business Process Editor which can generate both
UMM Metamodel compliant UML models (represented in
XMI or RDF) as well as Spec Schema-compliant XML
for use with CPAs at runtime.  We also had an agreement
on a simpler subset of UMM that the BPE could edit and
derive all of the artifacts for the whole Metamodel as well
as the runtime XML.  However, this agreement was predicated
on "one and only one metamodel".  If the BPSS and UMM
are out of sync (which appears now to be the case), then
the BPE developers are faced with the choice of which
to support, Metamodel or BPSS, when the two of those
should be semantically the same.

I am not going to get into the differences between BPSS and
UMM Metamodel in this message, only to highlight the
issue and state my opinion which is that apparent differences 
should be considered to be guilty until proven innocent.

(Some of the most important divergences are highlighted 
with line numbers in the related Transaction Integrity detail 
message.)

Respectfully, 
Bob Haugen