Re: Comments on process MetaModel

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

I agree with most of Cory's comments.

Specifically - I too believe that the REA model is in some sense a subset of
a generic model for interaction between organizations, namely that subset that
produces true economic events with full duality.

I also believe we need a stronger linkage between the steps in a process and
the businessInterfaces they make use of. Right now we have a 'dependency' that
we call 'mapsTo' between BusinessActivity and BusinessProcessInterface. We
could make that into a full association, and probably put it down between
RequestActivity and BusinessProcessInterface, and perhaps make BusinessSignal
an association class  off of it.

For other comments, see interleaved below:

>I do not have the model & example fully "internalized" so I may be off-base,
>but, it looks like there may be 2 Meta-layers represented in the same model
>and that this may be complicating the model.
>
>The "lower" level is the basics of interaction for a process.  Identifying
>the processes & the players , the documents that flow between these
>processes with ordering and content constraints.  This is the most "core"
>information for the entities to collaborate.
>
>The other layer, which I think derives from REA, is what I would consider an
>abstract business framework - identifying the roles that may be found in
>many generic economic processes.
>
>So, would not the elements of the business framework - such as partner,
>contract and economic resource be the "core components" that are instances
>of the first Meta model and would be specialized for specific processes?
>Could there not be non-financial business interactions (or at least those we
>do not want to think about in that way)?
>
>If so, the Meta model for the interaction would be much simpler as just the
>"core" and the REI framework would have a clear relationship with this Meta
>model - it would be an instance of it.
>
>I also wonder if the assertion is that every EbXml interaction is a
>realization of the REA model or that the REA model is one potential set of
>core related roles.  We may have a buy-in problems if we attempt to impose
>the REA view on existing processes (To intrusive on "business modeling"). On
>the other hand, I do find the REA framework to be excellent as an abstract
>framework on which to build a new self-consistent set of protocols.
>
>So, we may want to consider the separation of the "core" Meta model from the
>abstract business framework.
>
>Things that I find missing in the "core" model are;
>* A concept of the "B2B" business process it's self and the players in that
>process as well as the portals that will connect these players.  
>
>* A specific "connection" between collaborators in a process.  I think the
>"contract" of that connection is a BusinessProcessInterface which needs
>connection to the business process.  
>
>* Specialization of documents and processes
>
>* A description of the structure, cardinalities and constraints and types of
>the documents that "flow"

Looks like we may need to clarify the semantics of BusinessSignal and
InformationFlow. The former is actually what flows, the latter controls the
flow.

>
>* The ordering of documents between these collaborators (This may in some
>way be implicit based on the "steps".

Ordering of document exchanges can be done with the ControlFlow between the
two kinds of activities, specifically with the derived kind of ControlFlow
called InformationFlow.

>
>I would also think that the "Envelope" is part of the technology mapping and
>need not be in this model.  Even if it is specified, it is part of the next
>Meta-level down - not this Meta model.

I agree, the envelope should be removed from out model and left to the
transport team.

>
>Regards,
>Cory Casanave