Published in TDAN.com January 2000
Electronic commerce is not a new concept. Large companies have been using electronic data interchange (EDI) with their major trading partners for nearly twenty years. However, EDI has proven itself
to be too complicated and expensive for many small and many midsize companies. As a result, EDI has not been widely adopted. Therefore, EDI has not fundamentally changed the way business is
conducted.
Today business can be conducted in new ways that are eminently more affordable. The Internet and extensible markup language (XML) have lowered the entry barriers to e-commerce, in both cost and
complexity. The advent of XML, however, should not be interpreted as the end of EDI. XML does not replace EDI, but rather extends it to bring e-commerce to small and midsize companies. XML
complements EDI, and in doing so, realizes the vision of EDI.
Business-to-Business Commerce
The objective of e-commerce is to eliminate the manual trading processes by allowing internal applications of different companies to directly exchange information. In traditional commerce, both
customers and vendors may be automated internally, but their systems are usually isolated from an ability to communicate with each other Therefore, trading partners must traverse the gulf between
each system by manual processes such as mail, email, fax, meetings and phone calls. The objective of e-commerce is to minimize the manual gulf.
There are currently three different approaches labeled e-commerce. They are: web storefronts, e-commerce portals, and E2E e-commerce. Each of these approaches will be discussed as well as how well
they may fulfill companies’ e-commerce objectives and minimize the manual gulf.
Web storefronts
Many software companies are advertising web storefronts as e-commerce solutions. Web storefronts provide a web interface to a vendor’s catalog of products or services. The storefront
integrates the placing of an order over the web, with an internal processing system, like enterprise resource planning (ERP) systems, to fill the order.
This may be an acceptable solution for business-to-consumer commerce. However, it is inadequate for true business-to-business e-commerce. Customers presented with the web storefront solution would
have to visit hundreds of suppliers’ websites to fill orders. Potential customers would be presented with manual searches and manual order entry through a web form. Once an order is placed,
the customer would have to manually update their internal ordering systems, or ERP. For a large manufacturer with thousands of suppliers, this would be an intolerable way to conduct business.
E-commerce Portals
Some companies have proposed e-commerce portals to automate both vendor and customer buying and selling of goods and services. Utilizing e-commerce portals, customers can browse numerous vendor
catalogs and place orders while only visiting one website, the portal website. Vendors go to the same portal website to view and fill customer orders.
Although these portals eliminate some of the problems of web storefronts, there are major shortcomings to this approach:
- Both customers and vendors must manually update their internal systems after placing and retrieving orders from the portal
- A company’s critical information business resides outside of its internal firewalls, while its data is being updated and maintained by a third party on the portal website
- Portals charge companies for catalog updates and ensuing transactions
Companies are thus charged to access their own information! While this approach may be tested for a time it will not prove acceptable as a long-term solution. Companies want their vital information
residing within their own walls.
E2E e-commerce
The first integrated approach aimed at solving business-to-business e-commerce was called electronic data interchange (EDI). Only 300,000 companies worldwide have adopted EDI because of its
complexity and expense. (Compare that number with the millions that have established an Internet presence). As a result, EDI was never adopted widely enough to transform the way business is
conducted electronically. In fact, most large retailers have a maximum to 20 percent of their suppliers using EDI.
The basic premise of EDI, however, is right on track. EDI eliminates manual processes by allowing the internal applications of different companies to exchange information directly.
Companies such as XMLSolutions [http://www.xmls.com] are building end-to-end, enterprise-to-enterprise e-commerce systems using an open source language called XML. Reaping obvious benefits
of EDI, XML allows the internal applications of different companies to share information directly. The tremendous advantage XML holds over EDI is that XML is both machine and human readable while
EDI is only machine-readable.
EDI and XML compared
XML and EDI are very different. The creators of EDI were mainly concerned about the size of their messages. Bandwidth for EDI networks is very expensive, even today. EDI messages are thus very
compressed and use codes to represent complex values. All of the meta data is stripped from an EDI message, which makes the message difficult to read and debug. The complexity of EDI makes EDI
programmers hard to train and expensive to keep, which in turn makes EDI applications expensive to buy and maintain. Complexity drives cost.
XML messages, on the other hand, are rich in meta data, making them easy to read and debug. Good XML strives to be self-describing. The simplicity of XML makes XML programmers easy to train and
less expensive to keep, in turn making XML applications less expensive to buy and maintain.
| XML e-commerce solution | EDI e-commerce solution |
| Optimized for easy programming | Optimized for compressed messages |
| Requires web server costing $0 to $5000 | Requires dedicated EDI server costing $10,000 to $100,000 |
| Uses your existing Internet connection | Uses value-added network (VAN) charging $1 to $20 per message or more |
| XML message format learned in hours | EDI message format takes months to master |
| Only requires JavaScript, Visual Basic, Python or Perl script writers | Requires highly trained C++ programmers |
Message formats
The following two figures provide a comparison between EDI and XML. To demonstrate the difference, try to find the purchase order number in each document.
ISA*00* *00* *08*61112500TST *01*DEMO WU000003
*970911*1039*U00302000009561*0*P?
GS*PO*6111250011*WU000003 *970911*1039*9784*X*003020
ST*850*397822
BEG*00*RE*1234**980208
REF*AH*M109
REF*DP*641
REF*IA*000100685
DTM*010*970918
N1*BY*92*1287
N1*ST*92*87447
N1*ZZ*992*1287
PO1*1*1*EA*13.33**CB*80211*IZ*364*UP*718379271641
PO1*1*2*EA*13.33**CB*80211*IZ*382*UP*718379271573
PO1*1*3*EA*13.33**CB*80213*IZ*320*UP*718379271497
PO1*1*4*EA*13.33**CB*80215*IZ*360*UP*718379271848
PO1*1*5*EA*13.33**CB*80215*IZ*364*UP*718379271005
CTT*25
SE*36*397822
GE*1*9784
IEA*1*000009561
Figure 6 Sample EDI purchase order
1234
1999-02-0814:05
XMLSolutions
601 Pennsylvania Ave. NW
Suite 900
WashingtonDC20004
097251
Widgets
4
11.99
47.96
VA
0.045
2.16
…
Figure 7 Sample XML purchase order
The different approaches of XML and EDI
EDI comes in two distinct flavors, ANSI X12 and EDIFACT. ANSI X12 is the US standard for EDI and has evolved over the years from the most basic attempts at exchange between very large corporations
in the 1960s to full-blown customer/supplier billion-dollar networks. EDIFACT is the international standard, endorsed by the United Nations and designed from the ground up beginning in 1985. X12
and EDIFACT have several version releases of their message formats. Compatibility between versions is not always straightforward. In addition, there are other groups such as the Open Buying
Initiative (OBI) proposing standards for simply moving EDI messages over HTTP.
XML e-commerce is even more diversified. As of June 1999, there are at least five proposed XML-only standards under development. CommerceNet, a business consortium, is developing ECO. RosettaNet,
another consortium, is working on XML standards for product catalogs. Commerce ONE has created the common business library (CBL) in part on a government grant from the US National Institute for
Standards and Technology (NIST). Ariba has rallied several companies around commerce XML (cXML), a proposed standard for catalogs and purchase orders. Microsoft has loosely grouped many of these
technologies under what it calls BizTalk.
Other groups are working on XML-EDI hybrids. The XML-EDI Group, ANSI, Ariba, and Commerce ONE have proposed various naming conventions for encoding EDI messages in XML. Essentially, they have kept
the English language, human-readable portions of X12 data dictionary and created XML attribute tags around the data. In doing so, they hard coded the particulars of each individual EDI message into
the XML document type definitions (DTD). If a user makes any slight changes to a document, they will have to rewrite the DTD. So, for each transaction set there will be a separate DTD, and in each
DTD there will be hundreds of individual element definitions. This essentially creates a scenario in which each document has to be unique and will be incompatible with all other documents. Over the
course of the past year, these companies collectively, have only been able to produce a handful of XML documents based on existing EDI standards. Furthermore, because these approaches use the
English language for the markup of the data, they are not multi-lingual and cannot be used for a multi-national implementation of XML. These methods have not fully leveraged the basic concept of
XML, which is to make the document both machine and human readable. Implementations of these approaches could be time consuming and costly.
XML-EDI trading system
EDI works. You can rely on it. There may be no finer accolade for a technology. Companies have invested millions on their EDI systems. They rely on these systems to process critical business
information such as purchase orders and invoices. Disrupting these critical systems would have negative financial and procedural impacts on their electronic trading partners. Why would a company
consider transitioning from these systems for the promise of a new technology? The objective is to leverage EDI and extend its reach to more trading partners.
Large companies that can afford EDI have probably already acquired and implemented EDI with the top tiers of their supply chain. While those suppliers may account for 80% of their business they
only make up 20% of all active suppliers. The other 80% of suppliers are operating inefficiently and causing losses of which each side may not be aware. These large companies are looking for new
technologies that will allow them to extend their reach to their entire supply chain.
The expense of EDI is rooted in its complexity and its complexity is based in its compressed, cryptic message formats. XML overcomes this complexity by storing the meta data within the data of the
message. XML also happens to be designed for HTTP transport sessions. XML can be presented to a party through a web browser or it can be transmitted via HTTP directly from one application to
another.
Large companies can now extend their electronic trading community beyond just the companies who can afford EDI. They can leverage their current EDI investment by installing an EDI-XML translator on
their web server. By adding this technology, companies can send XML documents like purchase orders to their trading partners, and retrieve invoices over the web.
Many companies are familiar with the economies of scale gained from automation. The trading volumes of large companies cannot effectively handle the processing and accounting of paper forms. By
integrating with even their smallest suppliers, large companies will now only have one internal electronic business process for sending and receiving documents, doing away with manual transactions.
Small suppliers, however, do not gain significant economy of scale by dealing with electronic documents. Remember EDI is expensive. It is just as expensive or more expensive for a small company to
deal with an electronic purchase order as it is to deal with a paper order. A small company’s trade volume can handle the processing and accounting of paper forms. Additional manpower is
necessary to handle the computers, programs and networks necessary for electronic forms. By extending EDI to XML these small suppliers can access this information through a simple browser, allowing
them to continue to print orders and manually process them. With the ease of implementation and low cost of entry for XML, small suppliers will be able to leverage this new technology and download
the XML data directly to their internal business systems.
Converting EDI and XML
Large companies will be able to leverage existing EDI systems to send and receive XML messages with their small to mid-size suppliers and vendors. The question that arises is, how can you do this
effectively and efficiently, while still maintaining the business rules and structure for well-formed EDI documents? One simple approach is to have an XEDI translator as an intermediate step.
When converting EDI to XML, the translator uses the X12 data dictionary to transform an EDI message into an XML document. Once the EDI message is represented in a well-formed XML document an XSL
style sheet may be applied to transform the document into HTML for display on the web, or the XML document can be passed directly to another application system.
When converting XML to EDI, the translator will not only function to convert an XML document into EDI, it’s X12 data dictionaries will ensure the XML document is compliant with a well-formed
EDI message. You will be able to apply business rules for your translation process to ensure the information you pass to your EDI translator is complete and accurate.
Leveraging an EDI-XML translator follows XMLSolutions concept of leveraging over 300 well-formed EDI documents for EDI conversions. Keeping the semantics of current EDI document structures
allows companies to extend their existing EDI infrastructure without having to change or throw away 20 years of well thought out technology.
The Savings of XML-EDI
A large company can accrue significant savings from employing an XML-EDI approach rather than replacing EDI with XML or building an XML system independent to the existing EDI system. First, there
are the savings in money. Companies have spent millions on building their EDI systems. The system works. Why throw that investment away?
More specifically, large companies have spent a lot of effort on mapping and interfacing EDI into their existing legacy or ERP systems. These mappings are very complex and must be very reliable,
thus they are very expensive. To implement an XML e-commerce system independent of their EDI system means that these companies would have to build a second mapping interface. By employing an
XML-EDI system, companies can use their existing mapping interface into their existing legacy or ERP system.
There is also the savings of time. By using the XEDI approach, companies have immediate access to more than 300 types of XML-based trading documents, from purchase orders to ocean waybills.
Beyond EDI-XML
EDI and XML working together is a first step. The objective of e-commerce is to eliminate manual processes by allowing the internal applications of different companies to exchange information
directly. Stated more generically, e-commerce is a case of systems integration (sometimes called legacy systems integration) that crosses the boundary of the enterprise. XML standards for
e-commerce and EDI are just means to this end.
The current proposed standards are not the end of this evolution. What happens when we are able to deal with business processes or workflow between trading partners, something EDI and the current
XML proposals cannot yet handle? What about those few trading partners who may never automate e-commerce systems yet will need to be recognized and accepted as well?
Eventually, a framework will arise to handle EDI and XML, as well as the manual and future workflow. It is possible for them all to operate in peaceful coexistence. National and international
commerce will be the beneficiaries!