RE: BP modeling - followup to Apr 11 Analysis conf call

[LONJON Antoine <alonjon@mega.com>]

Todd,

Let me answer both as an early member of the BP team and as a modeling tool
vendor.

1. The overall idea of the BPSS is to produce the XML DTD that all ebXML
Business process will have to conforme to. 
This XML layer is the only think we can rely on for interoperability
because.
	a. It will have to face true validation when used by runtime engine.
	b. It is an independent format that can stand of its own and is XML
based.
	c. This format is neutral considering any vendor tool (design tool
and runtime engine).

2. The UMM stands for two things. First it is a meta-model, second a way to
model business process according to the meta-model: the is a methodology.
On the meta-model side, UMM is effectively a superset of the BPSS. It is so
because of the methodology that covers requirements phases that the BPSS is
not concerned with. There are some differences (most minor in my mind)
between UMM and BPSS that can be fixed easily.
On the methodology side, I'm often surprised to hear that UMM should be
mandatory. It's good to have guidelines. But they are not laws. Everybody
knows that each project has it's own way to implement a methodology. This
should even be first step of a project: Determine it's own procedures based
on recommended methodologies.

3. There is sometime confusion between UMM and UML. The UMM meta-model is
based on UML(version 1.3) adding specific elements to it to cover process
definition. These extensions are called a profile for UML (in OMG
terminology).
So the UMM is an extension of UML. Being compliant with UMM means being
compliant with UMM extension of UML. (In terms of tool interoperability,
this is an important point. That means that each UML tool has to implement
UML extensions the same way. Guess what the reality is.....).

4. On the pure vendor side, MEGA International is implementing the ebXML
specification today. As we have extended business process modeling, we can
also support the UMM. I think competitors will also support ebXML.
Some of them will come from pure UML side: they will propose an
implementation of the UMM profile for UML.
Some other will build a direct BPE tool.

5. Tool interoperability. This is the difficult subject.
Just quote Bob:
> BPE-generated models should conform to the UMM Metamodel
>.If they are to be stored in ebXML repositories,
> it should be in a neutral format that can be shared 
> also by full UML tool
> (The BP work group should decide which neutral format to specify,
> XMI, RDF or whatever.)

A. UML is not neutral. It has a version: 1.3. Version 1.4 is coming soon and
version 2.0 is on the track (MEGA International is part of these working
groups at the OMG). So what version of UML should be stored for ebXML: the
oldest one?
B. UMM is an extension of UML. The reality is that tool vendors (we do our
best however) always have slightly different ways to implement extensions.
SQL is a standard but Oracle and Db2 have their own extensions (That make
the value of each products).
C. The weakest point is to come. It concerns diagramming. There is no
standard way today to specify how diagrams can be exchanged in XML. The
current UML specification is too weak (you lose data). The OMG is working on
that subject but it will take time: to specify, to implement. So diagram
exchange is not easy today (it is not a matter of XMI, RDF, ..., but of what
content is stored is these formats).

To summarize: Tool interoperability is improving but some work has still to
be done. 
The ultimate reliable format for ebXML BP is the one described by the BPPSS.

This format can be easily handled by SMEs. It can cover simple or complex
processes. It can be produced manually or by BPE tools. MEGA, we are
committed to deliver that format.
Runtime software has to come. Surely the major participants of ebXML will
provide you with such a software. The proof of concept is demonstrating
their capabilities at each meeting.

Antoine LONJON
Chief Architect
MEGA International US
781 890 3442
alonjon@mega.com
www.mega.com



-----Original Message-----
From: Todd Boyle [mailto:tboyle@rosehill.net]
Sent: Thursday, April 12, 2001 1:45 PM
To: Bob Haugen; 'ebXML-BP@llists.ebxml.org'; 'ebXML-CCBP-Analysis
(E-mail)'
Subject: RE: BP modeling - followup to Apr 11 Analysis conf call


Bob Haugen...
> For people who want to develop simple limited-purpose business 
> process models, for whom UML is overkill and raw XML is too
> difficult, Business Process Editors should be developed 
> using the concepts in the  BP Worksheet document.
> (Several vendors already have these in the works.) 
> 
> These BPEs should be able to work at several levels,
> from simple business transactions to larger collaborations to 
> whole reference models.  BPE-generated models should conform
> to the UMM Metamodel.  If they are to be stored in ebXML repositories, 
> it should be in a neutral format that can be shared also by full 
> UML tools.
> (The BP work group should decide which neutral format to specify,
> XMI, RDF or whatever.)
> 
> Respectfully,
> Bob Haugen

Bob, OK, I want to use a BP Editor.  Let's say I'm a software 
developer.  I want my software to be a good citizen in business 
processes and I'm ready to code it accordingly.

(if you're busy see last paragraph.)

Who are these vendors?  Is there a commitment between any of 
them, that the BP schema produced by the editors will be 
interoperable with each other, around ebXML spec as compared
with the TMWG spec?

And, how close are we to any vendor applications, that can run 
these BP schemas?  It doesn't have to be perfect as long as it 
can give SMEs some basic handling like preconditions, basic 
stuff like timeouts, graceful failure handling.  Just a few 
basic things---almost like a transmittal sheet stapled
on an invoice or PO.  And an ID code, that associates the 
Order, the Fulfilment, and the Settlement document.  

I am confused, and a bit worried.  

My impression is that the UN/CEFACT community has all but decided
to delegate its business process design work to the TMWG.  In 
other words, ebXML has "lost some customers"?  (that's ok, I think)

And within the ebXML leadership I am now reading that ebXML BPSS
may become a strict subset of UMM?  Sounds like a good idea, 
ensures the compatibility of products that implement ebXML BP.

In fact, these directions seem positive--we may get applications
that do the most important, simplest processes for small business,
and some assurance they will have a long payback period without
becoming obsolete.  And we get them sooner, and with feature
sets that do not transfer just a little wealth to incumbents 
of EDI.  

My perspective is EDIFACT is an essential stakeholder in designs
of business architectures, and EDIFACT users are also important 
suppliers and customers for SMEs.  However, individuals and SMEs
are way underrepresented in UNCEFACT, that's why 28 million SMEs
in the US are still printing paper checks while F500 EDI is 
working better than ever.  EDI users love to say, *they will never
stop using EDI.*  Surely, SMEs must despair of UN/CEFACT process.

At the same time however, if ebXML BPSS is a subset, isn't 
there a risk of omitting some key part of the UMM superset, 
which is a more complete model?  What if our ebXML vendors cut
to the larger TMWG.  What if the ebXML users cutover first! 
What if it's disruptive. etc.  

My gut tells me, these are not as big a problem as waiting 
years, while TMWG deliberates and Intuit and Microsoft sew up
the SME market, and then finding out the TMWG thing doesn't
work for SMEs anyway, it only works to modernize EDI.

I am most troubled by several, separate efforts such as CPP/CPA, 
the BPSS and the BP.  When actually what I want is them all smoothly
integrated with each other and with TRP and RR into a single
application.

Let's not lose momentum during this reorganization, and let's 
not just "drop dead" in May.

I wish the vendors would all go down to YahooGroups and start 
up an "EBXML Vendor Forum", to publish their arguments about what
specifications they are adopting the next few years, while the 
UN/CEFACT continues on its course.   Heck. Call it the 
"UMM BP Vendor Forum" if that's really what it is!  Would any
two ebXML BP vendors please call each other on the phone and
setup this Forum where we can talk about the profane and 
forbidden topic, of commercial products.

TOdd



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org