Today marks the 5-year anniversary of ebXML’s final meeting in Vienna Austria that concluded with what everyone called a successful 18-month initiative. Check out the video of the final session <- Click here!

Just as a side bar note. The little known reason why ebXML was an 18 month event had to do with UN/CEFACT rules and the maximum time an effort could run without bringing in the 50 plus national delegations in Geneva, for approval to start such an effort. So in retrospect the ebXML initiative had to finish 18 months from its start, and having a hard drop dead date was a really good forcing function for everyone involved. And to be fair, the outcome of ebXML was not any standards but a set of specifications, some white papers, technical notes and a lot of insight into what new technology like the Internet and XML could do to improve the world of EDI. Having been responsible for the creation of the initiative, as well as having had the privilege to have chaired it, I believe I have not only the right, but also a responsibility, to do an informed and impartial status update where ebXML has ended up today.

<large personal disclaimer> I am currently not and for some time have not been affiliated with either UN/CEFACT or OASIS, so I am basing my conclusions on the public evidence. Both organizations claim to operate in a public transparent manner, so that information is what I am using. </large personal disclaimer>

There can be no question that the original ebXML project was a milestone of close cooperation, proving that people from around the world could come together and agree on a set of technical specifications in such a short time with a minimum of overhead. In retrospect, the 18-month success has to be credited to the fact that the initiative lived outside the highly formal standards bureaucracy. Yet, in a way, the 18 months of work demonstrated what global standards should be:

• clear and focused on a single idea,
• quickly developed, and
• decisive with a strong bias for action over politics.

I’ll elaborate below on the degree to which the standards world embraced the work from the 18-month ebXML initiative following May 11, 2001.

The original goal when the 18-month effort started in late 1999 was to enable anyone, anywhere, to conduct business using the Internet. Now, after five years, did it achieve in the real world the goal it set out with? Based on current market penetration the answer is regrettable – NO.

I don’t believe that’s because ebXML had the wrong starting ideas or that it could have been an invalid solution. Compared to the early Web Service work five years ago, ebXML had some better technical qualities, like for instance a more reliable and secure messaging solution for B2B integration, a more mature Registry and Repository model and maybe a few more things. But what ebXML didn’t have five years ago was the support from the major technology vendors. In fact the ebXML Vice chair walked away from the project hours after its concluding meeting and started promoting the first Web Service Workshop with other major technology vendors.

In all fairness, ebXML was an 18-month effort and it was only at the end of 18 months that there was any notion of continuity after Vienna, a follow-on period that had a turbulent start, which I’ll talk about more below. Vienna was a deciding moment where some people decided to continue and others didn’t. In the meantime we now know that the Web Services vision was out to address much more than B2B, and today we can see Web Services used on devices, inside of internal company applications and also to some degree B2B. We now know that the origins of Web Services were driven by the need for distributed computing on the Internet.

At an ebXML meeting before Vienna, Microsoft was instrumental in helping to resolve a technical impasse regarding the fundamental question of should the ebXML messaging solution be based on SOAP or not; what we now know as ebMS was originally based on MIME types. There was much hope within the ebXML community that Microsoft would come around to support ebXML showing the world that the big three, Microsoft, IBM and Sun were on the same page. Sadly we now see that was optimistic thinking, but they and other technology vendors like SAP and Oracle are now all working together in the WS-I so maybe ebXML had a little bit of a role in contributing to the collaboration in that industry.

In retrospect, ebXML never really got the broad exposure it needed to become a household name in the IT world in the post 18-month efforts. This is not to say we, in the business standards world did not try. But it’s a fact of reality that the technology world had already moved onto another set of railway tracks called WS, while the original 18-month participants were still trying to keep the original ebXML mission alive. I can’t really blame the smaller IT communities from going along with the biggest software companies. The consequence turned out to be that because of the lack of any pervasive commercially available solutions for ebXML, any early implementers would have had to pay lots of money to roll out their own solutions. Commercial ebXML just never happened. I must note that Open Source ebXML does exist today However, relative to the market adoption of Web Services and what people called SOA solutions today – the Open Source ebXML market numbers aren’t grossly overwhelming.

Back in May 2001, both OASIS and UN/CEFACT recognized the dilemma of an upcoming growth in Web Services and tried to correct it by labeling ebXML as ebWS. But trying to change a brand label was too little to late.

In the early years of Web Services there were a lot of variations in how each of the companies in the IT industry pushed their proposal as being the best for the various components within the Web Services stack. But in the last 5 years not only has the IT community come together through initiatives like the W3C, DTMF and WS-I, but also major industry communities have been looking at Web Services best practices (WS profiles) to help ease implementation of the specs.

One of the perception problems that plagued ebXML was that it was not seen as a true technical plug-and-play solution. The original ebXML specifications from Vienna were seen as an “entire platform” targeted to the same B2B environment as EDI (e.g. EDI: the next generation) limited to a set of interactions. In comparison the WS model was viewed as more of a “pick only what is needed” solution, which could help with keeping a low bar on the classical challenges with anyone considering adopting a new technology.

A sad commentary on what is published today as the base of today’s ebXML implementations is that there is no one anywhere in the world who uses all of the many parts of the ebXML specification set (ebMS, Reg/Rep, CPPA, Core Components, BPSS). Specifically all of the specs, integrated as the original ebXML architecture had envisioned has not been realized. Instead parts and pieces of ebXML get used; here and there.

ebXML’s messaging services (ebMS) is probably the most popular specification with a number of successful implementations around the world; but relative to Web Services or EDI you are still not looking at a very large installed base. ebMS always offered a payload agnostic solution that is superior to AS2, with reliable and secure messaging. One observation though, it appears that each year the work on ebMS is taking on more of the Web Service specifications. At this pace ebMS is almost becoming just another Web Services profile; nothing new because Web Services provides a set of protocols that can be assembled in a number of different ways for different purposes.

Next in popularity is ebXML’s Registry/Repository (Reg/Rep) specification. There may even be more Reg/Rep implementations than there are ebMS ones; however it appears that most of the Registry implementations are not used for ebXML as originally envisioned from Vienna: to store ebXML Collaboration Profiles and Business Process Specification Schemas (BPSS). Instead Reg/Rep seems to be more used to store other types of online data for public access. It should also be noted that around the time Reg/Rep was still being developed, before Vienna, something called UDDI was starting and even companies like CommerceOne (big supporter of ebXML that no longer exists) were working also on UDDI.

As to the rest of the ebXML specifications, I sadly have to conclude from what’s out there, that aside from maybe a few isolated pockets there aren’t really any major community implementations that have changed an industry. So what went wrong after Vienna? We’ve now had five years to do a post mortem on the subject. We have evidence. There were certainly political issues that surfaced between OASIS and UN/CEFACT, even before Vienna but especially after Vienna. Each of these organizations had different working procedures, took their decisions in different ways, kept different development priority agendas and without going into details, the bottom line is the differences between the two organizations did not help promote ebXML as both sides kept to their own vision as to what the single ebXML should be.

On the technology side, there is no question that most successful implementations were those of the OASIS maintained specifications; ebMS, Reg/Rep and CPPA. However, thanks to OASIS recently trying to hijack of one of the UN/CEFACT maintained specifications, the BPSS, which is still officially in UN/CEFACT, any end user implementers of that specification are going to be left in limbo not knowing who was truly in charge. Although someone might claim the OASIS and UN/CEFACT versions of BPSS are not exactly the same thing, they are close enough to each other to be compared. It should also be noted that after Vienna the technology industry got together behind the BPEL spec, and according to analysts like Gartner and software companies like Oracle and IBM it’s pretty clear that BPEL is the hands down winner in terms of implementations, products available, etc., and mindshare.

Last but not least there is (in)famous UN/CEFACT’s ebXML Core Component Specification (CCTS). If anything has created any firestorms in recent years, at least in the CEFACT world, then it’s got to be the CCTS work. These days some people in UN/CEFACT management might see CCTS as a possible salvation and a cornerstone to a new Global Business Semantic Framework, but the fact was that it took three more years after Vienna (in 2004) before the first CCTS specification was formally finalized. The fallout was a lack of any business-centric XML payload supported till then, and actually still to now, in UN/CEFACT. In reality UN/CEFACT’s main product was and still is UN/EDIFACT, and the last I’ve heard, EDI is still not ‘dead’. Actually it is still growing. The last few years were rather a bit confusing because some of the same key CCTS people were both in UN/CEFACT and in OASIS, but while UN/CEFACT didn’t have a formal CCTS available, those same people and more in OASIS went out and started gaining support for OASIS’ own Universal Business Language (UBL) solution that was loosely based on UN/CEFACT’s Core Component and Simpl-EDI message work. To also be complete established industry community XML message schema communities like OAGi, RosettaNet, SWIFT, and EAN/UCC (now GS1) were all going to be converting to CCTS.

To confuse the B2B world even more these days, UN/CEFACT has now just started to work on its own XML business message solution with the creation of a Core Component Message Assembly (CCMA) project. Once again, if history is any indication and given we still have the same old ebXML blood going to the meetings, those in the end user community looking for a complete ebXML implementation are faced with at least the option to either pick OASIS’ UBL or CEFACT’s CCMA; in addition to choosing between competing BPSSs. Surely not what the original goal was when ebXML was created, to avoid duplicative work.

The success of anything depends on how accessible, recognizable and widely known the solution offered is, and how much the end users believe that it can solve their real problems. Today, some five years after Vienna and the completion of ebXML there still is a loyal but small ebXML community out there. I’m not sure if that’s good or bad, but it says something of the persistence of some individuals that are hopeful that things may still change.

One option could have been that ebXML could have joined the Web Services’ new technology wave and as an original 18-month initiative take an honorable place in computing history as a success that went out on top. But today the ebXML communities are small, and getting smaller and they don’t appear to be representative of a wide enough cross section of the business world; certainly not of the technology world and that disconnect between business and technology simply won’t work in practice. And I haven’t heard of Web Services as loosing any market ground recently.

The facts are pretty open. There really aren’t any big technology players supporting, implementing and aggressively marketing ebXML as a valid B2B solution. Alternatively, the opposite is true for the marketing of Web Services, which IBM and Microsoft support in every which way possible. Web Services is in devices, on phones, in new generation applications, etc. Let alone that ebXML is also competing against EDI and EDI is still alive and strong as a proven technology for business document exchanges.

My basic conclusion is the original ebXML vision we ended up with in Vienna has failed to reach its goals because it failed to recognize (and embrace) the coming market trends and adapt to making itself relevant to changing perceptions in both business and technology. Today we talk about services architecture like SOA, and Web 2.0 for the next generation of not just business but living in a digital world.

The failure of ebXML really had nothing to do with the original technical merits. ebXML simply failed to stay with the business and technology times and gain the critical mass we’d all hoped for in Vienna. There may be those within the still existing loyal ebXML community that would disagree with this statement, pointing to a number of ebXML implementations. However a close examination of those implementations shows that most of them are government sponsored initiatives that supply the client software as well. In other words there is no real “Off-the-Self” software allowing anyone out of the blue to engage with anyone else anywhere else. These implementations are only within a specific application area where the 500 lb gorilla uses the ebXML infrastructure to lock their clients/customers into their closed system.

My final comment is that all of this was not an easy conclusion to come to. The original 18-month initiative allowed me to work with so many great people. A rare opportunity at best for most people. In those 18 months we all put away much of our personal lives to ensure a successful completion in Vienna, which truly was exciting and rewarding.

In hindsight, I only wish I could have done more after Vienna, to ensure more of the success we all deserved, and to continue demonstrating the vision of what an honest international community effort could do to create standards within a healthy working environment. I know now that if I were to do it over again I would have changed a few things, but this should be a posting by itself at a later time. For now, let’s remember the good things we all celebrated on that Friday in Vienna five years ago!

Tags: ebXML