Standards for the next generation of automated electronic commerce.
Electronic Data Interchange (EDI) is the standard mechanism governing the exchange of business transactions between computers and applications. The benefits of EDI are no longer limited to saving administrative costs by reducing the rekeying of data. EDI now offers the real opportunity of creating large virtual organizations. Like schools of fish, these virtual organizations appear as a single large organism, but in truth they are a multitude of individuals moving together in close harmony. EDI allows individual organizations to link their internal software applications to one another to form what appears to be a single integrated system. From point of sale through automated inventory control, the great majority of large retailers already use EDI with their suppliers to keep the shelves full and the warehouses empty.
HTML made the World Wide Web a reality by defining open multimedia formatting standards that can be interpreted by browsers. Just as HTML (and its larger cousin SGML) defines form, the EDI standard provides the format for encoding content. The purpose of an EDI message is not to communicate information between people, but between software applications. While traditional EDI is quietly revolutionizing the corporate back office, new open EDI standards are poised to automate electronic commerce over the Internet.
EDI is breaking free from high cost, value-added networks and joining the Internet to create the second wave of electronic commerce. This new wave focuses not on retail sales, but on forging electronic trading partner relationships in the pursuit of the creation of the virtual enterprises of the future. Who knows? The next breed of Internet users may be the EDI-based software applications themselves.
If we take a global view of electronic commerce we can see three communication patterns: person to person, person to application, and application to application. (See Figure 1.) Telephone, fax, and electronic mail are used in person-to-person communication, and, of course, the World Wide Web is the ultimate large scale person-to-application interface. This leaves application-to-application communication to EDI.
While there is continuing debate over how many millions of Internet and Web users there really are, users do not need to be told that the use of the Internet is growing faster than network bandwidth; deteriorating Internet response time is a good indication of the problem. One of the common ways of resolving bandwidth problems is batch processing, and while this may not be appealing to consumers hooked on interactive systems, most of the business-to-business requirements can be satisfactorily met through batch processing systems. As electronic commerce gets into full swing, users may find that it is less frustrating to let their computers browse the Internet on their own. To do this with any degree of success, users need data formatting and encoding standards to allow widely different software applications to work together.
Exchanging information between software applications is neither difficult nor new. Import and export functions are often integral parts of software applications and as such would come under the definition of proprietary EDI. These proprietary standards may be extremely efficient, well-known, and even in the public domain, but they remain proprietary, under the control of a single organization with no set procedures for publishing, requesting, or processing changes. Standards-based EDI simply creates an "open" structure for the exchange of information between systems. Standards are not known for their technical excellence or efficiency, but for the common ground they create between competing organizations. Standards are the necessary foundation of any wide-scale technology implementation; in a complex environment, standards provide the essential connectivity between different systems creating "open systems."
With tens of thousands of companies using EDI on a daily basis, it is a mystery that EDI remains so misunderstood. Bill Gates in his recently published book "The Road Ahead" (Viking Penguin, 1995) makes the common mistake of referring to EDI as "Electronic Document Interchange." The "D" in EDI stands for data and not document; true, the difference is subtle, but nonetheless significant. People exchange documents; software applications process data. In computer terms, however, a document is nothing but a structured collection of data elements, so perhaps the error is forgivable.
The more accurate definition of EDI is: An electronic commerce standard for the exchange of processable business data between software applications. Both the American and the International EDI standards are very similar in that they are made up of a syntax and directories containing the structures and definitions of hundreds of database tables, thousands of database fields, and tens of thousands of codes grouped into hundreds of business models.
A common example of EDI is the exchange of purchase orders and invoices. Each side imports and exports data as EDI messages, and views the data from the familiar perspective of their own order entry and accounting applications. However, these applications may represent the same data very differently. This transfer of data is made possible because both applications are mapped to the standard. Although it is still common for the application-to-EDI interface to be custom programmed, the need to keep pace with an ever-changing standard led to the development of generic EDI translators. In their most basic form, these translators convert mapped flat files to and from an EDI message.
A typical EDI data stream consists of an outer envelope or interchange control delimited by the tags ISA and IEA, an inner envelope or functional group delimited by the tags GS and GE, and the actual transaction set defined by the tags ST and SE. The data element separator is defined as the first character following the ISA tag. The example in Listing 1 uses the character * (asterisk). Blank spaces are only significant in the header and in this example they are denoted by the character b. (Details of the syntax or application control structures for the American National EDI Standard ASC X12 are defined in X12.6, and the interchange control structures are defined in X12.5. The syntax for the International EDI Standard is contained in ISO 9735).
Listing 1 shows an example of an EDI data stream. The 810 code following the ST tag defines this data stream as an invoice. Decoding an EDI message is not really difficult if you have access to the data dictionaries. As an example, if you look at the first N1-N4 block, this is obviously an address but the code BT in the first position of the N1 segment is key; it contains the code for the "bill to" party. The second N1-N4 block contains the code ST for "ship to," and the third N1-N4 block contains the code SE for "remit to." Simple, really.
The EDI standards are designed to be generic and, with rare exceptions, only a subset of the standard is actually used between two trading partners. This subset is referred to as an EDI Implementation Convention or Implementation Guideline. Most commonly developed by industry groups, these implementations freeze a version and release of the standard and define exactly what data is required and where specific data is to be mapped in the standard. EDI Implementation Conventions are the life blood of EDI; they define what must, and what may, be included in an EDI message. Implementation conventions also include the procedures for the exchange, acceptance, and rejection of EDI messages between the trading partners.
While it is often difficult to create an EDI message without knowledge of the specific requirements laid down in an implementation convention, parsing an incoming EDI message to a database is within the means of most database programmers. The difficulty, if any, is in mapping the EDI database into the required application. Converting an EDI message to a screen display or a printed report is not too challenging, but unless the target application has a clearly defined import data structure, appending data to application files can be an interesting and time consuming project. Luckily there are a number of excellent data mapping software packages on the market, and an even greater number of consultants to help resolve any problems.
To get started with EDI, you must master the language of EDI, where transaction sets or messages are business forms, data segments are database tables, and data elements are data fields. It is not difficult to see that the EDI standards are a unique reference of tried and tested models of business data, complete with definitions. Perhaps one of the reasons EDI is not as well known as it should be is that it remains a closely guarded secret of many professional database designers.
Bill Gates goes on to state in his book that EDI "allows companies that have contractual relationships to execute specific kinds of transactions automatically. Dealings are highly structured -- reordering products or checking the status of a shipment -- which makes conventional EDI unsuitable for ad hoc communications, although many companies are working to combine the benefits of EDI and email into a single system." Although essentially correct, Gates' simplistic analysis seriously underestimates the true potential of EDI as the driving force behind electronic commerce. In view of Microsoft's initial assessment of the Internet, this may not be as surprising as it should be.
When all is said and done, one or more EDI messages make up a file and it is this file that is exchanged between trading partners. As the number of EDI trading partners increased, dial-up connections rapidly became the more economical solution, and this was inevitably followed by the natural advantages offered by store-and-forward networks operated by third parties. Where store-and-forward was the primary function, a number of the networks added trading partner directory management, authentication of origin, archiving, delivery notification, EDI syntax verification, and even conversion of EDI to faxed pages.
Like all network providers, a major part of the provider's value resided in the creativity of their billing practices, from character or segment count to the actual value of the transaction to flat-rate charge per transaction and any combination between. In the same way that the Internet redefined both email costs and network connectivity, it is redefining the cost and connectivity of EDI value-added networks. There is little doubt that the Internet is the ultimate low-cost, global, value-added network.
Although the Internet is without a doubt the universal email network and EDI is no more than electronic mail between applications, there is still one major weakness in the Internet that is holding back wide-scale use of EDI over the Internet. EDI messages carry with them commercial meaning, and in business it is desirable to know who is on the other end of the line, and to be able to prove, should it be necessary to do so, who sent the message. This is called "nonrepudiation." However, as you read this the problem may be solved as the issue is being addressed by the of the MIME (Multipurpose Internet Mail Extensions) protocol. However, EDI contains tailor-made solutions for digital signatures, authentication, compression, and encryption. (These are detailed in Standards X12.56 and X12.58.)
HTML is an extension of SGML and, like EDI, is based on the use of tags to identify data. The difference lies in the definition and use of the tags. In both HTML and SGML the tags are used primarily to address issues of data formatting and, of course, the hypertext jump. On the other hand, EDI disregards format and focuses solely on encoding content. You could use SGML tags to encode content, but it is unlikely that you would be able to get these tags accepted as part of the standard, just as you would find it difficult to get the EDI standards committees to agree to assign segments or codes for formatting data (it has been tried).
With most back-office information systems using EDI as the preferred data stream, it makes sense to address the issue of the data stream formatting at the source rather than to take a step backward and hard-code parsers for proprietary Web data streams. For simple forms this is not a problem, all that is required is a little planning to incorporate the EDI standards into the design. What quickly becomes obvious, however, are the limitations of HTML as a data-entry design tool. Anyone who has designed a data-entry form knows that the secret to getting all of the input boxes filled correctly is to ask the right questions in the right order with a liberal use of look-up tables. HTML may have many useful qualities, but a form design tool it is not. Java appears to hold the answer with its ability to code complex forms. However, the answer to a Web designer's dream is a tool that converts EDI formats to Java applets. I have no doubt some are being developed. (TradeRights has one, and so does Premenos, a developer of EDI translation software). I suspect most EDI translator companies are working on one.
If the Internet is the road, HTML servers are the destination, and browsers are the vehicles to get us there. The problem with today's browsers is that they require people to drive them. With Java-enabled browsers we will be able to read and write EDI formatted messages, but the real dream is to be able to switch on the autopilot, key in the settings, and let the computer navigate while we sit back, relax, and look at the scenery. The future may be closer than you think; I foresee EDI servers complementing Web servers within the next few months.
ISA*00*0000000000*01*01*PASSWORDME*01*123456789bbbbbb*9 87654321bbbbbb*890714*2210*U*00204*000000008*0*P*: GS*IN*012345678*087654321*900509*2210*000001*X*002040 ST*810*0001 BIG*900713* 1001 *950625*P98932 N1*BT*ACME DISTRIBUTING COMPANY N3*P.O. BOX 33327 N4*ANYTOWN*NJ*44509 N1*ST*THE CORNER STORE N3*601 FIRST STREET N4*CROSSROADS*MI*48106 N1*SE*SMITH CORPORATION N3*900 EASY STREET N4*BIG CITY*NJ*15455 PER*AD*C.D.JONES*TE*618555823 ITD*01*3*2**IO ITI**3*CA*12.75**VC*6900 ITI**12*EA*.475**VC*P450 ITI**4*EA*.94**VC*1640Y ITI**I*DZ*3.4**VC*1507 TDS*5111 CAD*M****CONSOLIDATED TRUCK CTT*4*20 SE*21*000001 GE*1*000001 IEA*1*000000008
Listing 1 shows an example of an EDI data stream. The 810 code following the ST tag defines this data stream as an invoice.