There is no such thing as “EDI Communications” ! There is nothing wrong with your computer, and your brain has survived the New Year’s revelry – you heard my statement correctly = “The is no such thing as EDI Communications” ! This is a public service announcement.
This article was prompted by a very quotidian stimulus…..I was reviewing our website stats…
A very interesting keyword search just landed on my Evangelist’s plate (analytics), sparking ideas and possible answers to questions I hear via search keywords, conversations, and correspondence with my colleagues:
The search queries / questions: “(which)…communications (are) not suitable (for) EDI” paraphrased as, “What is / are EDI Communications”? Or, “what is special or different about EDI Communications”?, etc. All of these questions are host to an entire subspecies of questions:
- What is AS2,
- Is AS2 better than FTP?
- Is the VAN era on the wane?
- Is there a nascent VAN Exodus ? Why? Why not?
- Are the various Enterprise 2.0 on-demand integration platforms different from the VANs and Classic EDI Service Providers of the first era?
- Are E2.0 supply chain and logistics hubs (Cloud B2B) subject to the same or similar inefficiencies or deficiencies as VANs ?
- Or, might Enterprise 2.0 provide answers to certain ‘baked into the sector sins‘?
- Cloud B2B – (SAAS / PAAS) – would I even know it if I saw it?
The struggle over applied communications practice, including setup, customizations, partner integration, etc., occupy too many hours of today’s B2B specialist’s time. B2B professionals shouldn’t be required to plumb the arcane depths of AS2 or VAN comms, merely in order to facilitate client-side transactions. Yet, here we are, again and again. I repeatedly see these searches: AS2, AS2 vs. FTP, API vs. VAN vs. etc. What does this mean?
The legion of issues related to contracting reliable messaging services remains unique to our EDI world, however we define it. Elsewhere (and everywhere), these struggles and upheavals are either a) absent, or b) an afterthought. I no longer even need to prove this, as these issues have been recounted ad nauseum, in articles written by respected industry authors. The list of EDI Communications deficiencies is as long as the offsetting smorgasbord of native communications options available everywhere. The EDI market has found ways to simultaneously adopt and circumvent these aforementioned systems, while somehow managing to provide the industry with an expensive, creaky amalgam of over-and-under provisioned systems that are considered all but indispensable – which they are not.
What (EDI Comms) do is indispensable.
Every OS, IDE, or integration environment enjoys a rich palette of native options. Enough said. These native options have been bent to perverse purposes when honest customers are tasked with ‘making do’ in the arena of EDI-over-VAN messaging, as well as in the misapplication of configuring and operating large AS2 hub systems – forcing their adoption upon innocent supply chain partners. These systems, (and not all of them are technically bankrupt), are management monstrosities, offending one’s sense of dignity, justice, theology, and geometry. We all know that there are better ways to enable partner communications.
“There is no such thing as EDI Communications“.
“EDI”, is a catchall that is properly applied to standards, documents, and processes– and should not be used to describe communications of any sort. Adopting this standard of nomenclature, we can thus concentrate on healing the ills that plague the vital messaging services used by trading parties. Permit me, for the moment, the freedom to applaud what is being done well, and to castigate, without reserve, the long-standing deficiencies in our market.
The above questions (the search terms in my preamble) are at the crux of all issues; and there are many services for handling Layer Seven (application) messaging:
Ignoring for the moment the greatly abused product category of MFT, and whether your transfers are files or streams, I, as an applications analyst, see the industry falling neatly into ‘families”:
1) Communications via cooperative messaging providers, those supporting a system of addressing, and 2) Non-routed (Client to Client), the badly named ‘Peer Communications’.
Subfamilies of the above are:
a) standards-based vs. bastardized,
b) Established or proven, leading edge, or obsolescent,
c) Methodologies that are inherent to the chosen protocols and stacks: Best Effort (where applications deal with delivery exceptions) vs. End to End (failure recovery in the stack).
Technical variations of the above are not as important, because you can’t choose the results or behaviors – such comms features are subsumed in your messaging application at a lower level:
a) Connection types: state-aware, or stateless.
e) Good and Smart, well implemented, widely adopted, having a vibrant community of developers, professionals, and “thinkers” evolving the standards and pushing forward, or…..
b) Bad and Dumb, poorly implemented, narrowly adopted, bereft of a vibrant developer community, with nary a soul concerned with standards or evolution of the state of the art.
The messaging system you adopt may add or subtract features. In today’s market, anyone can buy, borrow, or create workable systems using licensed or open source free software. One may use the outsourced services of established providers, or may build highly customized comms apps using SDKs or Web Services APIs, and all may exploit standards-based or nonstandard systems. And, we are all, to an extent, experts; we use many types of messaging in our daily lives.
You might not be a system operator or service provider, but you surely rely on many communication’s utilities to an extraordinary extent, and know what to expected of them. In our market, we have issues that are still waiting for basic resolution. Later on I will give illustrative examples of systemic EDI Communications issues with debilitating inefficiencies.
Here some examples of widely adopted Communications Systems – everyone involved in EDI should consider the following systems as well performing sectors:
SMS – Standards based (GSM) and widely adopted, evolving via the ITU and carriers / handset, and MTSO equipment manufactures. Value added services via software enhanced gateways, and a vibrant economically driven developer model. Good and Smart. Not terribly secure, see wikipedia.
Email – Standards based, widely adopted. Free or inexpensive to operate and to add value via software.
Almost all OS’s support email as system function calls and out of the box, and email client apps can send and receive via programmatic control. There are numerous Web Services Mail API’s (SOAP and REST) for server side transactional email applications. All such cloud-mail is hosted as a service.
SMS can be added to any program on any OS, and is on its way to becoming a ubiquitous messaging option (if it’s not already), in the next dot releases of popular OS’s and Web browsers (browsers are almost OS’s as one-stop multitasking environments).
The above are two real examples of standard and ubiquitous communications options. There are more:
- Raw HTTP/s, when used in conjunction with DNS, can be considered a quasi-routing system, or at least a directory assisted transport mechanism.
- FTP is old fashioned. It is deficient as a messaging protocol, and barely gets the job done for transfers. In the hands of professionals, it can be part of a larger system.
- AS2 is https transport secured by certificate, with a protocol or ‘state’ machine supporting ‘hard’, in band acknowledgements (MDN). AS2 has been propped as an integral piece of EDI or supply chain communications, but has completely and utterly failed the test for ubiquity, ease of use, and ten other things. AS2 works, just. That’s not saying very much. In the hands of professional, data center operators and when married to a better supervisory layer, AS2 can be made respectable.
- EDI over VAN – Let’s take a deep breath here.
Analysis of the VAN market is complex, because VAN’s deliver two services that are logically distinct: 1) data conversion, application integration, other stuff, and, 2) Communications.
EDI is not widely adopted compared to email, nor is it well adapted to the demands of a growing, EDI using mid market. A book could be written on why VANs refuse to adopt remotely invokable directory services (as in all normal messaging systems), the inability to invoke the complete suite of EDI network provisioning services from within software….is gut wrenching. To end-users, the lack of these services (directory and API Network Ops / Configuration) manifest as increased costs and compound inconvenience – sometimes to an extraordinary extent.
Conversely, although poorly standardized, VAN communications enjoy a globally meshed supply chain network system that is host to over 400,000 companies and nearly one million IDs. It is THE largest, interoperable (barely) system, with all others, such as self hosted As2 systems, a very distant second place.
VANs, without directory services or ID portability, portray themselves (unwittingly?) as technically deficient, as well as indifferent to evolving their place within the state of the communications art. With borderline client care services, and with their collective backs turned to the industry they serve, I perceive a less than ideal technical profile, offering a laggard, creaky, quirky, comms palate. This is just one man’s opinion.
The VANs inherited their de-facto, place holder positions as the largest addressable EDI Compatible (routed via the ISA envelope segment) system of supply chain communications – and by fixing a few deficiencies and adding a few features, while catching up on SAAS offerings, re-jiggering end-user pricing (and, adding directory services, systems of ID portability, eliminate multi-year lock-in contracts), etc. etc. etc., the VANs, serving the largest cohort of trading parties, can have their crown back in a year. And, Loren Data Corp can provide the path to address the technical hurdles in a thrice.
The crux of the matter comes down to saving EDI’s routed (vs. non-routed) communications. We will all eventually agree that routed systems are a preferred method of handling messages. So, we now see where the VANs have succeeded, and at the same time, where they have failed. One very looming, uncomfortable question concerns whether the VAN market’s deficiencies are completely self-inflicted aforethought. In other words: Do the established EDI incumbents, the VANs we all know and….love (?), did they shoot themselves and their customers in the feet, deliberately….?
As to the masked intentent of under-serving and overcharging, while lagging far behind the state of the art…..the prognosis was hinted at above, and shall be explained in a further article. We have “things to do and promises to keep”, and “miles to go before we sleep”. The picture I shall portray will not be pretty; but a great system of collegial, competitive, and cooperative networks needs to be saved. The VANs currently provide one-stop routing and message exchange services to the largest addressable body of trading partners, and has succeeded until recently, in spades. The VANs need to clean up a terribly damaged and distorted business and customer service model, while eliminating their toxic practice of locking in their clients, and finally, they must adopt modern inter networking practices .
All is not lost, and we CAN help. We will help everyone with a stake in the future of B2B Communications.
