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



 

 

Market Impact of the ebXML Infrastructure Specifications

Will any achieve critical mass?

The ultimate measure of any standard, and for that matter any product, is market acceptance. Regardless of quality, features, or technical deficiencies, the final judgement of any standard is whether or not its implementation achieves that certain "critical mass". Achieving critical mass means that it is the first, if not the only, approach considered when organizations implement new technology. In electronic business, it means that it's highly likely that a current or potential trading partner supports the technology.

 

So, how will the ebXML infrastructure specifications measure up? Without going into too much technical detail on the merits or deficiencies of the specifications, here are my best guesses at the success of each of the infrastructure specifications. It's a near certainty that someone will implement each of these technologies, and it may even be that some single organization implements all of them. That's not the issue. What is the issue is whether or not any single technology is implemented by enough organizations to achieve critical mass.

  • Messaging Service : This specification is the hardest one to assess because it is the most mature and goes farthest in satisfying a clearly defined market demand. It provides a way to bundle several XML documents into one package, route the package to a destination within an organization, ensure the timely and reliable once-and-only-once delivery that SMTP by itself does not, and specify security options. However, the specification is overly complex, and there are several other approaches available (though at least somewhat less capable at present). Perhaps the biggest problem with the messaging service specification is that it was produced by ebXML and lacks the cachet of having come from W3C. There's a very good chance that SOAP by itself may become the de facto standard. This is ironic because near the very end of the ebXML initiative the messaging service specification was changed to incorporate SOAP in an effort to involve Microsoft. Microsoft gained everything by this and lost nothing, as they have yet to support the ebXML messaging service. One particularly ironic aspect of this is that the die-hard anti-Microsoft constituency was left with nowhere to turn after the ebXML specification was modified to incorporate SOAP, originally a Microsoft invention. The ebXML specification provides features that the current SOAP specifications by themselves do not, but it remains to be seen whether they are sufficient to overcome the marketing advantage gained by SOAP's Microsoft backing and having been brought into the W3C work program. Probability of achieving critical mass: .4
  • Registry Services : The registry services specification faces several obstacles to widespread adoption. The main obstacle is that the specification was not developed completely in terms supporting a distributed, networked registry. Without this key feature, the value added by the specification is difficult to justify when considering it against less capable registry approaches. Another handicap is that all messages exchanged with an ebXML compliant registry must be formatted in an ebXML MHS envelope. This in itself requires a somewhat heavy weight client, such as a Java application or applet, rather than a lightweight client like a browser with Java support disabled. Another failing is that, even though the ebXML registry offers a very flexible mechanism for organizing registry objects into categories, it doesn't offer native support for perhaps the most important objects that need to be stored, ebXML compliant core components and business information entities. It is near certain that the current OASIS registry will be made ebXML compliant and that CEFACT will eventually bring on-line an ebXML compliant registry. However, I think it unlikely that there will be very many other widely used implementations. Probability of achieving critical mass: .3
  • CPA/CPP : The trading partner information, i.e., the collaboration protocol profile and agreement, is a very good and well-developed piece of work. The only problem with it is that unless the "digital dial tone" electronic business environment develops any time soon (which I consider very unlikely), there is little need for it. As noted in my previous article, electronic configuration of trading partner information may be a significant benefit for organizations with hundreds of trading partners. It is a very small benefit for organizations with only a few partners, and the benefits may not outweigh the cost of development. The ANSI X12 EDI standards have had a trading partner information transaction set, the 838, for several years, and there has been only one sizeable implementation of it. I know of no EDI software packages that natively support it. If we take the 838 as an example, there will be few implementations of the CPA/CPP specification. Probability of achieving critical mass: .2
  • BPSS : The Business Process Specification Schema offers a means to describe a business process in an XML document without having to go through the laborious exercise of UML modeling. However, the complexity required to configure an application system according to a BPSS instance document, as discussed in my previous article on ebXML and SMEs, presents a considerable obstacle to adoption. There are less elegant but much easier ways to implement some of the most significant functionality that business applications might support. For example, an application could offer a series of check boxes on a customer profile setup screen indicating the business documents that are to be exchanged electronically instead of being printed. Probability of achieving critical mass: .1

In summary, I find it unlikely that any of the ebXML infrastructure specifications will see widespread implementation. Why is this the case? How was so much time and effort spent in developing specifications that the market will most likely ignore? My previous articles answer part of this question by detailing why they failed to meet the two most important requirements: enabling interoperability and supporting small to medium enterprises. However, there is another consideration that can explain this situation. It is also a very fundamental problem, having to do with scope. The ebXML infrastructure fell prey to the same kind of scope problem that burdens most Internet security specifications in that it was intended to make it easy for organizations to trade with other organizations that they don't already know. The primary problem for most organizations, for now at least, is for it to be easier to trade with other organizations that they do already know, which is a much simpler and more tractable problem.

 

For the next two articles in this series, I'll move the focus away from technology and look at analysis. The next article will examine the pros and cons of using OO analysis for electronic business, and other related topics. The following article will discuss one of the more promising, but as yet least fruitful, ebXML contributions, Core Components.

 

November 26, 2001

© Michael C. Rawlins