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)
|