Most companies do EDI. And use one of the major VANs to do it. We don't think about VANs much. They just work. And make EDI possible. But change could be coming. What are you going to do about it?

Are you doing EDI? Seems like most everyone is. Ten (or is it 20?) years after a very important fellow declared that EDI was dead, it's still the circulation system of modern commerce. And the veins that keep that old blood moving are the VANs that we have come to know and love.

They take in our transactions, pass them on to one of their brother or sister VANs, and pick up the replies, all while maintaining security and backup. Set up of new documents and trading partners is done by the VAN, and once done you can forget about it.

EDI as we know it today rests on two strong legs: a single standard that you use to define your documents (and for most of us, that is X12) plus a single address that we send everything to and receive everything from (rather than having to define and monitor point-to-point connections ourselves). It's what makes it possible for a small company with limited staff to be able to get into the game. All you have to do is pay the bill at the end of the month.

And all of it is prefaced on one simple proposition: that no matter who you're trading with, your VAN will pick up and deliver your transactions to that partner, no matter who they use as a VAN. And that was a great assumption until a couple of years ago.

GXS vs. Loren Data—Two Out of Three Falls

Most of you who are in the EDI world know by now that GXS, the largest VAN on earth, has been shaking that model. And they have done that by targeting Loren Data.

Who is Loren Data? They are an interconnect VAN. Its customers are not end users like they are with GXS; instead, they're the EDI service providers who offer specialized web-based EDI translation services often oriented around a particular niche or industry. Loren Data's role was to help facilitate the interconnections between these service providers and the various big dog VANs.

The whole history of this dispute dates way back to the year 2000 and has many twists and turns on the bunny trail. Essentially though, GXS kicked off the battle by first refusing to accept an interconnect request from Loren Data and then accepting it but trying to bill Loren Data as if they were a customer rather than a VAN. Things went back and forth until GXS bought Inovis (who had been routing Loren Data traffic to GXS for a modest price).

At that point, Loren Data (on advice from the Department of Justice) responded by suing GXS under the Sherman Anti-Trust Act, and the suit wound its way through the court system before the Supreme Court refused to consider the case (probably because only one company was involved in the suit). When the suit was dismissed, GXS responded by demanding that Loren Data pay the GXS legal bill, pay all back charges for the years they transacted with Inovis, and agree to allow GXS to review all contracts and agreements that Loren Data had. If this was not acceptable to Loren Data, then GXS would totally cut them off on March 4, 2014. Given the facts that GXS is now size-wise the predominant VAN and that a ton of retail-oriented traffic flows from the service providers through Loren Data, it's hard not to agree with Loren Data CEO, Todd Gould, that this is "a coming train wreck."

Why Loren Data?

So why was Loren Data singled out as the target? Several reasons.

First, GXS has not been as profitable as the Francisco Partners had hoped, and their financial situation has stalled a hoped-for IPO. And GXS has lost customers over the last few years. Their feeling is that what they really need is the income that all of these EDI service providers are feasting on. There are too many of them to attack individually, but Loren Data is the throttle point where they can all be affected.

Second, the ECGrid messaging platform that Loren Data president Todd Gould developed had some major enhancements that were ideally suited to the emerging population of service providers. And when the ECGridOS was released in 2008, the set of APIs that it contained made things even easier, allowing the service providers to programmatically set up and maintain connections rather than doing it manually as GXS does. This was a major leap forward for VAN interconnections, and Loren Data quickly picked up a number of niche-oriented EDI service providers, including retail-oriented SPS Commerce.

And finally, Loren Data and the service providers who were affiliated with them made an unforgivable (to GXS) move; they began to drive down the price of EDI services, not something that GXS and its financial situation wanted to see.

As an apparent smokescreen, GXS has claimed that the issue is about daisy-chaining, the practice of sending EDI requests through a series of VANs until it finally reaches its destination. According to GXS, daisy chaining (and therefore Loren Data) is an obsolete model and GXS does not want to participate in it. While it is true that daisy-chaining as a network topology has its drawbacks and has been supplanted by a hub-spoke/star approach, daisy-chaining as a way to span varied service providers is still valid. After all, how would you do email if you didn't daisy-chain? Or get to web pages with no knowledge of who that site's ISP is? Until the entire world is supported on one network, daisy-chaining for message transfer seems to be a requirement, and the ability to do it and do it well is a litmus test for any modern network.

So Who Cares?

But you're not using Loren Data, right? So what do you care? Well, I think there are several reasons to be concerned.

First, Loren Data supports a lot of retail customers, SPS Commerce being one of the major providers that it services. Can you imagine the economic impact a major retail EDI disruption would have on the market and the economy in general? Seriously, man. My funds have just started to settle down and perform. I'm not going to be very happy if we get thrown into six to nine months of volatility.

Second, you say you don't use Loren Data's ECGrid? But are you sure? If you're trading via SPS Commerce, CovalentWorks, NetEDI, Energy Services Group, etc., you're using Loren Data's network and could be affected. Many times, companies are blissfully unaware of what VANs are involved at the interconnect level.

And third, you have to wonder what will happen if GXS is successful with this gambit. It doesn't take too much imagination to think that they might try it with other niche targets.

Is GXS likely to win this battle? Time will tell. They certainly might follow through on their March 4 cutoff, but will that break Loren and the service providers who use it? That seems less likely. So far, support for the ECGrid has remained solid, and Archie Black, CEO of SPS Commerce, has expressed his support for Loren Data. A much more likely scenario is that it will backfire on GXS, painting them as a heartless company that's more interested in crushing competition the old-fashioned way (that is, the way Machiavelli did it) rather than one focused on providing excellent value for their service (the way Robin Hood did it). But for every company who uses a VAN, the message is clear: the days of signing up with a VAN and forgetting it may be in danger.

And If You Are Directly Affected?

And if you are directly affected, what are your options?

You could switch from GXS to a VAN that's less confrontational, but switching VANs if you have dozens or hundreds or thousands of trading partners is not for the fainthearted. It requires a lot of work, a lot of manpower, careful timing, and almost certainly something will get dropped (that is, transactions in or out will be lost), resulting in customer service issues with suppliers and customers. And it's not something you can do on short notice. Switching from one VAN to another is like dating a really hot girl or guy; it's one thing to talk about it, but it's another thing to do it.

Or you could remove yourself from the VAN world and do everything with AS2. More and more companies have that capability, and AS2 is a way to do secure EDI with customers without needing a VAN. The downside? Scalability. Most places start with two or three AS2 partners and ramp up from there over a period of time. The problem is, AS2 is not a fully automated solution. Each connection is set up (and maintained) by hand, so when you have lots and lots of them it can get to be quite a burden.

You Know What We Really Need?

In reality, the VAN idea is one of the best things to come along since happy hour. You plug into it and you sort of ignore it after that. The downside, as our GXS-Loren Data kerfuffle illustrates, is that it relies on a certain amount of sportsmanship because each VAN owns its own DNS repository. And if they want to block somebody from communicating with them, they can.

Maybe what would be nice is a publicly owned (or member-owned) repository thingy that could be accessed by all parties equally. In essence, it would take the job of connecting VANs out of the hands of the VAN and place it somewhere else; in a common configuration, that would be both secure and open. I could be with whatever VAN I wanted and they could fondle and care for my transactions, but it wouldn't matter to them, nor would they even know what other VAN those precious little bits were going to. They would connect to this central repository, sort of a, ECGrid on steroids (without the 'roid side effects).

This is not a new idea. The concept of a Commercial Internet Exchange (CIX) model for EDI has been around for a while, and a good discussion of it can be found in Alan Wilenski's blog. Obviously, there would be a cost for this, and that would have to be handled somehow, either by bundling it into the VAN cost or having a separate bill for that entity. But I'm not really concerned with reality right now.

One of the biggest questions is, who would do that sort of thing? Probably here we're talking about either a consortium of major EDI players or else something government sponsored (although that sounds pretty scary when I say it out loud). The key point is that this entity would function independent of the VANs and probably should be restricted from taking or giving transactions directly to an end company. Otherwise, we would just be creating a super VAN that despite good intentions would eventually embrace the dark side and become evil in an EDI sort of way.

The Wild Card

Will GXS really impose this blackout? At this point, they're sticking to their deadline, but I've been told that some GXS customers who would be affected by it have received letters from GXS telling them not to worry, that everything will be OK. So what does that mean? Is GXS bluffing? Generally, you don't tell people that you have a two, a four, a six, a nine, and one queen, but one does wonder.

The wild card here, of course, is OpenText. Their acquisition of GXS was finalized on January 16, so they're in control. Will the OpenText leadership step in here and adopt a more "can't we all just get along" approach? If so, then OpenText needs to break their silence soon in order to garner a real publicity bump. Waiting until March 3 will not buy them much.

And if they back off, what does that say about the future? With the acquisition of GXS, OpenText will have five big VAN players in their pocket. And if they back off, that could mean that the new GXS/OpenText is going to try harder just to get along. Could that provide the impetus for a public DNS registry for EDI?

But for now, no matter who you are, who you trade with, and what industry you deal in, you can no longer turn a blind eye to your VAN and just hope it all works out. Yeah, baby. We have one more thing to watch and worry about.