Adoption of ebXML: Hiding in Plain Sight

Feb 2007
By Alan Kotok (re-printed from ebXMLforum.org)

Have you ever misplaced your glasses or keys, only to discover they were right in front of you all the time? This same phenomenon seems to be happening with some so-called experts, observers, and analysts who recently report low levels of ebXML adoption, particularly when compared to generic Web services.

While it is true that ebXML got off to slow start, in recent months the numbers of ebXML users have expanded markedly. Most of ebXML's implementations are different from what the planners of these specifications anticipated, and the ways it has been adopted are different in some respects from e-business adoption in the past. As ebXML has gained end-users, these standards have come to affect millions of lives worldwide. And in some respects ebXML has become part of the basic infrastructure, much like asphalt is to transportation or copper wire is to electricity.

The prospect of expanding e-business to small businesses motivated many of ebXML's developers, and I count myself among them. In fact, ebXML's stated objective was to make it possible for any business of any size in any industry to do business with any other business anywhere in the world. The hope at the time (1999-2001) was that the presence of an accepted international e-business standard would motivate small business software developers to support ebXML. By using accounting software that supported ebXML, for example, small businesses would find doing e-business as easy and routine as their normal everyday accounting.

Not your father's "hub-and-spoke"

To get this number of users, ebXML has spread through a variation of the classic hub-and-spoke model employed with the old electronic data interchange (EDI), but with one important difference. In the classic hub-and-spoke model large, powerful customers imposed EDI technology on their suppliers. Since the suppliers needed the business from these big customers, they installed the systems needed to make it happen, often with burdensome individual variations for each trading partner.

With ebXML, the hub-and-spoke model still has a large player (the hub) that specifies the technology for the smaller trading partners (the spokes). But in this case, many of the hubs are public agencies, regulated public utilities, or organizations subject in some way to public accountability. Thus the hubs cannot impose harsh marketplace monopolistic conditions on the spokes (as with past EDI systems). Too much push-back from these network participants would doom the hubs' programs. Rather than the classic hub-and-spoke, this arrangement is more of a consensual hub-and-spoke.

Here are some examples of these public organization networks now using ebXML day-to-day ...

Taken together, just these six ebXML application areas alone probably have hundreds of thousands, if not millions, of users. Add in ebXML's adoption by the UK's National Health Service health care records system and you likely have millions of transactions affecting people's day-to-day lives in North America, Europe, and Asia.

Open, transparent processes

The ebXML work itself was developed by an open process, sponsored by two leading standards organizations, that later promoted ebXML to a full-fledged ISO set of standards. This history helped make ebXML-based applications an attractive approach to organizations accountable to public authorities.

Another feature of the examples presented here and many other ebXML applications are their use in fulfilling vital public functions: e.g., electrical grid management, health care, port security, and public health. Having solutions based on open standards and using open-source tools means users can diagnose problems and make fixes or changes needed to get the job done, rather than becoming dependent on a vendor's proprietary solutions.

While these conditions may apply to public agencies, what about the use of ebXML by private sector enterprises? Even the business applications of ebXML - for example, networks of General Motors and Volkswagen of America manufacturers and dealerships - require consensus of all parties. While car manufacturers are much larger and more powerful than the local auto retailers, the manufacturers still need the dealers on their side. You can't push them around too much and expect to sell many cars.

What if enterprises have a choice to use ebXML?

One might look at these applications and wonder if any organizations voluntarily adopt ebXML, without a large hub providing incentives, either positive or negative. New evidence suggests more voluntary applications are beginning to take place. Wireless giant T-Mobile uses ebXML messaging for its provisioning and maintenance transactions in Europe that involves peer cooperation from equally large telephone equipment suppliers. In another commercial application, Helena Chemical Company, a manufacturer of chemicals for agriculture, recently installed a new system to handle trading partner integration that combines Business Process Execution Language with ebXML (messaging and collaboration protocol agreements). Other implementers in that industry include Monsanto, Syngenta, Agriliance, Southern States Cooperative, Wilbur-Ellis, and Agrium who are all using the NEXUSe2e toolset to collaborate electronically using the ebXML protocol and the RAPID transactions standard. No big customers held a gun to the heads of these companies. They made the decision based on the best available solutions for meeting their needs.

Health care and ebXML: the next (really) big thing

One industry recognizing the strengths of ebXML is health care, and the ebXML standards can soon expect to see some major adoptions in this high-impact field that will result in even millions of more users. The IHE (Integrating the Healthcare Environment) initiative aims to improve the use of computer systems in health care to better share information. IHE is an undertaking of the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA). Among IHE's contributions are what it calls integration profiles, that offer guidance on implementing health care information standards to meet specific clinical needs. Part of IHE's technical framework ability is an integration profile for ebXML registries, to provide cross-enterprise document sharing among health care delivery organizations. With the ability to exchange records among registries, the ebXML registry standard offers a means of establishing virtual, connected records of patients' histories within a clinical domain.

IHE tests real-life applications of its specifications through “connectathons” and demonstrations involving vendors companies. The first 2007 connectathon took place 15-19 January in Chicago. An interoperability demonstration held at last year's HIMSS conference in June drew 37 vendors and more than 3,000 visitors. At the event, some 700 participants created and tracked their own electronic health care records. The Artemis Project, a similar, but more ambitious health care initiative in Europe, also uses ebXML registry specifications. Like IHE, Artemis seeks to solve the vexing problem of interoperability involving electronic health records. But Artemis takes the work one step farther, to the level of semantic interoperability. Artemis plans to apply Semantic Web concepts to connect not only the data in the records, but the meanings of the data in the records. The Artemis project is still in its development stages but has received substantial funding from the European Commission and other sources.

Apples and elephants

On the seemingly rare occasions when market analysts can find ebXML in use, they often compare the number of ebXML applications to Web services applications, which is a highly suspect way of evaluating ebXML's market penetration. Web services can range from desktop widgets and gadgets to internal integration applications to full-fledged business-to-business exchanges. The sheer numbers of REST or SOAP uses for data exchanges, for example, will far eclipse the industrial-strength interactions typically employed by ebXML messaging. To compare the number of ebXML applications to generic Web services, therefore, isn't even an apples-and-oranges comparison; it's more like apples and elephants.

And why even compare numbers of Web services to ebXML uses? Web services and ebXML overlap and are highly complementary. The ebXML messaging is based on the SOAP specification. UDDI and ebXML registries play together quite well. Each has its own particular uses, strengths, and weaknesses.

Seek and ye shall find

In yet another ebXML implementation, the U.S. National Institutes of Health has begun requiring research funding requests submitted in electronic rather than paper form from universities and biomedical research centers. Most institutions have chosen to use specified online Web forms to capture the data in the funding requests, but NIH also offers as an option system-to-system delivery, using ebXML messaging and collaboration protocol agreements.

In researching a two-part series about NIH's electronic grant applications for Science Careers, I selected for interviews several university research administrators, seeking only a mix of large, medium, and small institutions. Of the four administrators I interviewed, two of them plan to implement NIH's system-to-system option at their institutions, one using its own systems and one using a third-party service provider. In both cases, the universities used the system-to-system option not only to transmit funding requests, but also as a means to improve their own internal processes.  Thus, without really looking too hard, I found two more enterprises planning to use ebXML, and each chose to use the technology when they were under no obligation to do so. Finding ebXML users isn't hard. You just have to open your eyes.

Alan Kotok is managing editor of Science Careers, and a participant in the original ebXML development initiative.