EDI, Take It and Leave It

August 4, 1999

Alan Kotok

XML can learn valuable lessons from the EDI experience, as well as leave some its baggage behind. First, the lessons:

Data exchanges need predictability. Enterprises receiving data from trading partners need to know the format of those data coming down the line. EDI presents a predictable format that enables trading partners to know with certainty the contents of the data stream. In the X12 manifest/ship notice transaction set, for example, the detail segments begin with a hierarchical level (HL) segment, followed by an item identification (LIN) segment, and so on. Exchanges using XML need no less certainty.

"When companies go from hard copy to electronic transactions, they lose one of the basic means of tracking business activity—through human eyes."

Identify everything. With EDI, everything is identified uniquely -- each trading partner, each location, each transmission, each product, each shipment, and sometimes each unit load within a shipment. It seems obvious, but when companies go from hard copy to electronic transactions, they lose one of the basic means of tracking business activity -- through human eyes. As a result, all of the tracking of transactions relies on the same systems used to send, receive, and process the transactions. Therefore, one needs means of tracking the transactions, and elements of the transactions, that are independent of the sending and receiving systems.

For example, one of the best practices employed with EDI is the use of the manufacturers' product numbers or stock-keeping units (SKUs) by all of the companies in the supply chain. This practice provides a straightforward way of tracking inventories throughout the chain, rather than interpreting different codes assigned to the same products as they flow from manufacturer to distributor to retailer to consumer. Unique identification also allows for accumulating data at a fine level of detail, which provides valuable raw material for forecasting future requirements.

Another example is the use of Data Uniform Numbering System (DUNS) numbers assigned by Dun and Bradstreet to identify trading partners. Most every company has a unique DUNS number for financial reporting and by using that number, trading partners have a common means of identifying each other. Some industry groups have company identifiers for other purposes, such as the paper industry's two-character company codes used in bar codes that become part of a unique unit number assigned to each roll of paper manufactured in North America. EDI transactions in the paper industry use this North American Roll Identifier to identify each roll of paper shipped from paper mills and used in printing plants.

Acknowledge everything. No good EDI transaction or XML transfer should go unacknowledged. Nor should any bad transaction or transfer either. Good X12 practice encourages use of a functional acknowledgment with each transmission. A functional acknowledgment that uses the transaction set number 997 tells the sender when the trading partner retrieved the message and indicates any X12 syntax errors.

"To explain the difference between functional and substantive acknowledgments, consider a functional acknowledgment as the equivalent of mimicry and substantive acknowledgment as conversation."

Good EDI practice also encourages use of substantive as well as functional acknowledgments. To explain the difference between functional and substantive acknowledgments, consider a functional acknowledgment as the equivalent of mimicry and substantive acknowledgment as conversation. Both acknowledgments send a message back to the sender, but one contains vastly more value than the other. An example of a substantive acknowledgment is the purchase order acknowledgment sent upon receipt of a purchase order. This transaction tells the supplier's understanding of the order and lists any exceptions to its terms or conditions. Another example is the receiving advice that lists in detail the items received, and any differences between the shipping manifest and the items unloaded at the receiving dock.

One XML vocabulary that puts a premium on identification and acknowledgment is the Information and Content Exchange (ICE) protocol used for syndicating content over the Web. While first considered a publishing application, ICE has found significant business uses with manufacturing parts catalogs and financial services. The ICE authoring group, an organization under the GCA Research Institute umbrella, takes great pains to identify the different parties in these exchanges. ICE also uses a request-and-response model so no transmission in the process goes without an acknowledgment.

"The real benefits from EDI have occurred when trading partners looked at the data they needed to exchange and stopped thinking of documents."

Think data not documents. Despite the idea of EDI transaction sets being modeled after hard copy documents, the real benefits from EDI have occurred when trading partners looked at the data they needed to exchange and stopped thinking of documents. Recent supply chain management initiatives use EDI transactions for exchanging much of the data needed for forecasting and replenishment of inventories, but they are based on an analysis of product and information flows not on current hard copy documents or EDI transactions for that matter.

When evaluating the flood of new XML vocabularies ask yourself if they have any basic data modeling behind them, or are they emulating paper documents? I find it interesting that one benefit of the new supply chain management experiments is the reduction and almost elimination of the purchase order. Yet, look at all the white papers on XML that use a purchase order as an example. Is this how XML plans to save the world?

EDI's other legacy. EDI may have some achievements to crow about, but it needs to eat a little crow as well.

"Organizations have little incentive to develop systems if the standards on which they are based change constantly."

The idea of EDI standards changing every year challenges the whole idea of standards. Organizations have little incentive to develop systems if the standards on which they are based change constantly. Standards should provide an element of stability and change only with the greatest reluctance. It requires standards groups to take the time to get consensus among the industries they serve and test the specifications before issuing the documents. You can fix bugs, but once you issue a standard stick to it, at least for a while.

XML will enable transactions to go room-to-room, not just door-to-door. The extended enterprise, as futurist Don Tapscott calls it, really exists today. The manufacturer of a product for example has almost as much stake in the customer's success as the customer itself. Why stop and start data transfers therefore at the respective company mailboxes? EDI may send data from one company to another, but the data flow starts much deeper in the organization and needs to go directly to where the trading partner uses the data. With XML, data can flow from an application in one company's system to its equivalent application with the trading partner.

"If any legacy of EDI needs erasing, it is the X12/EDIFACT dichotomy, which hangs like an anvil on the development of EDI systems."

An encouraging sign with XML is the international nature of the specifications under development. If any legacy of EDI needs erasing, it is the X12/EDIFACT dichotomy, which hangs like an anvil on the development of EDI systems. Companies in Kuala Lumpur or Kalamazoo should use the same set of standards for their business data exchanges. Period.