RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]

[Bob Haugen <linkage@interaccess.com>]

Rachel and all,

I think one of the problems has been that ebXML has been focused
on technical infrastructure, sometimes almost in opposition to 
business understanding.  (On the other hand, there were a lot
of infrastructure details to specify...)

However, there is a core of business logic buried in the details,
and it is now up to those of us who know where it is to help to
bring it out into the open.  

I don't feel like I personally have done it well enough yet,
including in the tidbit below, but I'll keep trying.

Regards,
Bob Haugen

-----Original Message-----
From:	Rachel Foerster [SMTP:rachelf@ix.netcom.com]
Sent:	Thursday, June 07, 2001 9:38 AM
To:	ebxml-dev@lists.ebxml.org
Subject:	RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]

Bob.

This is a useful explanation that begins to draw the analogy from the ebXML
UMM to "real world" concepts. However, if it takes someone like you who's
been immersed in this stuff the last 18 months to make the associations,
what does this say for the bigger community of potential users of this
stuff? The content and concepts embodied in these documents and specs should
be - at least in my opinion - accessible to the uninitiated if they are
truly to be useful and valuable.

This is one of the lessons we "EDI" folks have learned over the last 2-3
decades (albeit as a consultant I've managed to make a living as a guide.)
If the rules, concepts and ways to use them are so abstract and difficult to
extract, regardless of whether they are technically elegant or not, they in
fact become almost useless.

If ebXML is to succeed, one shouldn't have to have an expert guide through
the forest. Accessibility and ease of comprehension, and thus usefulness, is
the real great cachet of XML and I believe one of the reasons it has spread
like wildfire.....anyone who can read can understand it and begin to use it
immediately to solve message exchange needs.

Rachel Foerster

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Thursday, June 07, 2001 6:20 AM
To: 'Abid Farooqui'; 'ebxml-dev@lists.ebxml.org'
Subject: RE: [Fwd: Example Scenarios Used Within the Aerospace Industry]


Abid Farooqui asks:
>Has any one tried using some modelling tools to come
>up with business document specification. I guess OO EDI was doing that but
>it was not very condusive to XML but to other technologies like CORBA which
>are much more complex.

UN/CEFACT Modeling Methodology (UMM), the recommended methodology
for ebXML, contains a package of classes called Economic Modeling
Elements that define the basic primitive objects for most electronic
commerce.

The terms are fairly abstract because they are metamodel elements,
but they would be subclassed into whatever terminology was common
to an industry for real use.

Instead of a PO, there is an EconomicCommitment, which means
the promise to execute an EconomicEvent (such as deliver the goods)
at some future time.  EconomicCommitments could represent the
delivery schedule part of a Purchase Order.  There is also an
EconomicContract class that represents any kind of bundle of
commitments, such as a PO or a long-term contract or a
supply chain release schedule.

Instead of ShippingNotices and PaymentNotices, there are
EconomicEvents, which represent the transfer of ownership
or control of an EconomicResource, such as a product,
service or financial instrument.

EconomicEvents fulfill EconomicCommitments, for example,
product deliveries and payments fulfill the commitments of
PO Line Items.

Those Economic Modeling Elements may be what you are looking
for as the object-oriented primitives of electronic commerce.
They are the bare minimum.

See the Business Process and Business Information Analysis
Overview and Business Process Analysis Worksheets and
Guidelines at http://www.ebxml.org/specs/index.htm

Good luck,
Bob Haugen