Rawlins EC Consulting

Rawlins EC ConsultingRawlins EC Consulting

Rawlins EC Consulting - Help! Rawlins EC Consulting - Contact Rawlins EC Consulting - Resources Rawlins EC Consulting - Services Rawlins EC Consulting - About

 

Analysis





XML Resources





EDI Resources





General EC



 

 

Setting the Stage - Understanding ebXML in Context

 

To fully understand ebXML it is necessary to understand the context in which the initiative was started and a few major points about how it was conducted.

 

UN/CEFACT's and OASIS's stated motivations for starting the ebXML initiative were altruistic and laudable (see the invitation letter).  However, if one is to objectively evaluate ebXML one can't ignore certain market and political dynamics active at the time of its inception.  When negotiations between UN/CEFACT and OASIS started in the summer of 1999, Microsoft was gaining momentum with its BizTalk initiative. Unless a viable alternative framework for using XML was developed, many OASIS members (notably Sun and IBM) would be at risk of ceding yet another market to Microsoft.  UN/CEFACT, on the other hand, was affected by somewhat different dynamics.  CEFACT has a broad work program to facilitate international commerce, with one of its responsibilities being the UN/EDIFACT EDI standard (maintained by its EDIFACT Working Group, or EWG).  For several years CEFACT had been working on moving electronic commerce to a new era with the next generation of UN/EDIFACT. Dubbed "OO-edi", this approach was based on business process modeling using object oriented analysis techniques. It initially assumed that the dominant implementation would be in distributed object technology (such as CORBA). EWG and ANSI ASC X12 (an independent body, but the U.S.'s representation into the EDIFACT development process) were finally, and somewhat reluctantly, warming up to this approach when the buzz about XML started to reach the noise level of an F16 at takeoff. Various groups associated with both X12 and EDIFACT were investigating ways to embrace XML. So, UN/CEFACT was at risk either of getting trampled into EC irrelevance in the XML stampede and losing the progress made in OO-edi, or of having a number of competing XML dialects emerge from among several groups associated with it (or possibly both!). To avoid these scenarios CEFACT had to make a bold move to embrace XML. Therefore it clearly benefited both UN/CEFACT and at least a few influential OASIS members to do something. As well, it benefited them to work together, creating synergy from their respective strengths - the EDI based e-business experience, user base, government support, and UN imprimatur of CEFACT and the XML expertise and vendor base of OASIS.

 

The best source for what they intended to do is the initial Terms of Reference document between UN/CEFACT and OASIS. That document stated that the purpose of ebXML was "to research and identify the technical basis upon which the global implementation of XML (Extensible Markup Language) can be standardized". The primary goal for ebXML was to "provide an open technical framework to enable XML to be utilized in a consistent and uniform manner for the exchange of Electronic Business data in application to application, application to person and person to application environments." These statements are notable as much for what they don't say as for what they do say. ebXML was not about creating standard schemas or DTDs for common business documents such as purchase orders and invoices, but was instead about creating an infrastructure. This was a very pragmatic and politically expedient strategy.  Creating an infrastructure is more technically challenging than creating a new standardized XML vocabulary of document definitions.  However, doing the latter is much more politically complicated and contentious. It was particularly so considering that many of the organizations and vendors targeted for membership (such as RosettaNet and Commerce One) had already defined their own XML dialects. Organizationally, this strategy was remarkably successful since all of the targeted major players actively participated except Ariba and Microsoft (who finally participated at the eleventh hour). The goal, then, was to figure out how to make all of these divergent XML approaches interoperate rather than to persuade the players to converge on a single XML dialect. Success in achieving this interoperability will be the topic of a future article, as well as a recurring theme in this series.

 

The Terms of Reference and the goal of extending the benefits of e-business to small to medium sized enterprises (SMEs) will be the primary criteria I'll use to assess ebXML. In a conventional project, conformance with a Requirements Specification is usually the benchmark for such an assessment. We did produce a Requirements Specification in ebXML, but ebXML was hardly a conventional project. At the organizing meeting in November 1999, using a UN/CEFACT recommendation as a starting point for discussion, the participants agreed to a set of project teams. The teams' responsibilities were either functional (such as message handling or business process methodology) or support (such as marketing or technical coordination). They also agreed to have all of the teams start work at the same time, working in parallel. This meant that, at least a high level, the solution and its architecture were assumed from the beginning. The primary function of the Requirements Specification ending up being not to form the basis for determining the solution, but to document, review, and gain consensus on the solution that ebXML was already developing. Given this, the Requirements Specification is best characterized as being descriptive rather than prescriptive. Therefore, using it as the primary basis for assessing ebXML verges on begging the question; it would be a meaningless exercise.  However, I will use its definition of interoperability when assessing ebXML against its Terms of Reference. The Requirements Specification, as a dominant theme, also validated the sponsors' objective of extending the benefits of e-business to SMEs.  ebXML's support for SME's will also be the topic of a future article in this series.

 

It will be helpful to briefly review what ebXML produced before attempting to analyze it.  The next article will provide an overview of the ebXML architectures (the plural "s" is not a typo).

 

May 21, 2001

© Michael C. Rawlins