This is a market characterized by what is known as “The Network Effect” (http://en.wikipedia.org/wiki/Network_effect). The value of the market grows exponentially as more endpoints (trading partners) are accessible. By cornering a large share of these endpoints, a bad actor can control the growth and direction of the market. Even with the addition of direct connects through AS2, this market is still defined by VANs and Interconnects.

Interconnects are not just a feature of EDI, they define EDI. Had Interconnects not been introduced some 20 years ago, EDI would never have become as successful as it is today. The power of this network effect is why a technology that is 40-years old remains relevant today and why so many competing technologies, delivered by a single provider have failed.

Without Interconnects VANs would not be VANs at all, but would be isolated service providers, only able to service small communities that chose to be wholly dependent on a single system. However, Interconnects are not for the networks, they are for the trading partners. They allow each trading partner to pick the offering that is best suited to its needs and not be locked into a single provider solution.

The networks on both ends of the Interconnect benefit equally by having the other end to complete their respective trading partners’ relationships. It is equally beneficial to send an EDI document as it is to receive one, so by simple logic the VANs do not settle send/receive with each other, they are paid by their respective customers. This is why Interconnects are “free,” and the VANs to not charge each other for them.

Here lies the problem. There is a player in the industry that by acquisition has gained monopoly control over the market. Entrance to the EDI data routing market (a.k.a. VAN market) is being controlled by this single entity. If they do not give permission, one does not get to play. (Of course, they are more than willing to offer a degraded connection…for a fee.)  Without a true Interconnect with GXS one cannot reach enough endpoints to be viable. Imagine trying to be a phone company and Verizon refuses to interconnect. (Fortunately, in that case this was settled in the early 80s with the landmark MCI v. AT&T antitrust case, which resulted in FCC oversight requiring competition.) If you doubt this is happening in our market, ask yourself how many new VANs have entered the market since 2001. The fact is we have fewer VANs now than 1996.

The elephant in the room that no one is willing to talk about is now on the march again. In their plans to eliminate the ex-IBM IE system, GXS is shutting down all the Interconnects to IE and routing them through TGMS. For every network save one, GXS has moved this to a comparable, reciprocal interconnect on TGMS; in several cases creating new TGMS interconnects where none existed before. GXS has singled out Loren Data, demanding Loren Data to move from a decade-old, reliable, reciprocal, and direct interconnect to a circuitous route through Inovis, and additionally requiring payment.

What they are telling their customers is that there is an “unresolved interconnect issue between GXS and LORMAIL.” You bet there is. As GXS has said on many occasions, they do not like our business model – one which enables service providers and developers such as SPS Commerce, CovalentWorks, Energy Services Group, Trubiquity, NetEDI and launched Covisint as a VAN.

Since 1999 Loren Data has been on a mission to reinvent the communications side of EDI. ECGrid was envisioned as an automated switch between networks. We bring to this market Directory Services (e.g. Qualifier/ID-based routing tables available to all networks), automated Trading Partner Interconnect Provisioning, Migration Management, Certificate Management, and a 100% programmable interface for all aspects of network and Interconnect management (see http://ecgridos.net). The illustrious William Kammerer has called ECGrid “The VAN of VANs.” No wonder GXS fears us. We celebrate and encourage Interconnects and a rich market of innovators, while GXS wishes to shut them down and create a single network system under their sole control. GXS’ former V.P. of Marketing, Bobby Patrick, told me directly that “Interconnects are a necessary evil.” It is these very Interconnects which allowed GXS to build its business and the industry, which it now is using to prevent others from entering.

GXS is now attempting to force Loren Data to accept a degraded (below industry standard for network to network communications) connection in lieu of the direct IE Interconnect; one that cannot handle our data with the accuracy and efficiency our clients and GXS’ own customers require, and which is crucial to Loren Data’s professional reputation.

No greater harm has been done to VAN Interconnects since GXS terminated its Interconnect with Internet Commerce Corporation (ICC) 2001. In many ways this is even more insidious. While ICC was itself a new competitor in EDI, ECGrid enables many more companies to compete with GXS…providing you with new technologies and more options.

Not only is this immoral, we also believe it to be illegal and are pursing the matter in court with a Sherman Act antitrust suit. Antitrust is the last great protection we have when a market becomes out of balance and no longer functions in a competitive manner. It is an expensive and slow process, but one that must be pursued when all else fails. There is much about this on my blog at http://www.ld.com/presidents-blog/.

There is another, even more powerful route, but it takes the industry saying enough is enough. If you want a market with competition and innovation, help us stop this right here and right now. Please, for the sake of the industry and yourself, please write Bob Segert of GXS (bob.segert@gxs.com) and let him know that interconnects are the backbone of EDI. Let him know that it is essential that all viable networks freely interconnect with each other to create the infrastructure the industry needs to thrive. Also drop a note to David Swanlaw, Sr. Vice President of Operations (david.swanlaw@gxs.com). It is telling that Interconnects at GXS are actually owned by the Sr. Vice President of Corporate Strategy and Development rather than by Operations. If you would like the GXS strategic perspective on Interconnects you can write Steve Scala (steven.scala@gxs.com). If you would also like to write the Department of Justice or the FCC, drop me a line and I will provide you with some contacts. (Please send me a copy of any letter you send; I would greatly appreciate it.)

You might think this does not affect you – don’t be so sure. We need diversity. We need innovation. ECGrid and other innovators should be allowed to operate on a level playing field in this market and not solely at the discretion of GXS. If GXS is allowed to choose which innovators are allowed into EDI, the market as a whole will stagnate, suffer and ultimately die.

This market belongs to all of us, the trading partners, the software developers, the service providers and the networks. Without industry level resolve, as time passes, GXS will become ever more emboldened to wield the power of Interconnects as a weapon against its competitors. Do not let that happen. Maintaining a healthy counter balance within the EDI Communications Industry means fostering competition and innovations from many diverse parties.

I am requesting you to actively add your voice to the discussion. If you agree with GXS, that’s fine. But if you don’t, let everyone know that GXS’ actions are NOT OK with you!

Respectfully,

Todd Gould
President
Loren Data Corp.

This first document is our Appellate Brief filed on 12/1/2011: Loren Data 4th Cir. Brief 12-1-11 (Final)

This next document is GXS’ response filed on 1/10/2012: GXS Brief 1-10-12

And finally, our reply to GXS’ response filed on 1/27/2012: Loren Data 4th Cir. Reply Brief 1-27-12 (Final)

Counsel has informed me that we now wait, probably 90 days, to hear from the Circuit Court, whose next step is likely to be oral arguments. After that it would be another 90 days before we hear a decision.

Todd Gould
President
Loren Data Corp.

Where is EDI going? Are you providing complete solutions to your customers? How are you prepared to compete with Enterprise 2.0 and The Cloud?

Loren Data grows in two ways, one in adding new customers the second is by helping our existing customers grow. Because we enable service providers, there is a synergy of efforts that benefits both our customers and ourselves, and the industry in general.

Join me in making 2012 a year of individual and industry growth.

Best regards,

Todd Gould
President
Loren Data Corp.

The current skirmish is over the ex-IBM Information Exchange (IE) network. Since 2000 there has been a standard, reciprocal Interconnect between ECGrid and IE. GXS now wishes to terminate that and replace it with a degraded, daisy-changed (their pejorative term) and poorly supported, circuitous route through TGMS -> Inovis -> ECGrid.

GXS has every right to consolidate their acquired networks; I have no beef with that. But to use this as another tool to further harm my business is not cool, and I am simply not going to stand for it. It is bad for my customers, it is bad for GXS’ customers and it is bad for the industry.

In a letter to me from Steve Scala, Sr. Vice President, GXS, he states:

Your efforts to stall our migration efforts detract from our ability to offer our clients newer and additional messaging services. I appeal to your wisdom to do what is right for your customers and the entire EDI community to help us migrate this traffic.

Truly? GXS has lead a campaign to harm Loren Data and hold us back from the market at every turn for over a decade? We are not standing in the way, we simply wish to exchange a direct interconnect for a direct interconnect.

He further goes on to say:

If we do not receive written acceptance our proposal to migrate the IE Interconnect traffic to Inovis Works by December 15, 2011, we will assume you have no interest in assisting with this migration effort. GXS will begin to notify GXS clients currently using the IE VAN Interconnect (to and from Loren Data) that this traffic will become undeliverable and we will seek to assist our clients in finding alternative solutions.

Wow! Now that is demanding and threatening. DO IT OUR WAY OR ELSE!

All we ask for (and have ever asked for) is that GXS establish a direct, reciprocal interconnect between TGMS and ECGrid. The same type of interconnect that every single other VAN that has been transferred from an IE Interconnect has.

I challenge Mr. Scala to reply with an open letter to the industry explaining exactly why GXS refuses to interconnect with ECGrid. Steve, let’s hear it, publicly, out in the open. What exactly is it that worries GXS so much about Loren Data? Why are you holding us out differently? (Oh, and Steve, please, do not use the excuse that Loren Data is expensive to support as you have only offered us horribly under provisioned connections which have overburdened both our support departments over the years and would be moot with a true interconnect.)

Below if the full text of my response to GXS regarding their DEMAND that we degrade our respective customers’ data communications OR ELSE.

If you wish to support an open, well-meshed EDI/EC networked industry, with lots of innovation, competition and options, send Mr. Scala an e-mail at steven.scala@gxs.com and let him know how you feel. Tell him you want to see a true TGMS – ECGrid Interconnect in place.

Happy Holidays,

Todd Gould
President
Loren Data Corp.

Mr. Steven Scala
Senior Vice President
GXS, Inc.

December 15, 2011

Steve:

On behalf of Loren Data, I must reject all the premises of your letter dated December 5, 2011.

You characterize GXS’ unilateral threat to eliminate my firm’s peer Interconnect with IE (formerly IBM) as “simply…migrating the traffic” off of IE.  What you are actually demanding is that a solid, long-established, reciprocal Interconnect that has been in place between ECGrid and IE for over a decade be replaced with a circuitous, “daisy-chained” (your term, not mine) and degraded connection. It is my understanding that every VAN Interconnect that was on the ex-IBM IE Interconnect has been transferred to an equivalent direct interconnect into TGMS, some to previously existing and others to new TGMS interconnects created specifically as part of your project. GXS appears for no legitimate business reason, and certainly with no justifying rationale articulated in your letter, to be holding ECGrid out as the single exception.

You accuse me of “stall[ing your] migration efforts and detracting from [your] ability to offer [your] clients newer and additional messaging services.”  My efforts have never, ever been, nor can fairly be construed as “stall[ing your] migration efforts.” I have only tried to do what is right by all parties involved, especially our respective customers, by replacing an existing Interconnect with a like Interconnect.  As you should know, the actual process of setting up that Interconnect will take less than 24-hours and would constitute an infinitesimally low cost or burden to GXS or Loren Data.  As IE and TGMS use the same VPN, which is already in place, all that would be required is establishing FTP user accounts on both systems, exchanging X12.56 IDs, and transferring a few test documents. That de minimis effort is all this has ever been required.

While you appeal to my “wisdom to do what is right for [my] customers and the entire EDI community” you completely ignore the fact that GXS refuses to deal with my company on terms the same as those of other EDI network providers because you refuse to accept Loren Data’s business model.  It is clearly not in my best interests — nor those of our customers and their end user trading partners — to accept your defective offer of moving the established, ex-IBM Interconnect to a substandard connection through Inovis.

I strongly urge GXS to reconsider its threatened actions, which merely reinforce my resolve to continue the antitrust battle between our firms. Selecting the alternative of making Loren Data’s EDI traffic “undeliverable,” without Loren Data’s consent and over our explicit objection, would represent an unwarranted escalation of our firms’ dispute and could only be viewed as an intentionally predatory act designed to further harm Loren Data’s competitive and business prospects.  Please end this unjustifiable campaign against Loren Data and establish a proper peer Interconnect between TGMS and ECGrid so we can both move on and “offer our clients newer and additional messaging services” over a well-meshed, networked industry.

Most sincerely,

Todd Gould
President
Loren Data Corp.

Happy Holidays!

Todd Gould
President
Loren Data Corp.

Probably, because of my degree in Chemistry and Materials Science I am fascinated by the characterization of what I cannot directly see, but can measure, interpolate, extrapolate. As a matter or principle, we do not look at the data itself at Loren Data, unless something goes terribly wrong and we need to see the data to diagnose and correct a problem. So for me, it is the number of transactions and the number of bytes; the state of flux and flow over and through the systems.

The first real data on the system was an intensive 24-hour load test for the Department of Defense’s FACNET system. Based on some projections we gave them, they initially wanted to run something like 23 million transactions over our network in 24-hours. After I got over my initial shock and talked reason with them (and the fact that they didn’t even have the bandwidth to run that at the time), we settled on something like 23,000 over the 24 hours, about one every three seconds. (After we went live, it took months to see 23,000 transactions from them). Not bad for a few Pentium 800-mhz machines with 512k RAM running Windows NT 3.51.

At our current loads we run that amount each hour, and I am still mesmerized watching the dance of the data. Mailbags coming in, mailbag acknowledgements going back; interchanges processing, routing and going out; and 997s being returned within moments.

I see the data spikes turning holidays (Cyber Monday looks more like Cyber Week and maybe Cyber Month from here). The relative lulls each night and weekends, but still continuous activity; data always moving…and growing during “off hours” every month as our client base and their trading partners become more global and more on-line purchase directly trigger EDI transactions on the back-end, real-time.

I also see the outages when our graphs go flat because a major network or customer’s system is down. Sometimes for minutes, other times for hours. Is it us? Is it a customer? Is it another VAN? Automatic e-mail and text messages are generated. The real people, who make this all work communicate, work out a resolution to the problem and everything returns to normal. (Why do systems always seem to go down at 3am on a Saturday?)

The system has a pulse, a life of its own. There is something invigorating about seeing all these systems dance in concert with each other: the end users systems talking to their service provider, the interconnect handing off data to us on one end, and us then pushing it through to the network on the other side, carefully logging and tracking every step.

I think about all the types of transactions, the commerce it represents; all the companies doing business and the products eventually getting to the consumers as some point in the game. There is a reason the company’s middle name is Data.

We, the movers of electronic commerce traffic, are the unsung heroes of the economy. We make “Just in Time” work, we keep the assembly lines moving, the shelves well stocked and the on-line purchases ship the same day. In all the craziness and mundane-ness of this industry, I encourage my colleagues to remember Crystal’s words: We route their data, and their data, and their data…

Regards,

Todd Gould
President
Loren Data Corp.

What Is a VAN?

This is what I consider to be the core, minimum list of services that constitutes an EDI VAN:

• Multi-Tenant Mailboxing (for End-Users or Service Providers)
• Data Validation
• Mapping and Translation (through Software, Web Forms, Service or Third-Party)
• Standard EDI Document Routing
• Interconnects to other VANs via peering 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.)

What Is an EDI Service Provider?

And now the core list for EDI Service Providers:

• Multi-Tenant Mailboxing (generally for End-Users)
• Data Validation
• Mapping and Translation (through Software, Web Forms or Service)
• Standard EDI Document Routing
• Interconnects to other VANs via transit agreements

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 EDI Service Provider outsourcers its Interconnects (from VANS).

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

What is ECGrid?

So let’s go through the short list of what ECGrid provides:

• Multi-Tenant Mailboxing (for Service Providers)
• Data Validation
• Mapping and Translation (through Third-Party)
• Standard EDI Document Routing
• Interconnects to other VANs via peering agreements with one exception

Sure looks like a VAN to me, albeit a specialized VAN for Service Providers. 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.

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 is 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.

Let that sink in for a minute.

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)

That brings up the next question we hear all the time:

How do I become a VAN?

Let me answer that: By getting permission from all the other VANs! If they do not give you permission to be a VAN, then you do not get to be a VAN! To make matters worse, there is a blackball rule, just like trying to join a fraternity. If any one of the Top-5 (or so) VANs does not give you permission to join the group, then you don’t get to be a VAN!

There is an awkward middle ground: If most of the VANs say yes, but one or more say no, then you can be “mostly” a VAN and purchase the missing pieces. (Welcome to my world for the last decade.)

So given the incredible market entry control that the top VANs have over who else gets to be a VAN, why would they ever say “Yes” and to whom? The reason for Yes is quite simple: The EDI VAN Model is defined by the fact that there are Interconnects; without Interconnects there would be no EDI VAN Model!

In a networked market, its value is geometrically increased with the increasing number of networks and exponentially increased with increasing endpoints. The more networks, the more endpoints, the more valuable the market is to everyone.

The reason for No only (kind of) makes sense if you are the “market leader:” To control competition. Ask yourself this: Since 2001 how many new VANs have entered the market?

The next question is a business one and should be asked by anyone considering becoming a VAN:

Do I Become a VAN or an EDI Service Provider?

That is the $64,000 question. The answer is based on focusing your resources, attention and development on customer-facing tasks that will differentiate you from the competition: Become an EDI Service Provider.

Since the only difference between a VAN and a Service Provider is on the back-end, as far away from the client experience as possible, why invest a dime or minute into building your own Interconnect infrastructure?

If you want to be a player in EDI you either need to become a “VAN” or become a Service Provider with an up-stream VAN provider.

Does it make any difference to your customer base? To them VANs and EDI Service Providers are simply Electronic Commerce Service Providers (ECSPs). How your system interconnects is of little importance as long as you have the Interconnects.

Since the likelihood of becoming a VAN is very small and the business case is against in any event, then you want to be an EDI Service Provider.

What Does All This Mean?

Aside from ECGrid you have to outsource your Interconnect function to your competition!

If you are (or plan to be) an EDI Service Provider (traditional, cloud or otherwise) or are an EDI /B2B Software Developer, you really need to look at ECGrid and the ECGridOS API. Absolutely no other VAN provides the tools and true partnership that you find with Loren Data Corp and ECGrid.

So, is ECGrid a VAN? Unequivocally: YES!

ECGrid is The VAN for EDI Service Providers.

Regards,

Todd Gould
President
Loren Data Corp.