With supply chain platforms providing the E to E linkage and Managed File Transfer Services- do VANS still play a role? The pros and cons of VANs, AS2, FTP, Electronic Commerce Communications Providers. We will be evaluating TRANSPORT, not mapping,  Web portals, or other services which could be performed by a VAN as well as by other EDI service providers.

I approached Alan Wilensky, who is the policy and industry relations expert at Loren Data Corporation's ECGRID.  Alan supplied me with a “position paper” from Todd Gould, the president and chief engineer. Todd Started off by describing: What is a VAN?; What is an EDI Service Provider?, and What is ECGRID?

If you look at the following chart you will see that VANs, Service Providers and ECGrid all provide the identical services in the major categories.

	VAN	EDI Service Providers	ECGrid®
Multi-Tenant Mailboxing	✓	✓	✓
End-User	+	+
Service Provider	+		+
Data Validation	✓	✓	✓
Mapping and Translation	✓	✓	✓
Software	+	+
Web Forms	+	+
Service	+	+
Third-Party	+		+
Standard EDI Document Routing	✓	✓	✓
Interconnects	✓	✓	✓
Peering Agreements	+		+
Transit Agreements		+	*

Certainly, we all can come up with more items that are provided by many or most VANs and Service Providers, but I think we can agree they would be added equally to both lists.

In all our analysis at Loren Data since 1999 when we originated the concept for ECGrid, the only difference we can find between VANs and Service providers is that a VAN maintains its own Interconnects while an outsources its Interconnects (from VANS).

From an end-user standpoint, there is absolutely no difference between a VAN and an EDI Service Provider.

In the subcategories, where there is little difference to the end user, is where the differentiation between each is seen. It is quite notable that when combining a Service Provider with ECGrid, the subcategories exactly match the VAN!

This chart highlights the most pressing issue in the VAN/Service Provider model for EDI today:

ñ The only difference is between VANs and Service Providers in that EDI Service Providers require an up-stream provider for their Interconnects.

ñ The only difference between a VAN and ECGrid is that VANs sell their services to End-Users and Service Providers, while ECGrid only sells its services to Service Providers.

VANs and EDI Service Providers compete for the same customers, yet the Service Providers are dependent on the VANs for their up-stream Interconnects! Let me paraphrase that: Other than ECGrid the only way a company can enter the EDI market is either:

1. Convince an established competitor to accept an Interconnect (becoming a VAN)
2. Purchase Interconnect services from a competitor (becoming a Service Provider)

Todd concludes with a discussion of How Do I Become A VAN? His conclusion is that you would be better off to become an EDI Service Provider.

Next I had an extensive interview with Alan. He questions why we have perpetuated the VAN industry when better alternatives are available. They are a carryover from when telcomm costs were higher. Existing VANs: EasyLink (a.k.a. AT&T) , Sterling (IBM), GXS.  NuBridges and SoftShare were sold to Liaison Technologies . SAP bought Crossgate. 50% to 60% of VAN traffic is on GXS. VANs were originally resellers of  AT&T services. TWX (Telegraphy) was regulated, but VANs were not because the FCC regarded them as Internet services.

In truth VANs are not as secure as other alternatives. As an example, a VAN can “read the mail” and use this knowledge to market new companies for their networks. Additionally, they do not have any automatic reject notifications. Plus there are many other deficiencies since the technology is over 20 years old.

AS2 signaled the beginning of a “VAN exodus. New era companies avoid a VAN. Both VANs and Service Providers are providing new products. ECGrid handles transmissions for many companies, such as SPS Commerce. GXS has a “Trading GRID”. HubSpan is “Enterprise 2000”. Seeberger is building its own connections and does not want to use a VAN.

*  There is an on-going legal action between ECGrid and GXS. GXS purchased the IE service from IBM and renamed it as a premium VAN called TGMS (Trading Grid Messaging Service). GXS has denied interconnects with ECGrid. This court case is currently in the US Court of Appeals in Richmond, Virginia and has granted oral arguments. But what is really behind this interconnection denial is that the VAN industry is not the cash cow it once was. The “gravy is gone”; all the big trading hubs are on line already; the traffic is way down.

For EDI to continue to grow, it is said that there must be more interoperability and collegiality between network providers ----- the network must expand and provide more features, lower costs, and increase the ease of entry for new Enterprise 2.0 innovators, B2B, SAAS, PAAS, and any OEM Software vendor seeking to add native communications to their solutions.

Alan concluded his appraisal of the traditional VAN with a quote from Jim Morrison: “This is the end, beautiful friend“

Then I asked Todd some specific questions and got some great answers:

EC-BP: How does “Web EDI” versus “traditional” EDI fit into the current “revolution” against the VANs?

TODD GOULD: In 2000 Web EDI was a revolution against the VANs; today it is part of the standard mix. In the technology adoption life cycle, Web EDI was barbarians at the gate of the old guard. In time, it became a standard part of everyone’s offering. There is no longer a “versus” but a symbiotic relationship between the two.

However, all it  ever was was a stop-gap measure; Web EDI is little more than “electronic paper.” It allowed those who could not or would not invest huge sums of money into an integrated system to satisfy the needs of their major trading partners requiring EDI. Without the ability to integrate, Web EDI is a more expensive, less ubiquitous fax machine.

Be that as it may, it revolutionized EDI and brought the Internet to the forefront of EDI. I can still remember articles in EDI World stating how the Internet could never support the mission critical nature of EDI. I laughed then, and everyone laughs now.

EC-BP: What other “forward thinking ideas” are on the horizon?

TODD GOULD: As always in technology it seems we move back to the future. What we now call cloud computing is just a new way of selling time sharing. With EDI the holy grail is end-to-end integration. Standards like X12, which were rightfully maligned as not being standard, are really interesting to look at with 20/20 hindsight.

X12 created a framework and nomenclature for major hubs to develop their business documents and communicate these “implementations” to their trading partners (spokes). The problem was each one was different and ultimately a huge burden and expense for the spokes to implement. Frankly, each of these major hubs could have just as easily developed their own formats and told their trading partners to figure out how to import and export those. The amount of work for the spokes would have been about equal and probably less expensive.

What looks hot to me is standardized implementations. The common way to look at X12 is as “the standard'” and the implementation guides as a subset. To me, X12 is a very complex instruction set and each implementation is a unique way of using it. What I would like to see is a much simpler set of implementations for each document type that 99% of the companies could use, for example a simple 850 purchase order or a simple 810 invoice. Multiple companies can write to the same simple implementation allowing rapid adoption of these business documents by smaller hubs. For the 1% that need the more complex documents, they are free to use them, but the rest of us could focus on enabling more businesses and growing the market.

EC-BP: What is the answer to the current “Directory Services” issue that stymies movement between providers by “locking them in”?

TODD GOULD: The lack of a shared routing table between VANs is a nuisance and does cause migration problems; however, it is not what causes the “lock in.” That is caused by bad behavior of certain VANs which block all attempts at a free market. I’ve seen first hand refusal of a VAN to allow an ID to move to another network; I’ve seen a VAN charge a company $1,000+ in order to release their ID; and I’ve also know of a VAN that flat out told a company that if they move their IDs to another network, they will refuse to route their data to their trading partners on that VAN.

The lack of a Directory Service helps create a different type of lock-in. By the lack of communications, directory and routing standards, it is very difficult for any new companies to become VANs. Add this to the fact that the largest player in the VAN industry is using Interconnects to pick and choose who may compete both as peers and as service providers over transit agreements, we have a very dysfunctional market.

Ultimately, the cure is to create enough demand for a new, alternative network that the old system becomes irrelevant. This will not happen in the current market of major hubs and supplicant spokes. However, in the emerging midrange hub market there is a significant demand to move on to newer, better and less costly technologies and practices. The crossover of need to connect to the legacy, traditional VAN market is the biggest obstacle; however, it is already becoming less relevant.

EC-BP: How have things changed since the growth of Cloud computing?

TODD GOULD: I would like to say that there are some amazing things going in EDI because of the growth of Cloud computing, but EDI actually lead the way into Cloud computing,  before it even had this name. From the days of time sharing, to ASPs to Web EDI, to full blown API infrastructures, nothing is more Cloud than EDI.

Some other blogs that we have written include An unusual WebSite on WHOISEDI ; What Will It Take to Create the Perfect EDI Directory? ; Should My Client Start A New EDI VAN?