From the notes and musings of Todd Gould, President of Loren Data Corp,:”There is a great opportunity for EDI to become an embedded technology; if I didn’t see real potential, I would not be steering Loren Data in that direction”.

Todd, (one of the true experts in commerce data transit), expands upon the subjects handling commerce data transit directly via an open EDI Web API is a good idea.

The masked analyst will attempt now to provide some background, so here we go:

The whole business of system to system data carriage is a hodgepodge of legacy and modern methods.

Lets put aside the IFR (EDI documents) for a moment, and concentrate on the carriage. Believe me, we will have plenty to say about data interchange very soon, but the issue as it stands is fairly settled.

System to System communication of commerce documents between trading partners is an old business, predating the open internet by decades. A historical recap of dedicated networks (VANs) is beyond the scope of this article, but suffice to say that the EDI industry retains any number of legacy practices and relationships:

1. Transit Methods-leased lines and modems may be long gone, but the routing legacies are still in place.
2. Almost 100% of pre-Internet EDI traffic was carried over private WANs. Now, commerce networks are virtual, where IP  routing via secure methods predominate. There are peer=to-peer methods, hub and spoke, etc. The point of this observation is that generalized data carriage is a commodity, whereas for some reason EDI is treated differently, or rather never made the jump to the universal ubiquity of Web and email traffic.For those who argue that commerce documents are special and require a level of traceability, I ask the followingQ1: Are a CEO’s email or Text Messages more or less important than an X12 Shipping notice?
   Q2: There are protocols routed over Http that are used for mission critical enterprise systems. Are these more or less critical that any one EDI document?

   Answer: All of these message classes are critical, but one need not contract for special peering with a private provider to secure special routing. The security of SOA (service oriented architectures) and email are attained by encryption and certificates. Modern VANS use Internet routing for the special traffic they carry for trading partner peering and routing.

   Both questions actually devolve to one big question about EDI:

   Q: Why is EDI a  special case? Why is EDI not subject to universal addressing via DNS or URI name-spaces? If email, SOAP and REST traffic is fine with mission critical enterprise messaging over port 80, why not X12 messages?

   Why are EDI communications not treated like any other secure internet traffic? Why are trading partners walled off from one another, without open routing? When was the last time you had to ask whether your mail could reach another ISP subscriber? When you pick up the phone, do you concern yourself with what phone network or long distance carrier you are using to call a friend?

All of the above is where the Web and the world of EDI part ways. CEO’s and children expect email to reach it’s destination, but Supply chain managers need private networks. Why?

Legacies

Value added networks (VANs) provide that essential mix of expertise, integration of large systems, and communications. By predating the Internet Era, they have built a legacy tying together trading partners via the essential services triangle, but have not wholeheartedly participated in the revolution of open routing, peering, and standardized services.

VANs are essential as powerhouses of commerce IT, VANs are some of Loren Data Corp’s best clients for routing and data transit. Todd Gould is carrying a message to his partners across the EDI industry that it is time to standardize routing and protocols for open EDI transit:

I interpret his gist to say, “federate and standardize your communications and internetworking functions, build higher value services that address the core of client commerce functions”. Todd also suggests that the industry embrace VAN interoperability with a standard set of web services that conform to best practices. Loren Data has taken these crucial first steps by introducing ECGrid OS.

“I am convinced that it is time to shift VAN architecture. Let’s create an infrastructure that embodies our best aspirations, by automating the process of interconnections and moving to an integrated routing environment.”, says Todd. Amen.

The masked analysis is as follows:

The movers and shakers of the industry – developers, VARs, Systems integrators, etc., all want to have the advantages and accountability of EDI transit, but will hardly tolerate metering models from the smokestack era. ERP system bosses are ready to vote with their wallets for a directly invokable EDI commerce service. The new kids on the block are going to go their own way if the EDI industry does not act. The exodus has begun.

So the masked analyst asks his colleagues: Is this anyway to run an industry? We can provide better services, embrace modern architectures (Web Services for interconnections and routing), and bring value with our skills, where added value actually thrives, and not by protecting trading partner ID’s and cultivating KC’s. So says the masked analyst.

Todd also added:

“Following in the footsteps of telephone communications and banking, we need a central clearing house for interconnect traffic, a central routing registry, and a process to configure fully automated access points.” Mr. Gould is proposing an EDI industry summit for Value Added Networks and other Electronic Commerce Service Providers for the Winter of 2009. Lets hope that his inspired vision is shared by like minded leaders and professionals within the community of supply chain commerce. We can come together to create a new and open world of EDI.

You can see the actual API methods here: ECGridOS