RE: [ebxml-dev] Still looking for info on ebXML deployments (final?)

Following on the heels of the discussion of ebXML deployments (which
appears to have gone dormant), did anyone else notice the recognition of
the five-year anniversary of the approval of the 18-month ebXML project
and a retrospective posted on Klaus's Korner in the blog section?  Klaus
Dieter-Naujok, you may recall, was the chairman of that initial project.
There's also a video from the closing meeting.  Check it out at
http://www.klauskorner.com/MyBlog/MyBlog.html.

Best regards,
Bill Chessman
Inovis(tm)

-----Original Message-----
From: Dale Moberg [mailto:] 
Sent: Monday, May 01, 2006 3:43 PM
To: ebxml-dev
Subject: RE: [ebxml-dev] Still looking for info on ebXML deployments
(final?)

I snipped out little excerpts from various messages to respond to.
Interesting discussions despite the origins :-)



Joe C. writes:

Beyond suitability for requirements, I believe that strength and
cohesiveness of a community is a very strong factor when considering
adoption of a framework/standard. If one is asked to provide a
recommendation to a current or potential client regarding adoption of
ebXML, for instance, this situation could - I believe - be viewed as a
negative factor and therefore may serve as a strike against adoption -
which could influence a recommendation for adoption. I gently challenge
this community to show its strength and cohesiveness, else face
potential negative ramifications for global adoption.

Comment: The ebXML "community" has, like the WS-* "community," had its
share of disputes. Core components struggled for years with major
opposed coalitions. BPSS has endured and survived a custody battle. ebMS
has witnessed battles about "dynamic" collaboration (no CPA stuff!),
intermediaries, reliability, and so on. The disputes led to compromises,
some good, some adequate. 

WS-* wars (where every specification generates an equal and opposite
specification) appears much more Darwinian than ebXML has ever been. I
think WS technologies (which broadly include ebXML) will not suffer
permanently just because of all those battles.

Another "adoption assessment" is not really needed at this point. ebXML
has some limited traction, for various components and for varying use
cases. It never solved the "SME" problem (there is not just one) and who
knows what will. (I hope the UBL SBS helps, but time will tell.) I think
it is much more interesting at this point to try to find out why those
who are using various components have found them useful, rather than
asking why it has not caught on yet with the Andromedans. I personally
think that allowing questioning and debate leads to a healthier
atmosphere, rather than relying upon a prophet whose evidence is bound
to be incomplete because of enduser desires for confidentiality.
Especially a prophet who can find a cloud inside every silver lining.

Cameron Hart notes:

However I struggle to see how ebXML will become adopted by SME's (with
maybe the exception of the ebMS component).  I say this because I have
been aware of a ebMS solution available in the New Zealand marketplace
for over 2 years, and it has gained little traction.  The problem is
that the cost to provide the solution to a SME outweighs it's benefits.
It is competing with simple solutions based on HTTP posting.

Comment: 
Interesting remark.

Many internet b2b communities emerge because of a large "driver" (aka
gorilla). It can be a government regulatory driver. It can be a
mega-retailer. Having been through the rise of internet EDI with the
IETF EDIINT group, I would say you need both drivers and champions in
the portion of the supply/value chain that moves to a solution. Once a
commitment occurs, the inertia of reuse begins to dominate, and the
solution then propagates by the network effect. 

There are maybe 16 million NA businesses, with 1 million with sales
greater than $1 million yearly. I think 15.5 million businesses will
have a supply chain using fax, telephone order takers, and/or web forms.
500,000 might eventually look to some modest app to app automation. I
suspect at most 200,000 use Vans. Maybe 100,000 or 200,000 use internet
b2b direct connections. In NA probably a half use some version of
EDIINT, mostly AS2 or AS3. I think the market for secure acknowleged,
data exchange is probably half saturated in NA. There is considerable
inertia already, and current data exchange solutions will tend to
persist until there is a good reason to change. Neither XML nor
SOAP/WSDL nor ebXML constitute a business reason to change in
themselves. There might be something lurking in the background that will
provide businesses with both competitive advantages, reduced costs,
and/or ROI. That is why getting some business level case studies out
would be useful.

As far as one part of the SME issue goes, you overlook that a large
community collaboration driver can make a deal with venders to let its
community obtain automatically provisioned copies of software at low
cost. This provisioning option is an important factor to consider, and
is often the way companies are introduced to internet b2b software and
solutions.

Matt M.:
There is a lesson in this for anyone who is trying to break into the SME
B2B market.  Forget about this "I love ebXML" stuff, and let pragmatism
guide you.  Your customers will reward you for that pragmatism.  If that
pragmatism calls for ebXML -- use ebXML.  If it calls for something
else...you know what needs to be done.

Comment:
So true, but you could also leave the choice to the end users, if you
kind hide the dreary specification and protocol details sufficiently. 

Andrew S. Townley:
ebXML doesn't really have a wide exposure if you're not already using
it.  It seems to take a large investment of time/effort to understand
how to apply the technology quickly, and you need to (with the exception
of freebXML) pay lots of money or roll your own implementation.  There
are some similarities between SOA/WS-* and ebXML (I think there are more
than most believe), but I think the fundamental issue is a lack of
common language and communication between the communities.

I think the primary assumptions are: 
 * you must use the entire platform
 * it is targeted at the same B2B environment as EDI (e.g. EDI: the next
generation)

In this way, I think people (including me) believe that it is targeted
at a fairly important, but limited set of interactions.  Based on the
last few weeks of thinking about ebXML again (thanks to both you and Joe
on other forums), I can see that certain parts are certainly modular.

Comment:
I think that ebXML is kind of an open RosettaNet with a touch of
Open-EDI. The RN distinction between public and private process is
presumed (drives choreography/orchestration distinction), with the
public contracts to be standardized (in choreography and configuration
parameters). The BSV and FSV distinction is widely presumed (Open-EDI)
in the layering. [ebMS, ebCPPA, ebRR in the FSV, with BPSS, CC, BSI up
at BSV level. And ebRR has a bit of BSV in the classification and
categorization metadata.] The analogs of open PIPs were to come from CC,
but delays there mean that you have to pick them up the schemas from
UBL, OAGIS, or perhaps GS1 XML. So it definitely sprang out of EDI, RNIF
and other early eCo framework excitement during the bubble. ediNG-- not
bad.

I just don't see that using the entire platform was a design goal. This
is the usual WS-* accusation (ebXML, ugh, monolithic), and apart from
having far fewer specs than WS-*, I just don't get it. Every separate TC
develops its specifications so that it can be used either with _or_
without the other ebXML specifications. Put UBL GEDs into a WSDL
interface/porttype, and voila. Add a WSDL DocExchange element to your
CPP. Write a WSDL for ebMS 3.0. Etc. I am not sure how many products
exist that would support entirely arbitrary selections from the
resulting specification soup, but that is another issue, and not part of
the design. 

There is a sense of commonly asked for user requirements--that reliable,
secure, authenticated data exchange must be provided, for example. Maybe
that is just the ediNG point again.