RE: What do people really expect from ebXML?

["Blantz, Mary Kay" <mblantz@netfish.com>]

Hi Philip,

Once we finally send it out, you'll see that we do always start with a
model of the business process, drill down to Functional Sets (logical
business groups), down to Aggregate Core Components, down to Basic
Core Components.  I suppose you're right that it's like a pyramid.

We see cross-message usage at the Functional Set level, and below.
For example, a Functional Set for product specifications might be
identical for a purchasing message, for an invoice, for a shipment
notification, for test reports, etc.  

For some types of business messages, the entire message could be
cross-industry.
For example, the information required to purchase MRO supplies.  

With the syntax-neutral approach adopted by CC, we see many
opportunities for commonization across industries and 
messages.  While this approach will not reduce all the cost now
associated with traditional EDI, we are hopeful that much of
the cost caused by variance will be reduced.  And we think that
commonization will be of major benefit to the SMEs.

Mary Kay

-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Monday, April 23, 2001 10:27 AM
To: William J. Kammerer; ebXML Core
Subject: Re: What do people really expect from ebXML?


William,

       What a good question.

 " In short, why is it expected that the standards and products built upon
> the CC specs will result in anything better than what we have today with
> EDI?"

 As far as I see it the EDI data structure is a pyramid, with Data Elements
at the bottom, Composite Data Elements at the next level, Segments at the
next level, Segment Groups at the next level and 'Messages/Documents' at the
top of the pyramid.

From a data modelling point of view there are discontinuities in this
structure, particularly at the level of the document group, since Group1 in
an Invoice message is not the same as Group1 in the Purchase order message.
That is to say there is very little, if any business meaning, in the
Grouping at 'message/document' level.

Unless ebXML, or any other standard is able to model from the top of the
pyramid 'downwards' to the Data Element level, or it's equivalent, then the
standard will always have something lacking in the data model.

Naturally there needs to be a process model to detail the data flows within
the business model but that is another matter.


Cheers, Phil



----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Monday, April 23, 2001 2:23 PM
Subject: What do people really expect from ebXML?


> What do people really expect from ebXML?  Or in other words, what do
> businesses expect from ebXML Core Components?  I can reduce the scope of
> my first question simply because I think I can answer why they might
> want TR&P Messaging Services, the Registry, and Automated Trading
> Partner Agreements.  I might even be able to make a stab at answering
> that for Business Process modeling.
>
> For example, TR&P Messaging Services is giving folks something much
> better than what they have now, replacing EDIINT AS1 and AS2 for
> point-to-point EDI over the Internet.  The Registry and Repository will
> at least be able to let you automatically locate your Trading partners'
> CPPs (Collaboration Partner Profile), and thus automate the process of
> "hooking" up to them -  avoiding the pain of the trading partner
> maintenance required of EDI over the Internet packages today.  Just
> these two parts of ebXML could completely remove what's perceived
> (perhaps incorrectly) as a major impediment to automated B2B
> interoperability (e.g., EDI) -  the "expensive" VAN.  Throw in a few
> more examples, and people will immediately discern the benefit of ebXML
> in ameliorating the misery of what they go through today.
>
> I'm asking questions like these, especially of real businesses  (as
> opposed to vendors), to share with some folks in Marketing and
> Awareness.  After suitable distillation, a talented writer like Alan
> Kotok will probably be able to help craft convincing propaganda pieces.
> If you do have additional ideas on why Messaging Services, Business
> Processes, Registry and Trading Partner Automation will be attractive to
> business and industry - and just as important: why they're better than
> what we have now - please share your ideas, and I will gather and
> forward them to Beth Morrow of the M&A group.
>
> But the benefits of Core Components is a tough one to explain.  In all
> fairness, it's the most complex piece of ebXML.  And its analog in
> conventional EDI has been around and working for years -  so CC has a
> tough hurdle to jump.  Sure, I know that modeling the data structures
> might help the standards making process, but that's not a benefit that
> will sell ebXML to the business community - only a small fraction of
> that community actually participates in the standards-making process, as
> they are mostly standards "consumers."    We might even say that Core
> Components will lead to an explosion of inexpensive off-the-shelf shrink
> wrapped B2B software - but why?  Why didn't EDI lead to inexpensive
> off-the-shelf shrink wrapped B2B software?
>
> In short, why is it expected that the standards and products built upon
> the CC specs will result in anything better than what we have today with
> EDI?
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org