Rawlins on ebXML at Five

I'm sure that many people are expecting me to say that ebXML has failed, but in my opinion it is still too early to make such a blanket assessment. To date it has failed to match the level of success of EDI, which I used as a benchmark in my earlier series. I still think it unlikely that it will surpass EDI, but there is a small chance I am wrong.

Work has continued on the ebXML family of specifications. ebXML Core Components were finally codified in the UN/CEFACT Core Components Technical Specification. Several standards development organizations have either adopted the CCTS or announced their intention to do so. I re-affirm my original assessment that Core Components work may end up being ebXML's most significant and long-lived contribution. I also applaud the work of the OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC. The ebXML work has no doubt contributed directly and indirectly to the development of the XML Web Services and other specifications.

However, I'm most concerned with actual use of the ebXML technologies. For the most part, my research confirmed my original assessments of ebXML market impact. The ebMS has proven to be most often cited in production deployments. There were a few mentions of CPA/CPP with ebMS, and I found no significant evidence of the BPSS in mission-critical production deployments. There was at least one surprise. I did not expect there to be as many ebXML registry deployments as there appears to be. I think we should probably wait a few years before assessing the success of these registries to see if they collect significant content, prove their worth by longevity, and prove the concept of federated registries by linking with each other. But, the registry specification may end up having more relevance than I had originally believed.

There are a few other, less significant, miscellaneous observations that can be made about ebXML:

• In my original series I concluded with the opinion that there would be a "son of ebXML", and I think it arrived in the form of XML Web Services. Try a Google search or search the articles of any of the major trade publications and you'll find that in most cases the references to "Web Services" with "XML" exceed "ebXML" (sometimes by several orders of magnitude).
• Amazon.com has six books listed on ebXML (and hundreds of listings on web services). The book by Alan Kotok and David RR Webber can be purchased used for one cent U.S (that's .01 USD). One of the ebXML listings, Scott Neiman's, appears never to have been published. (In fairness, I should say that my own book "Using XML with Legacy Business Applications" tanked and is no longer in print).
• The pace of new articles on and updates to ebXML.org and ebXMLForum.net has generally decreased over the past few years.
• The traffic on the ebxml-dev listserv has steadily decreased over the past few years. During its better weeks it still doesn't match what the edi-l listserv does on a typical day, and some months go by with fewer entries than edi-l has on its better days. One of the biggest bursts of traffic in 2006 was spurred by this retrospective.
• The Norwegian health infrastructure replaced X.400 with ebMS for carrying EDIFACT messages. This gives a bit of irony to the observation that ebXML was the new OSI (for those of you who forget, X.400 was part of the OSI suite of applications at the top level of the network stack).

While these miscellaneous observations don't prove anything they do leave an overall impression of something other than a robust, expanding technology that is taking over the market.

I generally disagree with Klaus Naujok more than I agree with him, and his assessment of ebXML at five is no exception. I think it premature to say that ebXML has failed, but I do think it significant that he thinks it has. If it has failed, I also disagree with him on the reasons. I offered several opinions in my original series about the deficiencies in the ebXML effort and see no need to further belabor them here. I will only summarize by saying that I believe that ebXML's internal failures were primarily in concept, and secondarily in management. It was too ambitious and comprehensive an effort. If people had tried to build the web infrastructure all at once in the same we built ebXML it never would have worked. A lesson that can be learned from ebXML is that most successful standards and technology initiatives grow incrementally and organically, starting small and inventing new pieces and discarding others as they progress, and are not built from the ground up as comprehensive architectures.

Despite ebXML's internal problems, there have been significant external factors that inhibited deployment. The technology bubble, fueled by Internet hype and Y2K spending, finally burst in 2001. ebXML was based on a demand for XML, but that demand failed to meet expectations. Organizations using EDI have had no compelling reason to change to XML. ebXML was also meant to reach small businesses that difficulties implementing EDI. The proliferation of web-based EDI services, while not optimally meeting the needs of small businesses, at least has met the needs of hub companies in pushing EDI out to all of their partners.

How does the future look to me now? ebXML registries may become the dominant flavor of registry for various software-related artifacts, though I still question that there is both the need for and discipline to use such registries effectively. There will be additional deployments of ebMS, many with CPA/CPP, but it will be always be an also-ran, eclipsed by XML Web Services and EDIINT/AS2. The BPSS will be forgotten by most in the industry, if they ever really knew about it. UN/CEFACT Core Components may eventually be the building blocks for most XML messages, but not for another five to ten years.

I doubt if I will do a retrospective of ebXML at ten years. If things go the way I think they will there will be little reason. If ebXML does turn out to be a booming success sometime in the future and if I'm still working in e-Commerce and have a web site I will post a notice saying I was wrong. Don't hold your breath.

Five years ago I suggested that we assess ebXML success by comparing it to EDI implementations. To date it has failed in that test, and I don't see it succeeding in the future. I wonder what it will take for today's ebXML proponents and defenders to admit defeat.

I hate to end on a negative note, so I must say that despite its deficiencies the ebXML effort has contributed a lot to the current state of e-Commerce. We could be farther along toward ebXML's goals we had done things differently, but we wouldn't be where we are today if it had not happened at all.

© Michael C. Rawlins

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007