OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-ccbp-analysis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Antoine Lonjon wrote:
>There are some differences (most minor in my mind)
>between UMM and BPSS that can be fixed easily.

I listed the differences that are most important to me
in my "transaction integrity" issue.  They could be fixed
very 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.

That wasn't something I made up, it's from the ebXML Tech Architecture.

My own personal favorite would have been OORAM, but I probably couldn't
have convinced anybody else.  Some of my colleagues swear by IDEF;
others like Catalysis; Bill McCarthy's working with Conceptual Graphs. 

The point, though, is that ebXML projects are not isolated from one another.  
The goals of runtime interoperability and share-able process models in 
repositories require some agreements.

>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.

I heard very good things about your ebXML tool from people at X12 in Seattle.
I hope to work with it soon.  I'm really glad you developed it, and think 
that MEGA's whole approach to modeling tools is very intelligent.
You seem to be able to conform to any technique because of your
own very flexible metamodel.  I expect you will have no trouble with UMM.

>5. Tool interoperability. This is the difficult subject.
[...]
>To summarize: Tool interoperability is improving but some work has still to
>be done. 

I understand that UML comes in versions.  I hope they will be upwardly
compatible. I understand that tool vendors implement profiles incompatibly,
and that diagram interchange can be ugly.  The issue in my opinion is 
what is the best feasible way to put business process models in repositories 
so they can be shared by people using different tools.  In reality, I expect 
there to be problems. What's the best we can do?  I think, keep as much 
uniformity as possible without specifying one proprietary format.

>The ultimate reliable format for ebXML BP is the one described by the BPPSS.

If you mean the runtime XML, assuming the transaction problems get fixed, I agree
that the  transaction level should be fairly reliable (and I think that is the
most important level to make reliable).  

But the topic here was not runtime XML but business process models -
in particular, UML ones.  ebXML has a whole body of work on how to 
create them, from the cc-bp-analysis team. It's all based on UMM.
Core components will use UMM; X12 and EWG will use UMM.  
We can have a body of models that at least had the same starting point.
Maybe they will even go together.

There are countless possible ways to do all this stuff.  How do we
interoperate and share models without some common ground?
Agreements need to be made.

Regards,
Bob Haugen




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC