RE: 16 Mar. Conference Call notice

[Bob Haugen <linkage@interaccess.com>]

Hi Christian et al,

Taking up your very constructive feedback from a slightly
different angle:  trying to clarify my strawman proposal.
I might have given you the impression that I wanted to
go lower in the abstract-to-concrete hierarchy than I do.

I'm picking up on your statements, as follows:
>Unfortunatly,
>due to my heavy workload during the last weeks i was not able to
>study your REA approach in detail, but i think it goes more in the
>direction of defining business patterns, which should be created by
>core components team.

My proposal of REA as an aid to the business process metamodel 
project has always been on the level of the REA ontology, which
is quite general and abstract, but still is a business process
metamodel, not a general metamodel for any process of any kind.
By that I mean it embodies the key concepts of business and
economics in a way that covers (almost any) business process,
but for example might not be appropriate in modeling a romantic
relationship or getting up in the morning.

For example, you could extract from the REA ontology a more
general process metamodel called a Transformation, where
inputs are transformed into outputs, possibly using other
resources, executed by agents, maybe being decomposed
into smaller steps, etc.  This metamodel might be suitable
for non-economic processes.

But REA also contains a metamodel for exchanges of resources
between parties, where one resource is traded for another,
often products or resources for cash.  REA describes the
objects and relationships involved in exchanges in a very
general way:  could handle barter, prepayments, any
particular exchange pattern in any industry.

And REA describes the relationships between transformation
and exchange processes, again in a very general way.

This gets back to the idea of a "sweet spot" in the design space,
between too-abstract-to-be-useful and too-concrete-to-be-reusable.
In my opinion, REA is pretty close.  Always interested in improvements
or something better.

The essence of my proposal (getting rid of the strawman aspect)
is that a useful ebXML business process metamodel should
have some business knowledge embedded in it.  In other 
words, in my opinion, it should not be only a generic process
model, although such a model might be part of it.  

Where to draw the lines - where does the metamodel become
too concrete to be re-usable in any business situation - is
certainly a judgment call.  

Trying to clarify the following statement of mine, which was
probably misleading:
>4. Production component purchasing is characterized
>by multi-stage agreements, for example:
>Yearly contracts with detailed product specifications
>Long-range forecasts
>Short-range forecasts
>    authorizations to procure materials
>    authorizations to fabricate 
>Changes to all of the above
>Shipping authorizations
>Sometimes demand-pull signals like electronic Kanbans
>   (EDIFACT DELJIT)
>The ebXML business process metamodel must handle
>all stages of procurement relationships between trading
>parties.

I don't mean that the ebXML business process metamodel
should get down into the details of multi-stage agreements.
But I think it *should* acknowledge that multi-stage agreements,
with increasing degrees of commitments, exist in many
industries, and include concepts with which to model them.
A general-purpose process model may be incapable.

REA's Type, Commitment and Execution levels are
a start in this direction.  Bill McCarthy and I are
discussing how to go farther.  Ideas are welcome.

Hope that was more clear,
Bob Haugen