Cloud integration- EDI and API ?

There are an ever growing number of companies offering EDI + API that stirred up some thought:

Having worked with GXS, one of the leading EDI VAN services, I felt I should provide my readers with some background – EDI or Electronic Data Interchange is a B2B protocol used by major business to automate their supply chain. These standards pre-date the WebServices days and were designed to be compact messages designed to save bandwidth and are governed by standard committees (ANSI, EDIFACT or TRADACOM).  These  B2B documents represented an invoice, acceptance notification and many other pre-defined forms.

EDI offers major savings over large corporations like Walmart or JC Penney who wanted to streamline their businesses and normally have large partner networks.  Standardizing and integrating businesses between Hub (the Company) and Spokes (all the partner suppliers) is a win-win for everyone and ends up being a cost to Spokes to choose to do business with the main Hub.

The Spokes are smaller firms. They choose EDI because the Hub asked to do so. Will they internally adopt EDI?  Maybe / maybe not.  As most firms, internal applications are integrated or can be connected by building bridges between applications.  In today’s world, they will very likely invest in integration tools which connect directly to each other.  To integrate with the Hub, they would go with an EDI VAN service like GXS, buy a tool to map and transform their internal representation of Invoice or other documents and send it through to them as EDI, using a prebuilt transfer protocol like FTP/S, EDI*Express or others.

Now let’s look at an Integration provider building an offering in API+EDI. It would make sense to me if the Integration Provider

• Had a trading partner hub so that it made sense for Spokes to join in – or if they don’t have an offering of a hub,
• Offered an integration platform for Spokes to transform their documents in EDI and push to the network – seamlessly.
• Sold to the Hub an offering to replace EDI VAN services, and move to become a front-end to them for receiving EDI.  In this case, the Integration Provider should have a good strategy to upgrade the connector software for all Spokes.

So what I am getting to is that a firm will have difficulty making headway by only providing a way to transport EDI over an API without providing a value proposition to either the Hub or the spoke.  In this case, perhaps I am missing something.

I feel a better strategy we be to provide a built-in integration with Accounting or ERP packages to EDI.  This will certainly address the major concerns for the Spokes and increase traffic to the EDI Trading Grid / Network or connect with the Hub directly.  This is why a solution like DBSync makes the solution complete, as it connects to the accounting systems, provides mapping capability, and transfers to Hub in the form they need.