For an industry that is so reliant on technical communications architecture, it’s curious that the science of EDI messaging has been stagnant for years. FTP, As2, and a few oddball file protocols, a VAN exodus to closed hubs, a return to VANs (even with sub-optimal routing) makes the subject more than interesting – it almost mirrors certain societal dynamics. On the one hand, we have ultra modern, standards-based IP socket and the protocol stack carrying today’s packets for web surfing, email, and EDI messages. Attach to a standardized system, and you are able to send your messages anywhere. However, one thoughtless application layer higher, and wonderfully ubiquitous IP based transport systems turn into muck. There is no need for such retrograde “technical perversions”.
A proper architecture designed to co-exist and potentially replace the outmoded VAN routing system, must address the burdens associated with As2 (certificates and syncing) – such systems should ‘just work‘ for providers and end-users alike, period. A proper system for B2B EDI message routing needs programmable, code invokable directory services and an architecture for advertising the adds, drops, and changes that network ID’s are subject to. These issues are no brainers.
The EDI communications architecture of the new era must be as robust as email, as secure as (proposed) addressable As2, while retaining the reliability and transparency of systems we currently take for granted (DNS, BGP, SMTP, add you favorite RFC here). We do not have this in the interVAN world, but we should, and getting there should not require a Copernican Revolution.
For service providers and the rapidly growing constituency of ‘micro-vertical’ EDI SAAS operators / integrators (ECGridOS aficionados), for toolsmiths who are delivering integrated communications in their IDE-based data management suites (Oakland Software’s ODT-EDInow), the ERP, BPM, and Enterprise 2.0 specialty vendors (Dimension Software) no longer tolerating the artificial divide between application and communications (a divide dispensed with long ago in Internet applications) – for a plethora of constituencies needing communications and network control in an environment that is native to their application’s “code body”, we will need to go beyond the Crown Jewel of EDI Communications – we will need to exceed even our best, the ECGridOS API.
Of course, the technical evolution of our API is a constant. We are introducing new functions and entire branches of the API, optimizing the existing functions, upgrading the physical infrastructure, and simplifying the developer enrollment process. Loren Data’s Software Engineering and the evolution of the product road-map is unceasing. I am taking about an industry wide, thoughtful, and expansive rethinking of fixing the ad hoc, inherited mess of the current EDI mesh of cooperating VANs and specialty networks., as well as 101 other things.
On the competitive front, we can work together if the participants believe the EDI market is due for continued expansion. And we need more unbundled communications providers offering an expanded set of component network services. Competition in the pure communications sector (no value added services, mapping, etc.) will be a net economic stimulant for the industry, by making EDI more available in increasingly diverse channels (built -into software, SAAS integrations). It would be gratifying indeed to see at least five more EDI Comms providers in the mold of Loren Data Corp, each differentiated by the refinements and features of their network services, as opposed to the current duplicative services.
We do not need to increase the number of generic mailboxes, or push more vanilla Web Forms, or perpetuate a market where KC rates are the sole focus of quotations. More functional communications platforms with enhanced network control functions are the type of innovations that applications developers and Cloud Commerce providers will really build upon. Bringing such rich communications platforms to market will create a momentum that can be delivered to the B2B specialties that are hyper-focused, and domain specific. These are the “EDI Tiger Teams” acting as service providers for their clients (in addition to the tools and applications folks, a good example here is Pinnacle Data Systems).
The ECGridOS API has driven new EDI business ventures that have gone on to make their mark beyond VAN replacement services, (NetEDI), and has even figured prominently in the re-engineering of succesful enterprise software product lines (Radley, KDDI, Activant, Raymond IT, and too many others to list and link here, see our partner directory and our API listing at GettApp.com).
To fertilize this soil , we will require the entry of collegial competitors of goodwill to set the bar high and higher – we all must be ready to make deals and bring the innovators and channel specialists closer. Even the cautious, but otherwise capable thought-leaders in the traditional VAN Constituency, data center people, and MFT folks who want to raise the bar higher, should be welcomed in and engaged.
We are ready to get real and bring some “hardball high-end network engineering”, to the table, to our industry peers with a burning desire to reinvent the EDI Communications market. I believe it can be done, that it’s not out of reach, and it addresses the issues of VAN interconnection policy abuses that we have been dealing with at Loren Data. The visionary leaders in the B2B sector who have commiserated with us over the inter-VAN travails, know that LorenData Corp’s present interconnect wrangling will not be limited to ECGrid in the shorter-long run. Many respected colleagues have confided that they perceive “a Sword of Damocles”, is hanging over the heads of all innovators in the EDI sector – and it’s just a matter of time.
The ECGridOS blog is generally not the place for me to agitate over industry issues, but as EDI communications are so fundamental to realizing the sector’s prospects for future growth, I had to touch upon these sticky issues. As any student of networked markets will tell you, the ability to sort out peering and traffic routing issues, via the participation of the sector’s pragmatic and visionary leaders, invigorates the market and creates opportunities for practical partnerships that may lead to an “Internet Scale” revolution of fresh ideas and new paradigms beyond the supply chains.
For those who do not believe these truisms, here is your leased line to MegaVAN #1 – if they get their way, you won’t even need the Internet….hmmm.
Therefore, Todd and I invite the true believers, network engineers, the ambitious entrepreneurs and emeritus scholars of the B2B messaging world, (in short all who wish to see the sector thrive via technological innovation), to contact us and tell us what you would change, what you would do in cooperation if other, like minded colleagues had your ear? Tell us what kind of technology you would license or share, and how you might envision a dedicated cadre of competitor-colleagues creating a charter for an “Applied Research and Development Consortium”?
What if you could get the tech you needed – by cooperative development or licensing? What if you could influence interVAN issues, like message routing policies, as part of a group of industry advocates, at the regulatory level and beyond. Such a new, dynamic, and action-oriented organization would address some of the the ills of our market, but be more focused on solving the problems of the SME market expansion – what the analyst’s have termed, “the next $30B in EDI and B2B services revenues”.
Well? Call us and become involved with your fellow colleagues and other motivated thinkers in the EDI market. We intend to act.
