RE: comments on BP analysis docs and UMM

[Bob Haugen <linkage@interaccess.com>]

Karsten Riemer:
>As a preface to my comments there is a discussion of UMM and ebXML as input to
>the ongoing debate on this topic, and to help us focus ebXML documents on
>ebXML.

I'm not going to get into a point-by-point refutation of Karsten's last-minute 
and false diatribe against UMM, but to focus on three main issues:
1. UMM as a fulfillment of the requirements of the BP group to recommend 
    and document how to use a methodology for designing business 
    processes for ebXML;  
2. the UMM Metamodel as the practical answer to re-usable business
    process models and process components in ebXML repositories,
    yet another explicit requirement for the BP group; and
3. the distortion of the relationship between UMM and the BP Specification 
    Schema, focusing especially on transaction patterns.  BPSS cannot
    be disconnected from UMM; it is dependent.

[Let me get one point out of the way first:  the issue with UMM has never
been runtime XML business process specifications.  Those will be XML
documents conformant to the BPSS, and nobody cares how they got
there: UMM, Business Process Editor, XML Authority or text editor.

The point is that the BPSS is *not* the whole of the BP group's work
and requirements. In fact, it was an addition to the original requirements
for what everybody thought was going to be an early "infrastructure
release", but which never happened. 

Methodology and metamodel are fundamental BP requirements.  
See ebXML Requirement citations below.]

1. Contrary to Karsten's implications, it has always been one of the BP
group's duties to recommend and document how to use a methodology
for designing business processes for ebXML.  As Karsten should remember,
in the original BP face-to-face meeting in Seattle a year ago, there was an
explicit phone call from the ebXML steering committee reminding us that
it was our job to recommend a methodology, and suggesting UN/CEFACT
UMM (then called N090) as one option to consider strongly.

From the ebXML Requirements document, lines 320-324:
"* A single consistent modeling language and methodology 
* Support for current business models and practices as well as new ones developed
through business process modeling
* A superset business process metamodel that supports individually developed
business process models"
(And also the whole section 7.3 of BP requirements starting on line 690.)

That is the reason that one subgroup of the BP-CC-Analysis work group
is entitled "the Methodology group".

UMM is the methodology they have selected, as Karsten has known for
many months, and now at the last minute wants to oppose.

Note:  there was never any mandate to devise a separate methodology
for ebXML; the initial steering committee call explicitly suggested 
selecting an existing methodology, not devising a new one.
UMM is totally consistent with the mandate.  (Moreover, UN/CEFACT
is a permanent organization; ebXML is temporary.  In my opinion,
the BPSS should end up in UN/CEFACT with UMM.)

[In point of fact, the Methodology group has recommended two
"methodologies", one full UMM using UML tools, the other using
simplified Business Process Editors or worksheets.  But both
are aimed at developing business process models conforming
to the UMM Metamodel.]

2. The UMM Metamodel is the practical answer for shareable and 
re-usable business process models and process components in
ebXML repositories.

From the ebXML Requirements line 323: 
"A superset business process metamodel that supports individually developed
business process models";
and lines 693-702:
"allowing a company to 're-use' and extend standard, template, 
or actual business processes as starting points for definition 
of specific business processes
making processes defined under BPDS visually (diagrammatically) 
viewable a Identifying at least one industry standard based tool or 
technique, through which BPDS compliant processes can be defined 
through diagrammatic drawing"

The Analysis group has been very consistent in recommending that
industry groups and other larger organizations develop common 
business process models and store them in ebXML repositories.
We do not think it is practical for every business to develop their
own business process models.

For business processes and components to be reused and shared
through process modeling tools, there must be some agreements 
on structure, artifacts, etc.  As the group responsible for determining 
how to do this, the Analysis group has selected the UMM Metamodel 
as the best way to foster commonality.  Karsten has not identified
any substantive reasons to oppose this, nor named any alternative.

3. Karsten distorts the relationship between UMM and BPSS.
The BPSS was always supposed to be compatible with the 
UMM Metamodel, and there is still a statement in the BPSS
document stating that it must be possible to derive a BPSS
XML business process specification document from a UMM-
compliant business process model.  

The basis of the Analysis group working off UMM and the
BPSS working in parallel on XML runtime specs was always
that the BPSS would be compatible with UMM.  The slogan
was always "one and only one metamodel".

A case in point, from Karsten's comments:
>BPSS no longer is accompanied by a set of patterns, they reside in UMM

The BPSS is dependent on and makes continual references to the
patterns in UMM.  *BPSS cannot be disconnected from UMM*.
Moreover, the promise of legally valid ebXML transactions is also
dependent on predefined determinate transaction patterns, which 
again reside in UMM (and are referenced in BPSS). 

Karsten now this week wants to upset all of this work, and
all of these agreements, with no way to cover the requirements.  
This is wrong - historically, procedurally, substantively, and practically.

-Bob Haugen