RE: 16 Mar. Conference Call notice

[Bob Haugen <linkage@interaccess.com>]

Bob Haugen:
>> Christian, do you think the metamodel be independent of the business
>> domain?  In other words, are you proposing a "process metamodel"
>> independent of business?

Christian Huemer:
>yes, i think that the meta model is independent of the business domain.
>the class diagramm part of a meta model reflects the artifacts of 
>"inter-organizational" business process modeling. so the background
>is "business modeling" but it is not specific to a certain business.

Help me out, I do not understand.  I was not advocating
"specific to a certain business". (I understand part of my
strawman might have sounded that way, but sent another
message to try to clarify that.)

I am (still) advocating that a business process metamodel
should be about *business* processes, not just processes
in general.  And there are useful things to metamodel that
are common to business-in-general, that would not be
part of a process metamodel that was "not for business".

If we do not create a business process metamodel, 
but only a generic process model, then some other group
(maybe core components) will need to develop a 
common business process metamodel, or else
ebXML will contain dozens of different ways to express
demands without knowing that they are all "ways to
express demands".

Currently, the core components group does not have
the creation of a common business process metamodel
on its agenda.  

>btw, un/cefact tmwg takes the position that a meta model should not
>only cover class diagramms, but also activity diagrams. in other words,
>this means that there should be common methodology ...

Suits me.  I don't think class diagrams communicate  very well
anyway.  Much prefer collaboration diagrams, and also like
activity diagrams, although they might be too specific for
a metamodel.

>tmwg feels that core components should go into the direction
>of modeling. they should define patterns and utility classes for
>the purpose of reuse. and i agree that reuse can apply to any
>level of detail and to different modelling concepts (classes, 
>activities, ...). what we need is to provide a concept for reusability.

I see no indication that the core components agrees.

>tmwg would highly appriciate people with detailed modeling knowledge
>to join core components.

I did join core components, but you should check with them
and see if they agree with your feelings.  (Lisa Shreve,
I tried to copy you on this message instead of cross-posting.
Any comments?)

>> Do you think that ebXML should not deal with that level
>> in any group?
 
>ebxml by itself should not provide a solution for a specific domain.

That is not what I am saying.  There are concepts involved in staged-
commitment-type business relationships that may not be expressable
in a generic process metamodel.  These concepts *are* common to
many industries.  There are many other common business-relationship
patterns that cross many industries, that need more than a generic
process to express themselves.

>> If you are not proposing a totally abstract process metamodel
>> with no business content, could you please give an example
>> or in some other way clue me in to what you are thinking of? 

>i think - in your sense - i am proposing something "abstract" :-)
>but i think we need a common layer at a higher level to ensure
>reuse between different verticals.

In the sense of a design sweet spot that I referred to in my
previous message, there are degrees of abstractness.
Abstractness can be good; "too abstract" is useless.

"A common layer at a higher level to ensure reuse between
different verticals" might be exactly what I am saying -
or it could be composed of "Process" and "Participant"
and not be very useful in the sense that anything at all
can comply.

Got any examples of what you would put in that common
layer?

Thanks again,
Bob Haugen