As person that was part of the ebXML journey I can see the relevance of
what both Duane and Ed bring to the table as reasons for the said
failure of ebXML as a framework. (some part of ebXML still are alive) (01)
I may suggest two more major factors, that later has emerged as an
important. The start of the Web Services movement with SOAP as
forrunner. This standard soon won the mind share of many technologist
such as those in IBM etc.This diluted that pool of willing technology
companies and their experts. This happed to coincidence with many new
efforts to be more active in the standardization area by the technology
companies. OASIS and other orgs started to get traction and patents
could be the next holy grail. Also a divergent driver (02)
As for teh cost of entry, we have in Sweden developed several national
standard that are based on ebXML and require very low cost development
and thus resulting is cheap and efficient tools. (03)
Otherwise I tend to agree with Ed that the business problems wasnt and
still is not properly addressed. (04)
thanks
/anders (05)
Ed Barkmeyer wrote:
> 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.
>
>
>> 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.
>>>
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> -Ed
>
> (06)
_________________________________________________________________
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 (07)
|