Embedded EDI? Native EDI? EDI as a bundled feature of each and every SAAS platform? Why not?
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:
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:
- Transit Methods-leased lines and modems may be long gone, but the routing legacies are still in place.
- 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?
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 have sat in numerous meetings with upper level management of the largest VANs and I keep hearing the same things:
- Interconnects are a necessary evil
- Precious resources are spent supporting connections to our competitors
- Kilo characters provide lower and lower margins
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.
“A wave of on-line accounting systems offering free and low-cost GL services are now looking into ways that will provide EDI like services, standardized docs and (most important), ways to peer up partners that bypass the VANs and metering fees. Why?
- These harbingers of the new world of commerce have large, connected user populations,
- They are adept at API based system to system communications
- They are nonplussed at the inertia of classical VANs and supply chain commerce
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:
You can see the actual API methods here: ECGridOS