As you may know, Todd Gould was notified on June 4, 2013 that GXS has begun notifying its customers of its intention to terminate connectivity to Loren Data’s ECGrid® EDI Network on March 4, 2014. Ever since then Todd has received a lot of support from individuals in EDI forums.
We are going to try and give you some of those comments (abbreviated). Going to keep the same picture, not only because it’s cool; but because we bought it. (Todd, you can buy us a cup of coffee the next time you are in Nice.)
June 5, 2013
Todd Gould replies to the faithful
I am overwhelmed by the letters of encouragement I have already received; however, I am also bitterly disappointed.
Everyone who has any concern over these actions by GXS needs to speak out publicly, now. If you cannot go on the record representing your company, then speak out for yourself. If you can’t do that, then make some noise at your company so they understand what is going on, so they can speak out. Remaining silent only supports GXS, tacitly, but support nonetheless.
If you are with a VAN and you currently have EDI Service Providers as customers, be ready for a letter from GXS in the very near future banning all EDI Service Provider traffic from transiting your TGMS and Inovis interconnects. GXS is going to make your customers pay and connect to GXS directly for all that traffic. Think about it.
If you work for an EDI Service Provider shouldn’t you be able to choose whichever VAN you wish to route your customers’ traffic? Very soon your VAN (if it is not GXS) will be told that your customers’ traffic can no longer go over the TGMS interconnect, you will need to pay for another account on GXS. And if you would rather have interconnects to each VAN, shouldn’t you be able to do that on the same terms as any other VAN? Why made GXS king of deciding who can play and who has to pay?
If you are an end user, make no mistake, GXS is willing to interfere with over 10,000 trading partnerships and all the commerce that represents in order to control the market. These are your relationships, representing your supply chain, your business. Do not let GXS use your business to harm competition in this market.
If you are a GXS customer affected by this, call your account rep and ask them why they are doing this. How is this serving me? Tell them you want your trading partners to use whatever systems they want, and if that requires interconnects to ECGrid or any other service provider, then GXS should put them in place.
Not since AT&T v. MCI have we seen anything like this. It was bad for the market then, it is bad for the market now.
If you don’t speak out, you are supporting GXS’s actions.
Now is the time. Make your voice heard. This is your market, not GXS’s.
Regards,
Todd Gould
President
Loren Data Corp.
June 5, 2013
Response to Todd
First they came for the communists,
and I didn’t speak out because I wasn’t a communist.
Then they came for the socialists,
and I didn’t speak out because I wasn’t a socialist.
Then they came for the trade unionists,
and I didn’t speak out because I wasn’t a trade unionist.
Then they came for me,
and there was no one left to speak for me.
– Martin Niemöller
June 8, 2013
Letter to Todd from
Earl Wertheimer
http://www.spe-edi.com
(reprinted in entirety because it is really cool)
I read both documents and wanted a better understanding of the following:
“Daisy chaining is a practice of having one EDI service provider enabling
downstream EDI providers which all become dependent on one connection.”
If I understand this correctly, you (EDI service provider) can enable me
(downstream EDI provider) to setup my own EDI VAN.
Essentially, if I want to create an EarlVAN, you (Loren) can set me up.
All traffic flows from my clients, through EarlVAN, across to Loren then
out to other VANs. I would assume that EarlVAN is a virtual entity,
connected to Loren.
Is this the practice they want to eliminate?
thanks
June 8, 2013
Response by Todd to Earl,
(reprinted in entirety because it is really cool)
The short answer is, yes, that is the practice that they want to eliminate or more specifically control and have sole authority over. This is the practice that SPS Commerce, DiCentral, CovalentWorks, NetEDI, and nearly every single other service provider (a VAN without interconnects) has been doing since EDI began, whether it is through ECGrid, Liaison, Easylink, etc.
You can call it EarlVAN or EarlTheServiceProvider (a la SPS, CovalentWorks, DiCentral). This has been how EDI has been operating since before the internet…we used to call them a VAN if they directly interconnected, and a VAS if they connected through a VAN.
GXS’s excuses about latency, lost data, etc. is pure fabrication. These virtual VANs or Service Providers provide multi-tenant systems as opposed to single-tenant end-user configurations. The data travels the exact same path over the same number of hops (or lack of them). In fact, using a service provider such as EarlVAN is frequently more reliable and responsive than one-system-per-vendor model because you know what you are doing and are getting paid to do it well, for many companies, in the same way.
GXS is taking the position that there can be service providers or virtual VANs in the market, but they must all connect directly and pay GXS to play. GXS then can exercise the right to not do business with any service provider they feel is a threat. By prohibiting that traffic over other other VANs, and refusing to connect directly (or making egregious demands to do so, such as in our case), GXS exercises the power prohibit any company it choses from competing in this market.
Additionally, GXS is now moving to enforce its “no third party/daisy-chaining” provision of their interconnect agreements, prohibiting all the other VANs from selling connectivity to GXS customers to EDI Service Providers. GXS now demands that all the traffic that goes to GXS customers is theirs alone to charge for, both ways, all sides. The other VANs should be quite concerned right now as that EDI Service Provider traffic is a sizeable chunk of billing they are about to lose.
Will the VANs lose their Interconnects to GXS for all traffic next?
-=tg=-
June 9, 2013
By Ajay Sanghi, Managing Director
EDiSPHERE Software Private Limited
215, Congress Nagar, Nagpur 440012 | India
(reprinted in entirety because it is really cool)
We, at EDISPHERE Software Private Limited in India, are outraged by GXS plans to terminate interconnect agreement with Loren Data. This will adversely impact our business and that of thousands of companies.
We have launched India’s first indigenous self-service data integration network startup (anytoany.com), after several years of hard work, and significant investment in building the product, including native integration with Loren Data, as gateway, to our customer’s trading partners, who are spread across different EDI VANs.
The concerns highlighted by GXS in terminating the interconnect agreement with Loren Data states, “GXS will no longer process these transactions with Loren Data given concerns regarding tracking, latency, security and the daisy chaining of EDI data.” This is insincere and calculating for the following reasons:
The entire “daisy-chain” theory of GXS is a false premise for cancelling the interconnect agreement with Loren Data. Whether the data is processed by a third party service provider attached to ECGrid, or an end-users own mapping/translation software attached to ECGrid, the data moves with the same tracking, latency and security; as is being done by EDI VANs for several years.
Further, this looks like a classic CLEC vs. ILEC battle in telecom space a decade back! To me it’s a clear case of GXS (ILEC), an 800lb gorilla, muscling it’s way into crushing not just competition but also innovation, as it’s only on account of Loren Data (CLEC) that a small service provider like us can think of providing global connectivity. Loren Data is a great innovation in commoditizing the VAN business and we urge the US Supreme Court to bar GXS from cancelling Loren Data’s interconnect agreement, as the cancellation of the agreement is neither in the interest of end customer or small the service provider businesses like ours.
We will explore our options in India of stopping GXS disconnect Loren Data as our business gets directly affected by it.
I hope others also join in voicing against GXS!
Thank you for your consideration.
Regards,
Ajay Sanghi
June 10, 2013
By Michael Kotoyan – Founder & Instructor EDI Academy –
https://ediacademy.com/
(reprinted in entirety because it is really cool)
The daisy chain excuse by GXS is the most ridiculous one that I have ever heard, GXS does not even have the guts to tell the real reason (revenge for the retail catalog issue). Read more below.
When GXS bought a good EDI company called Inovis, EDI folks hoped for the best, some where sure that GSX would change their name considering how much bad publicity there is with it. A once well-known TrustedLink translator or a BizManager communication tool has been polluted with GXS’s brand. When GXS acquired Inovis they monopolized the retail EDI Catalog industry.
Loren Data stood up against the monopolization strategies of GXS in regards to the retail cataloging after the Inovis acquisition and now GXS is punishing them for speaking out. After the GXS acquisition of Inovis, InterTrade (a good VAN / catalog company based out of Canada) is now there to offer an alternative to the retail EDI catalog. If Loren Data had not
spoken out about this, GXS would have a close to 100% of the retail EDI catalog business in the USA.
I am going to make sure that hundreds of EDI Academy class attendees that are confirmed to attend our classes rest of this year alone will know about this issue. When I was an EDI manager at a national retail chain back in the early 2000s I was disgusted with what GXS did to ICC.NET/EasyLink by cutting them out of the interconnect. It was disruptive to the supply chain to thousands of vendors and there was outrage in the industry. They let ICC return to the interconnect several months later after industry outrage and a complaint filed with the department of justice http://www.justice.gov/atr/contact/newcase.html).
EDI Academy has been providing EDI Fundamentals & Best Practices Trainingfor over 6 years to thousands of EDI Professionals worldwide. Some of these attendees are GXS Customers.
As an EDI Academy instructor I have been teaching against bad EDI practices (e.g. issues caused by poor quality testing in on-retail boarding programs and testing fees) for years and always mention the ICC / GXS saga of the early 2000s in all of my classes. I tell the story of how ICC was brave enough to stand up against GXS and Sterling and route its traffic temporarily through the IBM. I am not shocked that they have now done this to Loren Data.
GXS bullies its ways to the top executives of organizations that are not as aware of what’s going in the industry. I praise Loren Data Corp for standing up against their monopolizing antitrust-like business practices.
By the way, GXS executives, in case you are actually reading this email, please note the fact that most GXS customers that take an EDI Academy class constantly complain about your outages. The tendency is that they are in a way simply “stuck” with your service because it has “just been there for years”. I know the GXS bottom line looks strong and your sales are doing well so you may not really care. However, if you think you do not have any industry-wide reputation issues you are being ignorant and living in a bubble.
Hopefully if the industry again puts enough pressure on GXS they will let Loren Data back in, just like they let ICC.NET back into the network over 10 years ago.
Like this:
Like Loading...
PenneyVanderbilt 