Is ECGrid a VAN?

This is a very interesting question, as the entire future of the industry may depend on the answer. The related questions are “What is a VAN?” and “What is the difference between an EDI VAN and an EDI Service Provider?” Let’s start with the last question first as I think it is quite telling.

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.