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



 

 

ebXML and SMEs

How ebXML measures up for small to medium enterprises.

Extending the benefits of e-business to SMEs was a primary goal of ebXML. The invitation letter said:

 

"We especially recognize the opportunities that XML offers to small and medium sized companies, to developing countries, and to economies in transition. It enables them to enter easily into the world of electronic business and, as a consequence, could bring very significant additional growth to world trade."

 

Given this emphasis, one would have expected ebXML to bring concrete benefits to SMEs. Did it? To answer that question, we must first examine the reasons why SMEs at present do not "enter easily into the world of electronic business". Then we'll see what ebXML did or didn't do to remove those barriers.

 

From several studies as well as professional experience from those involved in EDI implementations for SMEs, there are several reasons that SMEs find e-business, particularly in the form of EDI, difficult. The cited reasons range from too expensive and too costly, to standards being too hard to use, to poor application integration. Despite the wide variety of reasons, the sources of the problems basically break down into two major areas: application support and application integration.

 

Application support for e-business is a fairly wide area because it is strongly affected by the particular business processes that larger partners want to implement electronically. One example is a suppliers business application being able to create the data for a shipment notice electronically to a customer before the goods are shipped, and print a bar code label for the package. Another is the ability to maintain a cross-reference of customer item numbers to internal item numbers. The technical infrastructure side of ebXML deals with lower level middleware and does not address this type of application support. So, no help is provided to SMEs at this level. Another aspect of ebXML and SME problems is the definition of the business processes in which the SMEs participate. ebXML did not define the business processes, but only aspects of the methodology for defining them. I will discuss this in a later article, but it suffices for the purposes of this article that ebXML did nothing immediate for SMEs in this area either. So, ebXML provided no help to SMEs in application support for e-business.

 

The other area is in application integration, i.e., interfacing or integrating the e-business middleware with the business application. Perhaps the best way to determine what ebXML did in this area is to examine the functions and architecture of current EDI and future ebXML based systems, and see if there is any improvement.

 

Current EDI systems generally perform the following functions:

  • Conversion (translation) of documents in EDI standard formats to/from application specific formats
  • Programming (mapping) of these conversions
  • Communications, exchange of documents with trading partners
  • Generation and tracking of acknowledgements
  • Audit logging
  • Trading partner management

These tasks are fairly complex and are very specialized, since the software involved is used strictly for EDI. Due to this, the prevalent architecture that implements e-business with EDI consists of standalone EDI systems that are interfaced with application systems. The vast majority of applications vendors find that the EDI functions are too complex and specialized to build them into their systems. The interface between the EDI based e-business system and the business application is usually in the form of application specific flat files, although relational database tables and other formats are used occasionally. The interfacing and mapping require programming assistance, and customarily must be handled on a case by case basis due to variations in trading partner business processes and data requirements.

 

Future ebXML based systems, if fully implementing the ebXML technical infrastructure, will perform the following functions:

  • Conversion (translation) of documents in XML standard formats to/from application specific formats
  • Programming (mapping) of these conversions
  • Communications, exchange of documents with trading partners
  • Generation and tracking of acknowledgements
  • Audit logging
  • Trading partner management - creation of CPP, negotiation of CPA, configuration of system using CPA
  • Configuring of system according to business processes specified in the BPSS (we assume that BPSS of large trading partners are used, and that SMEs do not define their own BPSS)
  • Management and execution of business process according to BPSS

At first glance we can see that these features are much more complex than even current EDI systems. However, there are some mitigating factors. Parsing and generation (serialization) of XML documents may be performed using general-purpose XML programming libraries rather than specialized EDI routines. Conversions between formats can be performed using general-purpose XSLT converters, and programmed using generic XSLT editors. So, these pieces may be easier in the XML world, though ebXML did not contribute to them in and of itself. In addition, it is possible that CPP and CPA creation could be performed outside of the application system, perhaps as a web based facility.

 

Even with these mitigating factors, the functionality requires fairly sophisticated software. The advantages for SMEs are determined very much by whether these features are integrated within the application or whether they reside within an e-commerce system that is interfaced with the application (similar to how current EDI systems work). Due to the specialized functions and the complexity of implementing the ebXML specifications, it is unlikely that low-end applications vendors will rapidly embrace this technology and build these features directly into business applications. If we take the current EDI systems as an example, the ebXML functionality is even more complex and there is little reason to believe that for the even more complex ebXML an integrated vs. interfaced architecture would predominate. This is further reinforced by plans of vendors, such as Intuit and Great Plains, who seem to be moving toward models other than ebXML. So, the likely architecture is again a stand-alone e-commerce system interfaced (probably with XML files) with the business application. However, the interface becomes even more complex because it needs to communicate and manage business process status in addition to exchanging data. This is somewhat daunting because while most SME applications routinely track the status of things like orders and invoices, very few have any explicit concept of a business process, much less its status. They instead offer a number of features and functions that help users execute a process (e.g. create order, modify order, cancel order), but are not themselves oriented around a process (e.g. direct goods procurement). Another exacerbating factor is the variation in trading partner business processes and information requirements. I'll cover this in a later article on business process modeling and e-commerce, but there is little reason to believe that ebXML in and of itself will do a lot to help with this situation. In EDI systems trading partner variations have their most impact on information requirements. In the ebXML architecture the application system will also be directly affected by variations in trading partner business processes. SMEs will need an even higher level of programming assistance to set up the interfaces between the application systems and the e-business system. So, on the whole, ebXML not only does not help with application integration but also actually exacerbates it.

 

In summary, since ebXML makes application integration even more of a problem, and does nothing to help other areas of application support, it is an utter failure as far as SMEs are concerned. So, if it didn't do anything for SMEs (and it didn't do much for interoperability either), what did ebXML accomplish? The short answer is that it made it easier and more efficient for large enterprises to conduct business electronically. For example, an SME dealing with six large customers gains no appreciable benefits by being able to electronically configure its system for trading with them. However, a large enterprise with hundreds or even thousands of suppliers sees significant benefits. There are also a few very nice pieces of work in specific areas in ebXML. However, as good as they may be, the market may not be very interested in them in the long run. My next article will review the likely market impact of the ebXML infrastructure specifications.

 

To close this article on a positive note, as bleak as it looks there is a chance that ebXML could actually benefit SMEs through further development and work in other bodies. I'll cover that in the final article on what remains to be done and the challenges ahead.

 

November 2, 2001

© Michael C. Rawlins