OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really reduce it?]

Bryan, Duane, Joe, Mike et al,

The SME/ebXML article from your email, Bryan, and Duane's response both
pointed out that there are hard problems that the standards alone don't
solve. SMEs don't hire engineers to solve these problems, they buy
easy-to-use packaged solutions that "clever engineers" have designed.
(My background here - I was with Intuit for 8 years, and shipped their
first ever online banking enabled product).

A key point not always emphasized on these standards-centric lists is
that value in these solutions comes from interoperability, not
standardization per se.  Standards are simply a way of reducing the
costs of interoperability.

Hosted services can and do enable interoperability without requiring
(unrealistically) that the world adopts a single standard, or
alternatively, that SME client-side solutions take on the full burden of
translation and conformance to individual trading partners formats,
protocols, processes. However, hosted service are insufficient on their
own - there's still the last mile integration problem, i.e. integrating
with different SME legacy apps, who (as I know from Intuit), can
generally be relied upon NOT to do anything leading edge, especially as
regards standards.

So, to the original question, does ebXML help with any of this? My sense
is, yes, over time. As a pragmatic solution provider employing some of
the aforementioned "clever engineers", we've built a solution combining
both software and hosted services (from partners) that *interoperates*
with legacy systems out there, notably EDI. To the extent a particular
group of enterprises supports one set of formats/protocols whatever,
that enables us to roll out connections faster and at lower cost than
would be the case otherwise.  The architecture/infrastructure we've
built to support this, and make it easy, in some ways mirrors that
defined by ebXML. But for now, it's purely *internal* and not fully
standards-compliant... because there's not enough out there yet for
there to be anything much we'd connect with, and hence no business (or
user) benefit.

Over time, however, I do think the ebXML stack will help to create a
"B2B standards wave" that will, eventually, and facilitated by solutions
such as ours, drive mass adoption by SMEs, and everyone else.

Best,
Roger Bass.
Founder & CEO, Traxian.

PS: by way of a plug, if this type of solution seems a fit with business
needs you see, feel free to contact me. Traxian has end-to-end
integration deployed between SMEs and enterprises such as Intel, Fedex,
and shortly Coke, and others.


-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: Tuesday, July 13, 2004 8:45 AM
To: Chiusano Joseph
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really
reduce it?]

They are comparing apples and oranges.  EDI is an ASCII format for data,

ebXML is an infrastructure.  EDI may be used within the ebXML 
infrastructure.

Accordingly, finding that the infrastructure is larger than one of it's 
components is understandable and I would agree with the author of this 
email.  

Furthermore, it is my belief that any technology needs to be "hidden" 
before it will be successful. I did not have to know SMTP in order to 
send this email - the clever engineers at Netscape hid all that from me 
and presented me only with a "send" button.  Same with clicking on a 
hyperlink.  One does not have to know anything about HTTP.

Duane Nickull



Chiusano Joseph wrote:

>FYI - question about ebXML and EDI on the XML-DEV listserv. Forwarding
>here for opportunities for correction, expression of differing opinion,
>etc.
>
>Original question is at:
>
>http://lists.xml.org/archives/xml-dev/200407/msg00110.html
>
>Kind Regards,
>Joe Chiusano
>Booz | Allen | Hamilton
>Strategy and Technology Consultants to the World
>
>-------- Original Message --------
>Subject: Re: [xml-dev] Edi complexity, does ebxml really reduce it?
>Date: Tue, 13 Jul 2004 10:02:28 -0400
>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
>Organization: Booz Allen Hamilton
>To: Michael Kay <michael.h.kay@ntlworld.com>
>CC: bry@itnisk.com, xml-dev@lists.xml.org
>References: <20040713133910.HWGG8666.mta02-svc.ntlworld.com@Turtle>
>
>You're right Mike. I'll reproduce the questions below and answer them
>here:
>
>  
>
>> Whenever one examines one of the ebxml specs or reads an article on
the subject
>> there is likely to be a reference to how edi had problems with being
accepted
>>because it was too complex, but luckily ebxml, being based on xml,
solves all
>>this
>>    
>>
>
>Not completely, but it can make usage of EDI easier (please read on).
>
>  
>
>>A very suspect class of assertion it seems like to me. I'm wondering
if
>>anyone who has familiarity with these technologies can clarify exactly
how and
>>in what ways ebxml reduces the complexity of edi.
>>    
>>
>
>In general, ebXML is "payload agnostic" - so the payload can be XML,
>EDI, binary files, etc. So the degree to which it reduces the
complexity
>of EDI depends on how much of an improvement the "ebXML approach" and
>tools might be over those for EDI (a subjective judgment, IMO). There
is
>also a great lack (IMO) of ebXML tools/products available, and still a
>good amount of EDI tools/products - so that factors in. There is also
>the factor of product price, which would require a detailed comparison
>that I have not done (and I am not aware of anythat exists).
>
>  
>
>>Basically my understanding is that ebxml just wrapped the edi model in
xml, so I
>>have a hard time seeing how it could be simpler.
>>
>>Also am wondering about CPAs in Ebxml, it strikes me that this process
could
>>actually be somewhat onerous, does anyone know of any case studies
etc. on
>>problems with making CPAs between two companies?
>>    
>>
>
>CPAs in general represent the system features that are agreed upon -
>electronically or non - by two trading partners. CPAs include various
>paramters/settings (pick favorite word) that relate to security,
>messaging, business process specification, etc. Whether the process is
>onerous or not comes down (mostly) to the tools that are available, and
>how easily they automate the process.
>
>Hope that helps.
>
>Kind Regards,
>Joe Chiusano
>Booz | Allen | Hamilton
>Strategy and Technology Consultants to the World
>
>Michael Kay wrote:
>  
>
>>>These excellent questions are probably best asked on the
>>>ebXML-dev list.
>>>      
>>>
>>Only if you want an answer from the kind of person who lives on that
list.
>>If you want answers from the people who have given up on ebxml because
they
>>found it too complex, asking here might be better.
>>
>>Michael Kay
>>    
>>
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com




The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
list archives are at http://lists.ebxml.org/archives/ebxml-dev/
To subscribe or unsubscribe from this list use the subscription manager:

<http://www.oasis-open.org/mlmanage/>


The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
list archives are at http://lists.ebxml.org/archives/ebxml-dev/
To subscribe or unsubscribe from this list use the subscription manager: 
<http://www.oasis-open.org/mlmanage/>

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]