RE: Example Scenarios Used Within the Aerospace Industry

[Todd Boyle <tboyle@rosehill.net>]

> Some of us were talking in Vancouver about the unification of business
> process and information models.  We didn't get very far on it yet, but
> immediately it clarified all kinds of issues about core components
> and business documents and their actual use in conducting
> electronic business.

This is good.  SMEs desperately need standardization at the BP layer.
By all means keep up the good work and harmonize the ebXML 'protocol stack'.

But don't slow down the CC vocabulary.  I would appreciate an explicit
vote of confidence from the BP community, for the existing CC vocabulary.

I see no reason the work on BP should delay the immediate adoption
of core components vocabulary for the PO, the party, etc. by
SMEs, in simple HTTP interactions, TODAY.  These interactions are
already spreading rapidly in non-standard vocabularies, both within
collaboration frameworks and outside them.  This proves the viability
of custom HTTP interactions with something like biztalk server.

In other words, the BP layers under construction should
conform with existing vocabulary which is being implemented
within the business document level.  Does the BP layer require
changes in the party.details, quantity.type, identifier.type, etc.
in the CC excel spreadsheet?

Todd


> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Friday, June 01, 2001 10:18 AM
> To: 'Schuldt, Ron L'; 'ebxml-dev@lists.ebxml.org'
> Subject: RE: Example Scenarios Used Within the Aerospace Industry
>
>
> Ok, I love it.  The AIA PO example cited below is a perfect
> example of how to think about this stuff.  It's not just the
> PO (as if you are sending one document all by itself,
> it's the whole business collaboration with all of the
> documents in a reasonable sequence with relationships
> between them, so it becomes clear what goes together
> with what and why.
>
> -Bob Haugen
>
> -----Original Message-----
> From:	Schuldt, Ron L [SMTP:ron.l.schuldt@lmco.com]
> Sent:	Friday, June 01, 2001 11:49 AM
> To:	'ebxml-dev@lists.ebxml.org'
> Subject:	Example Scenarios Used Within the Aerospace Industry
>
> The Aerospace Industries Association (AIA) has been developing harmonized
> business transaction implementation conventions for the past
> several years.
> To support each transaction type (e.g., purchase order, purchase order
> change, etc.), the AIA EC Working Group starts with business example use
> case scenarios that are documented and agreed upon by the participating
> companies within the industry.
>
> Although the data details are EDI X12 oriented, the business process
> scenarios would apply to any data format standard. Therefore, I
> suggest that
> members of this list at least look at the "business example" documents
> available from the following URL:  --
> http://www.aia-aerospace.org/edi/implcon.cfm
>
> For starters, I suggest looking at the purchase order business
> example which
> is particularly useful. Portions of it could provide a model that
> this list
> might find useful.
>
> Ron Schuldt
> Lockheed Martin Enterprise Information Systems
>




> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Friday, June 01, 2001 7:58 AM
> To: 'Miller, Robert (GXS)'; David RR Webber
> Cc: ebXML Core
> Subject: RE: where the qualifiers went...
>
>
> Robert Miller wrote:
> >I hope and believe that the EWG/X12 effort will adopt a top down
> approach to
> >Core Component design that will produce significant results by the end of
> >this year.
>
> Some of us were talking in Vancouver about the unification of business
> process and information models.  We didn't get very far on it yet, but
> immediately it clarified all kinds of issues about core components
> and business documents and their actual use in conducting
> electronic business.
>
> For example, considering the stages of a business transaction in
> Open-EDI:  identification, planning, negotiation (of commitments),
> actualization (fulfilling commitments), and post-actualization
> (returns, service, etc.).  The information model must be consistent
> in structure and content across all stages.  Moreover, at each
> stage there are particular information structures that are critical -
> for example, commitments require who, what, when, how much,
> where, etc.  And there are essential relationships between
> information elements at different stages:  fulfillments vs
> commitments, etc.
>
> If the above is too abstract for you,
> commitment = PO Line Item
> fulfillment = Product Delivery
> etc.
>
> Also, to agree with Mr. Miller, it really will help to model
> all this stuff in as syntax-neutral way as possible (e.g. UML).
> CIDX is a chemical industry standards group that modeled
> all their stuff in UML and derived DTD's automatically.
> Now they want to move to XML Schema and it's just
> a matter of some new production rules.
>
> I hope the EWG/X12 effort will consider business processes
> as well as information elements.  I'll be there for a while
> Tuesday and Wednesday and would be interested in talking
> to anybody who wants to continue this discussion in person.
>
> Regards,
> Bob Haugen
> 708-524-1436