There was a recent discussion on the history of EDI on the EDI-L blog. Amazingly, several commented that EDI began in 1948 with the Berlin Airlift. Here are some comments posted by Klaus-Dieter Naujok:

"I agree with you that one could argue about the first EDI message(standard) for some time, so let's all agree with recorded history that the first EDI exchange took place in 1948 during the Berlin Airlift, where the task of co-ordinating airfreighted consignments of food and consumables (which arrived with differing manifests, languages and numbers of copies) was addressed by devising a standard manifest. As far as I know the standard was never publicly published."

"In the early 1960 the rail and road transport industries started to engage in what we call today EDI exchanges. This let to the formation of the Transportation Data Coordinating Committee (TDCC) in 1968. In 1973, the TDCC decided to develop a set of standards for EDI between companies and to invent a so-called "living standard", .ie: a standard that included standards on how to change the standards! This resulted in the first inter-industry EDI standard in 1975 covering air, motor, ocean, rail and some banking applications. What evolved included generic formats for general business ANSI X12, first published in 1981; a WINS format for the warehouse industry; and a UCS format for the food and drug industry; and for TDCC. European development of TRADACOMS, ODETTE and JEDI started around 1984."

The Lost Railroad Cars

Then Pete Austin from Axiom-Systems elaborated:

"Another piece of trivia for you."

"The rail industry got into the business because they kept losing railroad cars. I know, how in the world does a flatcar on siding 13 in Omaha have to do with X12? Watch. They kept losing railcars and devised a way to find them all. They painted bars on the bottom of their cars in a well defined coded manner (yes, early 'bar codes'). Then they started burying readers under the tracks. By reading the trains passing overhead, they now knew what cars were where/when. Now if only there was a way to communicate this information back to corporate......"

Doug Anderson, Vice President of Sales Support at Kleinschmidt noted:

"I believe TDCC published the first Electronic Data Interchange standard specification for general usage (motor, rail, ocean and air) in 1975. However, the TDCC began their work in 1968 and produced various drafts between '68 and '75. In addition, both rail and motor carriers were testing those drafts during that time period."

"For the motor carrier industry, the first major implementation of the draft EDI standard was 1975 when P.I.E. (then Pacific Intermountain Express) and GM implemented freight billing. In 1976 E.I Dupont and Chemical Leaman (a bulk chemical carrier) did the same with the published standard."

Transaction Sets July 15, 1975

The initial list of transactions was supplied by Ralph Notto from his notes for his book "Challenge and ConSequences":

The first EDI Standards publication included 42 transaction sets. These pertained to air, motor, ocean, and rail transportation and to payment, administrative, and control information. Of these 42, 16 were still in use by year 2000, but may have been enhanced.
Identifier-Title

104-Shipment Information (Air)
105-Container/Equipment Transfer (Air)
107-Shipment Information for Export Declaration (Air)
108-Shipment Information for Import (Air)
109-Shipment Information for Equipment/Delivery Order (Air)
110-Freight Details and Invoice (Air)
111-Freight Details and Invoice Summary (Air)
113-Inquiry (Air)
114-Shipment Identities and Status Reply (Air)
115-Status Details Reply (Air)
116-Repetitive Pattern Maintenance (Air)

204-Shipment Information (Motor)
205-Container/Equipment Transfer (Motor)
206-Shipment Pick-up Order (Motor)
207-Shipment Information for Export (Motor)
208-Shipment Information for Import (Motor)
210-Freight Details and Invoice (Motor)
211-Freight Details and Invoice Summary (Motor)

300-Reservation (Ocean)
301-Confirmation (Ocean)
302-Container or Specialized Equipment Pick-up Order/Cancellation (Ocean)
303-Cancellation (Ocean)
304-Shipment Information (Ocean)
305-Container/Equipment Transfer (Ocean)
307-Shipment Information for Export (Ocean)
308-Shipment Information for Import (Ocean)
310-Freight Details and Invoice (Ocean)
312-Arrival Notice (Ocean)
313-Inquiry (Ocean)
314-Status Details Reply (Ocean)
315-Status Details (Ocean)
316-Repetitive Pattern Maintenance (Ocean)

404-Shipment Information (Rail)
407-Shipment Information for Export (Rail)
408-Shipment Information for Import (Rail)
410-Freight Details and Invoice (Rail)
411-Freight Details and Invoice Summary (Rail)
416-Repetitive Pattern Maintenance (Rail)

900-Payment Authorization
901-Completed payments-
995-Advisory Information
999-Acceptance/rejection (Subsequently replaced by 997-Functional Acknowledgment)

And finally Rachel Foerster of Rachel Foerster & Associates Ltd added:

"And of course, we all know that it was Ed Guilbert that was actually the father of EDI as we know it today as a result of his role in the Berlin Airlift and further work in the U.S. DOT."

"My copy of the EDI Forum Founding Issue has several articles written by Joe Carley, Ralph Notto, Buddy Bass, among others sheds light on this question In Buddy Bass' (Earl J. Bass) article about John Nelsen he indicates that it was Conrail and the Missouri Pacific railroads that provided the first ever demonstration of the TDCC EDI standards when they exchanged the Waybill Data Exchange transaction between them in 1978."

Several weeks ago, I was asked by a Global Ecommerce Manager if he should convert their traditional EDI transactions into ebXML. One of his technical guys thought ebXML was the wave of the future.

To my knowledge, ebXML never developed business payloads, so I posed the following question to Mike Rawlings (President of Rawlings Consulting, participant on the ebXML committees): "Did ebXML ever develop complete business standards for PO, invoices, etc? As best I can tell, there was a feable effort to develop some invoicing standards, but the effort died out. Is this true?"

Mike's email response on Dec. 27, 2006:

"No, ebXML, per se, didn't develop XML schemas or DTDs for common business documents - those things were beyond our scope. The OASIS UBL TC has developed a limited set of schemas for supply chain documents based on drafts of the CEFACT core components spec. To my knowledge CEFACT hasn't yet published any schemas but they're still working on it."

For more info on ebXML, visit Mike's website for a 5 Year assessment of ebXML: http://www.rawlinsecconsulting.com/ebXML/ebXMLatFive.html

My question to the manager: "What is the business case for converting? There are no standardized business documents. Does his technologist think there are? Is he suggesting changing to a new enveloping structure? What is this buying you?"

He has outsourced his mapping and transactional processing to a provider that supported the ebXML enveloping protocol, traditional VAN processing, AS2 and other communication protocols. ebXML has evolved to simplistically one of the routing protocols for the transport of data through the internet. You can send traditional EDI data in an ebXML wrapper or convert to one of the emerging XML standards such as OAGi.

The business payload such as purchase orders, invoices and advanced shipment notices are not defined in ebXML, but in other standard bodies. The OAGi Group (not to be confused with the above mentioned OASIS group) is agnostic about the enveloping. Dave Connelly, CEO of the Open Applications Group, Inc. makes this case in the White Paper entitled "A Business Case for a Canonical Model". ¹

In conclusion, my recommendation is not to disrupt your very strategic EDI order management or supplier management models to migrate to an questionable XML standard. I presume his technologist was hoping the change would develop a web services model.

So is Web Services just all hype?

No, not at all. This very exciting business proposition is best described in the Kevin Kelleher's article in the July, 2006 WWW.Wired.Com publication:

"One day in 1995, Marc Benioff, then a senior VP at Oracle, was trolling a new Web site called Amazon.com. He clicked on the Buy button, and a thought struck him: Applications on the Web were the opposite of Oracle’s bloatware. They executed transactions through a simple interface that was available to anyone on the Internet. Web standards made it unnecessary for customers to install, upgrade, or maintain anything but a browser and a TCP/IP connection. “I thought, ‘This is amazing,’ Benioff says. “I saw the power of an open-standard platform".

"Benioff waited a few years for the Internet to mature and made his move. In 1999, he cofounded Salesforce.com, which delivers business software through a browser window. The company went public in a $110 million IPO in 2004. Today, revenue is growing by more than 50 percent annually, and giant rivals like Oracle and SAP are mimicking Benioff’s strategy."

Powerful stuff indeed.

To read the entire article visit: http://www.wired.com/wired/archive/14.07/economy.html

My recommendation: expose your technical team to web services concepts, but not select your strategic EDI-based order or supplier management processes for this education.

REFERENCES ¹Available Jan. 2nd, 2007 at Page 26
http://www.openapplications.org/downloads/whitepapers/whitepaperdocs/2005%20A%20Business%20Case%20for%20a%20Canonical%20Model.pdf