David and I have worked together in the
past perhaps through OASIS or AIAA?
He is one of the authors in developing the
specs. We satisfactorily used ebXML based BPSS, CPA and CPP for eCommerce for
automotive sector, fully auditable in legal and financial sense.
I was only articulating what he did so
wonderfully.
Thanks.
Ravi
(Dr. Ravi Sharma) Senior Enterprise
Architect
Vangent, Inc. Technical Excellence Center (TEC)
8618 Westwood Center Drive,
Suite 310, Vienna VA 22182
(o) 703-827-0638, (c) 3132041740 www.vangent.com
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of carl mattocks
Sent: Tuesday, January 15, 2008
1:15 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: [ontolog-forum] Fwd:
ebXML "failure"
As an aid to clarification ;-}
---------- Forwarded message ----------
From: David RR Webber
(XML) <david@xxxxxxxxx >
Date: Jan 15, 2008 12:30 PM
Subject: RE: ebXML "failure" Fwd:
ontolog-forum Digest, Vol 61, Issue 11
To: carl mattocks <carlmattocks@xxxxxxxxx>
Carl,
Please forward the enclosed.
Thanks, DW
=================================================
Comments on discussion of ebXML "failure".
Notes so far -
> Duane Nickull wrote:
> > One of the primary reasons ebXML failed was because the business
process
> > component ignored the technical architecture and delivered something
else.
> > The whole could not function without that critical part.
>
> I don't know what this means, but I am reasonably sure I would disagree.
>
> The first reason why ebXML "failed" was that most of the money
was spent
> developing fancy tools and technologies and very little was spent
> developing useful common business vocabularies and getting agreement on
> them. Once again, we decided that the solution to e-business
problems
> was a technical silver bullet, instead of getting people to agree on
> nomenclature and classification. In short, ebXML did not
develop any
> common business models or ontologies -- it just developed more technical
> languages and toolkits to implement the non-existent models.
>
> The second reason why ebXML failed is closer to what Duane says, but I
> think the reverse. Part of the ebXML technical work concentrated
on the
> clear definition of process models as orchestrations of the
> communications and actions of technical components. The real
problem
> was to look at real interorganizational business processes and define
> technically implementable versions of them, *where
possible*. But
> little or no work was done on that, so the end result was a set of
> technical languages and tools for implementing processes that no
> business actually wanted to perform.
>
Gentlemen - I feel that we need to be clear on the history leading to the
present of today.
First of all - in the context of todays' Ontology work - clearly this was not a
problem ebXML set out to solve. There were many things tabled in
order to make achievable goals - and one specifically was the development of
messages and exchanges. While the CCTS work was aimed at semantics -
and that work has succeeded in developing several useful products that have led
implementers to build UBL, Navy schemas for financial exchanges, the US DRM and
more - and now the continuing work in CEFACT that SAP is leading (arguably the
market leader in ERP systems). This hardly qualifies as a
"failure". Just because IBM and Microsoft escouched and
failed to exploit your technology does not mean you have failed!!! In
many peoples books that would be a major triumph. Notice IBM finally
released ebXML support in WebSphere 6.1 in 2007 - and also are building their
XDS/IHE secure registry around ebXML - that will have a huge impact on
healthcare delivery as the 20+ vendors supporting this initiative go live in
2008.
Also - notice that the ebXML work is very much alive and continuing in Europe -
the announcement of the development of the pan-European business semantic
Registry came out only this week.
OASIS has released V3 of ebXML specifications - and in the area of semantics
and ontological alignment 2007 also saw release of the V1.1 CAM specification -
again work that originally started in ebXML.
As for the claim that ebXML never delivered on the architecture - that again
seems a very one sided view. Clearly the whole ebXML integration
diagram with the registry has been subsummed into SOA - and yet most SOA
implementers DO NOT understand the core underlying concepts and principles that
entails. The very shallow view that WSDL + UDDI = SOA is something
that is severely limiting what SOA may be able to do.
Similarly in the arena of BP - we now have 3 very capable technologies - BPMN,
BPEL and BPSS - that have different mission profiles and are highly complementary
if you know when and where to do that.
Those people who think that ebXML and BPEL don't work together should look at
what Oracle delivered for Helena Chemicals - see article here:
http://soa.sys-con.com/read/318418.htm
In summary - far from "failure" - ebXML is continuing to be deployed
- is gaining momentum as people realize the strengths of its core technologies
and the ROI - is winning new application areas - and will continue to enhance
the solution stack it provides - as more capable and mature solution
technologies emerge.
Fact is ebXML is significantly ahead of its time - and the tools available to
really make it fly - AJAX, REST, Ruby, JBOSS, mature Java and understanding of
XML are only now in place. And concepts such as the OASIS BCM work
instruct and teach much in how to approach business alignment with ebXML that
people are still only just grasping the needs for today.
Also - it is worth mentioning that as an open public standards development
initiative that delivered - ebXML is without equal - nothing before or since
has compared. Only the other month at the OASIS conference in Bejing
- there was a presentation bemoaning the loss of truely open standards work (a
bit of a Catch22 IMHO - you have to use open standards to ensure you have open
standards).
Those who would want to claim ebXML has "failed" seem to be very
selective of the measuring sticks they stand next to it. They also
fail to attribute the debt they owe to the ebXML work - and the basis of much
of what they continue to work on today - for example while it may be called
"SOA" - the concepts and foundation are very much ebXML because the
fundamentals of electronic business collaborations just don't change because
someone invented a new acronym for marketing purposes.
DW
--
Chair OASIS Business Centric Methodology TC
co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
Ontolog ONION Cop Leader
CEO CHECKMi
vmail (usa) 908 322 8715
CarlMattocks@xxxxxxxxxxx
www.CHECKMi.com
Semantically Savvy Agents