[Top] [All Lists]

Re: [ontolog-forum] ebxml (was: (OT) German)

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Mon, 14 Jan 2008 14:32:08 -0500
Message-id: <478BB8B8.8060004@xxxxxxxx>
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.    (01)

I don't know what this means, but I am reasonably sure I would disagree.    (02)

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.    (03)

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.    (04)

> On 1/11/08 12:31 PM, "Sharma, Ravi" <Ravi.Sharma@xxxxxxxxxxx> wrote:
>> 1. E-business B2B commerce is still far from operational as BPEL and
>> ebXML communities and vertical practices of their CoPs are not ready to
>> converge due to large learning curves.    (05)

Actually B2B e-commerce is operational and is getting stronger every 
year.  Major manufacturers have been communicating with their primary 
suppliers by EDI/EDIFACT transactions for 20 years.  In the late 1990s, 
browser-based mechanisms extended that capability to smaller suppliers.
Last year, e-transactions as a percentage of manufacture-supplier 
transactions crossed the 60% mark.    (06)

No, it is not "ebXML"; it is that ancient 1980 EDIFACT technology, 
because the least important issue is what form the data encoding takes!
(Yes, you have to agree on the form, and yes, some tools have to 
implement it and you have to buy them.  That's the technical problem.)
The important question is: what data do the interacting businesses need 
to share?    (07)

The EDIFACT idea is that a "transaction" is a set of groups of data of 
various kinds for a generalized purpose.  Each separate pair of business 
partners then agrees on which transactions they will use, which data 
groups they will use, and *how* they will use those transactions and 
data groups to implement their joint business process.  The real process 
definition and the supporting business ontology is being defined in that 
agreement, not in the standards, and not in some silver bullet 
technology.  (The typical EDI tool has a human engineer "configuring" 
the messages as "take the value in this column of the spreadsheet or 
database table and put it in that field of the message".) The business 
people choose implementations that support the process they intend; they 
don't design the business process so that it can be implemented by 
BPEL/SOAP technologies.  If the process they agree on can be so 
implemented, and it is cheaper/faster/more reliable, fine.  But if the 
implementation is emailing structured messages, it will do.    (08)

The business process and the business information used in it is 
revenue-producing for both organizations; the technologies only provide 
support and cost-reduction.  ebXML failed because it did not put the 
technology in that perspective.    (09)

In business terminology, Ravi's "large learning curve" translates to 
"high cost of entry".  When the reason for using the technology is 
cost-reduction, you have to show that the cost-of-entry is rapidly paid 
by the identifiable cost reductions.  That is called a "business case". 
  The ebXML folk erroneously believed that the reason for the new 
technology was enablement -- new possibilities.  But all they produced 
was a new way to do the same old stuff.  They didn't realize that 
connecting to a previously unknown business partner is not just a matter 
of messaging technologies -- the main concern is to agree on the way the 
businesses will work together.  And that is not done by Chinese menu.    (010)

-Ed    (011)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (012)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (013)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (014)

<Prev in Thread] Current Thread [Next in Thread>