Bringing an API to market (where none existed prior) should be considered an important undertaking in the EDI Comms universe. Anyone in this business knows that our comms solutions have been stagnant – stalled at uploading files to send, and downloading received files from your “inbox”. I will address the As2 conundrum in another article. But, for the large universe of VAN connected trading parties, some 400K+ businesses, communications have stalled, and it’s not technology holding up the EDI Bus, it’s a lack of imagination.

The market has not even attempted to approach the reliability and ubiquity of common electronic mail systems, and the idea that end-users or professional service providers might gain actual control over their EDI Network configuration (mailboxes, user credentials, reporting, status, etc.) via closely-bound, programmatic controls – that idea is lost on 99.9% of the EDI comms provider market – after all, what do you need that for? If you wanna create mailboxes, just pull yer swivel chair over here to this web browser, and click here to make a new mailbox. It wonderful ! Not !

Check message status? Check the web interface. Anything, check this, call support, and so on, The idea that we (royal EDI industry we) would be enthusiastic about having gaggles of entrepreneurial programmers pinging fragile messaging systems – well, you get the idea. No progress, no code binding EDI Comms to your next-gen B2B systems, no direct control, no ownership. Such sickly stasis and stagnation, when the entire Internet Application economy, mobile apps, APIs, Big Data, and ANYTHING as a SERVICE – makes new millionaires daily. The state of entrepreneurship in the EDI market is not what it could be.

But we are trying, by offering the best API platform, 150+ Web Services functions for creating EDI networks, and by offering free developer accounts and flexible terms to give new developers room to grow – what more could Loren Data Corp do for the market?

I’m glad you asked: Todd Gould, President of Loren Data Corp, initiated a Sherman Act Antitrust Lawsuit against the EDI sector’s most toxic monopolist. The GXS gambit to impede Loren Data Corp, the industry’s only Communications API provider, is a strike against fair competition and innovation. Loren Data Corp is fighting back, while innovating in the midst of battle. I would also be remiss to omit the fact that the company is gaining support for its antitrust battle –   mere “tea and sympathy” has become modest material support.  The company could use more help, though, all you free market advocates ! Drop Todd a line.

End users have it tough – the means of their supply chain comms are sternly dictated.  ”Top Down Hub Power” has a “blood cost” – and mid market solutions that promised to drive costs down for many EDI neophyte companies, hubs and spokes alike (or hubs that are spokes and spokes that are hubs), have not have not surfaced in a big way. As the Title of this Article suggests, APIs, and a platform orientation in general, will serve this market well by reinvigorating a spirit of innovation. By simply making the mechanics of EDI processing available to more programmers and entrepreneurs….we are seeding a potential renaissance where EDI Communication and trading partner management become native functions of B2B systems, rather then external services that are administered via interfaces that belong to the communications provider. That’s what platforms and API’s do, they allow the consumption of many functions from within a code base or resource.

While the EDI Service Providers of the 1990′s Era innovated web forms for the ultra low end of the supplier community, we need more aggressive price reductions and integration offerings for hosted and managed CLOBs = (Capital Line of Business Systems- ERP, major inventory and warehouse management systems, etc.). We believe that increasingly sophisticated yet easy to invoke API’s will kick off a revolution.

Compared to what I see in today’s Mobile App economy, mobile, etc., we have much work to do in EDI Communications and Network Management. Every application, every B2B SAAS system, every IDE, every PAAS, every software B2B asset should have EDI Comms built in and available.

Todd is furiously adding functions to ECGridOS, making it a true e-commerce operating system. See the bosses update release :

http://www.ld.com/november-2011-notes/

Even Todd’s November update is outdated, and we have new As2 features in the ECGridOS API, which makes Loren Data ECGrid the only EDI Network to offer hosted As2 via API with optional Message Routing via interconnects to VANs and other global systems. ECGrid OS is simply unique:

But, why take my word for how great ECGridOS is for B2B entrepreneurs? Don’t poo poo the concept of API’s being vital to the revitalization of the EDI communication’s economy –  Simply do the following:

1. Drop an email to awilensky @ LD.com and ask for developer credentials! I will honor as many requests as my hands can admin – (self-service enrollment is coming soon).
2. Skype me at awilensky  — I am glad to answer any question about the API, the EDI market, the dynamics of networked markets, interconnection politics, etc.
3. Sign up for our newsletter
   
4. Join the ECGrid Developer Forum – THE place where the truly competent B2B integration power people gather!
5. Check out the excellent API docs site
   
6. Here is a good one: Paste the ECGridOS API  WSDL URI into your web browser’s location bar and see ALL the functions of ECGridOS as unpacked WSDL !!! Hey, you can’t get better than that, because you can interactively invoke many of the functions right there! Try it, don’t be shy: https://ecgridos.net/v2.3/prod/ECGridOS.asmx

I can definitely tell you one of the top question I get about ECGridOS – here it is: Who is using it? Most of the folks asking this really mean, “what type of developer or B2B IT entity is using ECGridOS API Communications services?”

Here goes:

Tech Savvy B2B Entrepreneurs looking to differentiate their offerings:

1) NetEDI and Dimension Software use ECGridOS to add full, better than VAN-like Trading Partner Communications and Management  to their unique solutions. In the case of NetEDI, they have built, from the ground up, a complete EDI business using their extensive experience in B2B integration. The folks at NetEDI use ECGridOS as their communications engine and network management backbone, an anchor service that complements the company’s extensive other fully and seamlessly integrated services.  See their offerings at http://netedi.co.uk

Dimension Software uses ECGridOS to add EDI Communications to Orbis Task Centre – an advanced, encompassing BPM suite that is making its mark in the supply chain solutions arena. Jesper Carstensen now distinguished Dimension’s offerings by bringing fully integrated EDI Communications and vendor management to Orbis’ great BPM suite. I would actually say that calling Orbis Task Centre a “BPM” product misses the mark, its really a powerful  application environment.  See Dimension Software at http://dimensionsoftware.dk/

2) Established B2B Software Companies and Service Providers that want to make EDI as seamless and painless as possible for their customers.  What better way to take the sting out of EDI’s sometimes vexing comms management, than to integrate trading partner management and  EDI Communications into the software or B2B SAAS service?

ECGridOS gives established Supply chain IT vendors the edge with 150+ function calls,  including instant AS2 hub creation and fully routed EDI messaging to over 100 different VANs, direct hubs, Federal purchasing, and other EDI compatible systems, globally.

Examples of established B2B companies using both ECGrid and ECGridOS include: Radley, SPS Commerce (ECGrid), Energy Services Group, Epicor / Activant (coming live soon), Oakland Software, and Covalentworks.

How many developers are there, either in development or live on Loren Data Corp’s network?

We assigned developer credentials to around 45 developers, and we see active programming and debugging activity from about 15 of those, some 7 odd accounts suddenly start calling functions at long intervals, and the other half are inactive. NetEDI , Dimension Software and Radley are the leaders in API calling activity, while we expect another half dozen to go live in a big way within one year. We are keeping our collective eyes on Steve Redler at Thuman’s, the Deli Best Meats – because he is a coding monster.

If you have questions about ECGridOS features or activity, please drop an email to awilensky@LD.com or join our developer forum at http://forums.ecgrid.com/index.php    we also invite our readers to join our mailing list at http://ecgridos.com/ecgridos-developer-news-list-signup/

Todd not only writes an excellent post about what it means to be a business owner for 25 years, he also covers the company’s milestones and key players, past and present, who helped him forge the company into what it is today – one of the, if not the only, EDI Communications innovators. It is a really good read and provides a great deal of insight into what makes an entrepreneur tick. Check it out

Todd has posted a very weighty ‘letter to the industry‘. Todd founded Loren Data Corp in Marina Del Ray, CA, in the late 1980′s, or the “Netware” era. Todd lived and worked through several ‘grand epochs’ of software development; he delivered capital software systems during the aforementioned Novell Era, and continued with Microsoft’s NT and the associated Visual Studio IDE.

Todd has been self employed for his entire career – and at the helm of the company he founded for twenty-five years. Todd has acted as an anchor participant in the maturing stages of the EDI era, and still does today in his efforts to clean up routing and ID portability via directory services. Just as the Internet was being considered as a potential transport medium, he recounts, “many VANs of mid to late 1990′s had to be dragged into supporting IP-based protocol  transport, and off of bi-sync, kicking and screaming, While Loren Data Corp was first into IP transit.” – The point is that I am not pumping Todd’s reputation, he does not need me for this. However, I am an acting industry advocate for Loren Data Corp., and I need to point out the significant advancements that LD brings and has brought to the market. I can’t do that without calling attention to it’s founder, President,  Engineer, and CTO, Todd Gould. Todd is Loren Data Corp.

Todd and his Principal Staff see to it that the company does not offer ‘me-too’ services, or garden variety fare –  almost every facet of the company is either extraordinary or at the very least, damned damned good.

And, this company, an independent, communications specialty provider, oriented with a laser focus towards the Professional implementors of EDI Communications……is fighting for its life against what can only be called, “the evil empire of EDI”. So, therefore Todd wrote the above referenced letter to the industry, and I have cross posted the link here.

In my opinion, as an outsider, yet also as a participant in Loren Data’s ‘go to market‘ affairs, I perceive what may be a sorry, sorry state of affairs – If Todd and Company continue to bear this burden upon  solitary shoulders, then this crusade against an evil PE-funded, EDI conglomerate, will be for naught. And if not one kindred soul steps forward to voice their support….well, then I can only say that the EDI industry deserves a GXS hegemony; I can hear the obsequious yapping of an eager GXS court jester: :”Well, I for one, welcome our Gaithersburg overlords!”.

Whether your support is tangible in aiding Todd in his antitrust efforts against the beast, or if yours is only moral support – such would be considered nothing less than priceless.

Thankfully, due to Loren Data’s VP Netops Extraordinaire, Crystal Kuczynski’s consumate skill in internetwork relations, the company has never lost a byte of data, or dropped a single message; though  pitted against a company holding more centralized routing power than any other VAN. Loren Data has performed outstandingly despite being at war, and the company is actually stronger (in some ways) than ever.

But if Loren Data is somehow removed from the arena – it will mean that the one independent, sole API provider, the comms platform specialists…….will be gone…and Darth Vader, his financiers, and the entire Death Star of Gaithersburg will be unfettered to consume their next victims – and the shred of momentum that kept the art of communications moving forward in the EDI sector, will, for a time, end.

That’s the irony of what is at stake here…a spirit of innovation that is totally absent within Loren Data’s torpid opponent – -

Yet such Innovations burns bright at Loren Data Corp  - and is the company’s most basic and precious asset.

So, please, my colleagues, Support Loren Data Corp and Todd Gould in bringing equity back to the EDI Communications Business Sector.

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.

It’s  a cliche heard often: “we live in a connected world”; yet it rings true for individuals, professionals, and instituions that depend on such networks for vital personal and commercial communications. Just ask any teenager what being connected means to them.  We derive value by  connecting via our network providers, be they wired or wireless systems, EDI Networks, electric and natural gas utilities, all utilities, to be frank. Network Providers, in turn, enhance their value by cooperating with, and connecting to competitive network operators via interconnections, increasing the total reachable subscriber population.  We are now able to send a message to almost anyone around the globe via email or text message. Such communications ubiquity was considered a pipe dream as late as the 1970′s, before AT&T’s divestiture.  Many innovations  we today take for granted, have their roots in the breaking of AT&T’s monopoly. I will expand on the that historical concept a bit later.

Thus, we discover a term of art that is not  in common use: ‘Network Effect’ or ‘The Network Effect’.  The definition of Network Effect is: “Systems that grow in value as the number of connected subscribers and networked resources are increased. So, commensurate with the size of a networked population, such is the value of the network. Some markets could never be sustainable without putting strategies in place to specifically grow the user population – thus creating an incentive for new subscribers to get on board. Sometimes these strategies seem counterintuitive, such as when competitors interconnect with each other – not only out of necessity, but to increase the value of the market. An increase in network resources or subscriber population (they are the same), also confers on any one network additional influence – if one network is left unchecked to acquire competitors with abandon (with private or sovereign wealth), then network effects will lead to monopolies and an unhealthy competitive climate for innovation to occur (why would a business remain in the market, or continue funding its R&D if one competitor held the largest and / or most influential user populations).

We have always needed competitors to interconnect, which is obvious if you give it a little thought. No one network could possibly herd all of the world’s (or even one country’s) subscribers into its captive claws while fostering competition and innovation.  That very situation existed in the early 20th century –  from the founding of AT&T, to its decades long march buying up every local telephone provider and a few regionals, plus their colossal efforts to create the first, and for a time, the only long haul network – AT&T came as close as any to finding itself in the position of a “Beneficial Monopoly”. In other words, the government and AT&T’s attenuated competition just about gave up, ceding to AT&T the right to exist sans competitors. Thank goodness for MCI and Bill McGowan, and the DOJ, later the FCC, who stepped in and stopped such madness. AT&T remaining in control of the nation’s telecommunications would have left all of us bereft of an Internet, mobile phones, and countless other innovations we consider commonplace.

Today’s networked IP (Internet Protocol)  markets were designed from the start to be composed of a fabric of loosely interconnected ISP’s, Backbone transit networks, and private / commercial / educational / Government Internet Exchange Points (IXPs) – it’s a wonderful system that both capitalized on some of AT&Ts technology, Federal research funding,  and Bell Labs cooperation with other ARPA members (MITRE, BBN, GTE, countless defense contractors, and many Universities).

So, finally, we come to the Title of this article, ”The Essential Truths of Communications Infrastructure Providers – Their Conduct (and the standards) that we hold them to”.

Here are few to get the ball rolling:

#1) One essential truth applies to all Networks, and it is the above discussed network effect. We expect our Network providers to cooperate within their respective industries, to grow the user population by cooperative interconnection policys, while nurturing the technical standards for interoperability. The Internet is a model of open access for new entrants and original web based services, first and foremost due to the adherence to standards; comply with the standards and you can attach to the network. (SMTP for email, HTTP for web, DNS for address resolution, and many more). Standards and collegial interconnection policies are responsible for our fertile and robust Internet applications and infrastructure market. Think of it this way: email is great! You can send it anywhere, and with the exception of the very young, very very old (although many seniors  are enthusiastic Internet users), you can reach anyone via one standardized platform operated by countless independent ISPs. Not bad, eh?

#2) We hold our providers to certain standards of reliability, privacy, and general conduct – just look at the recent (and ongoing) Facebook problems regarding privacy (sharing too much), trust (disclosing personal data to third parties and law enforcement) , security (a vector for malware). We all have very low expectation of the United States Postal Service – I’m sorry, but they are the gold standard in mail delivery when compared to their overseas cousins –  and changes are in store for USPS that we won’t like; I could go on with examples from wireless carriers, fixed broadband providers, and utilities, but I’m sure the my readers reader get my gist. EDI users, VAN clients in particular, expect that their network members ID’s are not being re marketed, but the technology or audits to ensure privacy over routed VAN systems has never been extant.

#3) We also have expectations transcending performance and reliability.  We have every right to expect that our network operators will coexist and interoperate with their competition, thus creating a unified, global system via cooperative interconnections. We have this in telephone voice networks, in IP (Internet) networks, and all types of mobile applications (email & web, and more) built atop such networks that  inherent the power of the networks wide availability and reach. We fully expect email messages to find their destination – we have similar expectations of our voice services, text messages, and Internet services. We do not want to hear that a network provider has blocked or isolated our ‘reaching out‘ to other subscribers, on a competitive network.  Ditto for others that want to reach us from other networks.

The essential truth: We expect our data to flow, and that competitive leverage not be applied in any way to lessen or block any subscribers traffic – Short form, don’t use interconnections as a means of competitive force. Ugly ugly ugly, and we have a historical example:

Would you accept any service that stopped your email from reaching grandmother’s mailbox? What if certain websites became unavailable due to a competitive spat between your Internet provider, and a giant like Verizon? Only 40 years ago, a war was fought over AT&T’s hegemony over local and long distance telephony – however, the ultimate win or lose battle was fought over MCI’s rights to route calls to/ from the AT&T network. This was important because MCI had existing intrastate switching capacity that delivered better quality at lower rates to new corporate and residential customers. MCI did this by obtaining some of the first available COTS microwave relays equipment for multiplexing dozens of voice circuits (trunking) over a single microwave channel . However if MCI’s subscribers remained unable to reach 90% of USA telephone subscribers on AT&T’s mammoth long distance and local phone networks, (AT&T held the lion share of all local and long-distance markets), then operating as a competitor was of no use.

You see, networks are very different than other markets based on physical goods or stationary services – the total value of a connected market is directly commensurate with the interconnections that tie competitors together, creating an environment of services ubiquity, while expanding the total market. Interconnections Create the market’s entire value.

The above axiom regarding interconnections took hold after AT&T’s divestiture was finalized in the early 1980′s. Today, we can hardly imagine a market where your destination party’s network matters. It sure used to matter in the past,  where the time of call and the location of the called party would greatly impact pricing, in those days of AT&T’s hegemony. Those days are now over for telephony and IP networks., and in many more connected markets of which you may not be familiar with: petro and gas pipelines -  metropolitan ethernet (private data networks used by multi site businesses, and some internet access), cellular and SMR (digital two-way radio) tower backhaul, freight loading docks located at cross continent warehouses, and access to marine port facilities and airfreight terminals (even if privately owned by giants).

All of these markets share certain features, and are called, “essential facilities”, i.e., electronic communications or physical transport facilities grown to immense proportions, becoming, indispensable common carriers (common carriage means that a facility must service anyone willing to pay, and may be compelled to serve all comers).

Regulations control most common carriers, who and what may be compelled to grant common access to the ‘essential facilities’ (via interconnections) of their competitors. We have seen ample legal precedent for applying common carriage law to networks, such as power grids, access to technical service information, certain exclusive parts inventories, and geographically held physical advertising properties. Even general incentives (group discount programs), and physical access have been fair game for antitrust actions and the application of Common Carriage law. (several such ‘access marker’ cases were litigated in the famous Aspen Skiing v.  Aspen Highlands skiing chair-lift promotion case, where a smaller competitor was prevented from participation in a group lift ticket promotion, and use of a common, private road that was held by the larger competitor). All of the foregoing are examples of standards of conduct for network operators to consider.

That one landmark case of MCI v. AT&T, was  tied to DOJ and FCC antitrust actions, which eventually led to AT&T’s divestiture, and the appropriate tariffing to ensure that telephone services grew amidst thriving competition, producing a market that was accesible and transparent for consumers and businesses alike.

That’s an awful long preamble to just to get to the following statement: “We expect certain behaviors from network providers” –  In the following articles, I will connect this to the troubled state of EDI Communications via VAN, the exodus to AS2 and closed trading hubs, and the very mistaken trade-off we have bargained for in not supporting a fully addressable and routable system – one that is presently being perverted by one of its largest incumbent operators. Stay tuned.

“Why API?”, is shorthand for, “Who benefits from the 115+ functions in the ECGridOS EDI network management API“?

But first, would we be here at all without the burgeoning community of skilled developers who are now deploying ECGridOS as an integral part of their B2B solutions? I think not! Therefore, I acknowledge our most committed partners, and point most excitedly to their use cases. It’s all you, guys and gals, it’s all you.

Taking Bold Action: A mission critical comms sector in dire need of imaginative engineering – One man’s Solitary Quest:

Operating Systems offer communications services that underpin many applications. SMTP, HTTP, what have you, we expect the ability to access rich communications services as a native function on most platforms, IDE’s, and OS’es. EDI Communications have traditionally been left to the mercies of external service providers, and have not evolved to the point of ubiquity.

The limitations of today’s raw EDI communications services, from any point of view, is a sore subject. New entrants to the B2B market, those with the freshest ideas, and those in the vanguard of the On-Demand Enterprise 2.0 model, are the future of the ‘commerce cloud’ –  these operators are simply unfathomable sources of inspired ideas within their respective verticals, e.g.,  inventory integration, ERP, Logistics, Retail, and hundreds of other specialized market slices that are ripe for EDI aided solutions. These vertical and micro-vertical ventures deserve much better than the limited services offered from traditional EDI communications systems – they deserve native communications accesible from a custom code-base. The very best communications should be integrated with a system’s GUI, or otherwise be embedded at a fundamental level in the back end, resulting in completely transparent communications for the end-user. (Users should not be expected to know the details of EDI communications setup and transaction monitoring - and the fact that many end-users do indeed have to be involved with such arcana, is a blight upon the industry’s house).

Of course, until the advent of ECGridOS, the foregoing was not the case at all within the EDI Communications sector.  Veteran organizations who also suffer at the hands of the ’EDI status quo’ deserve to gain the ability to offer richer services, rather than being stymied by a communications palette that is limited to uploads and downloads, administrative interfaces via a provider’s web page or even more foul, a configuration regime where changes are updated via phone calls and emails to a Network Operations support queue. OMG Yikes (or, Yoicks)!

Such early 20th century communications methodologies are…..unseemly when cast into the role of supporting  and servicing today’s futuristic ‘B2B Commerce Clouds’. There simply must be a better way forward, because it is, after all, almost 2012 !!

Happy New Year

So, yes, EDI Communications has historically offered us a rather boring tableaux of options, and peering into the industry soul,  I see that not much has evolved of late. Therefore, at what point do we, as colleagues, demand the next evolution of B2B communications architecture? Who indeed will deliver such innovation?

The above state of affairs was foreseen years ago by Todd Gould, Loren Data Corp’s President and CTO. Quite independently, while I was working as a B2B Product Analyst, I felt that a change was absolutely necessary for EDI Communications to keep pace with a growing, on-demand world of web based applications.  My analyst’s marching orders were to address the cultural and architectural issues fermenting within the B2B sector. And now, in cooperation with Todd since 2009, we are working to promote the applied philosophy of EDI Communications delivered as a family of platform solutions.

ECGridOS (and the upcoming Superhub AS2 modular architecture) bolsters the ECGrid host network with a 115+function Web Services API – a callable, Domain Specific Library of remote functions, running on ECGrid Server racks in Loren Data Corp’s SAS70 Data Centers. ECGridOS and Superhub are far more than replacements for standard communications methodologies; the API can be invoked, mixed, and matched with FTP, AS2 (externally and within the API), or any channel supported by ECGrid, including SMTP and X400 mail systems.

ECGridOS is to EDI Communications what mobile application ecosystems are to the various app markets (including the communications plumbing) – creating opportunities for new classes of applications that are driven by the fertile imaginings of developers, as well as enhanced interoperability among collegial competitors of goodwill. We do see a richer, diverse, and more competitive market, arising from a well engineered communications platform architecture. Such open interoperability and carrier-class network management provides B2B end-users with more choices, competitive pricing, and a market encompassing true technological innovation. We believe that we have sown in fertile soil, and are prepared for an era of renewed innovation. Participation in new industry (communications) standards  will begin the reinvention of EDI Communications to its true nature – an applied science.

The vision: dozens of competitors building on a a set of defined platform APIs, resulting in an explosion of EDI applications, mashups, and ever more diverse end-users, while also automating what have become all too common –  horribly manual, repetitive, and vexing processes for end-users and network operators alike.

Our initial answer now is Loren Data Corp’s comprehensive communications architecture: (ECGrid / ECGridOS / Superhub), a masterwork under Todd’s engineering guidance. And, hopefully, my endeavors in addressing the philosophical barriers inherent in inter-platform EDI communications. We shall see. We are off to a good start.

How does one busta move in this business(translation, get in)?

The creation of ECGrid®, Loren Data Corp’s advanced host network, was driven by the early Service Providers (like SPS Commerce) who were seeking a next step in the evolution of communications technology. While VANs offered mailboxes, ECGrid offered node level attachement, where the industry at large offered support oriented to the end-user, ECGrid provided a “Responsible Party to Responsible Party” model of support. Where most EDI networks subsumed X12.56 mailbags, Todd engineered ECGrid to promote mailbags into first class, accessible objects. All of these refinements, and many, many more, were engineered into the ECGrid interconnection and message brokering fabric.

Loren Data Corp’s direct, first name basis support model, and its commitment to not service end-users, are bedrock underlying the founder’s long-term vision; Loren Data does not trample client relations by refraining from offering software, integration, or mapping services. Focusing solely on enhanced communications for professional service providers and a new crop of B2B Cloud operators, Todd and his team of five expert, principal operators, are reaping tangible results: ECGrid downtime has totaled less than 11 hours (scheduled and unscheduled) over the course of the last decade. (Furthermore, no outage has ever resulted in a 100% loss of connection availability or intersystem connection capacity, due to ECGrid’s disturbed design. Pretty smart, Todd.

Advanced B2B Ventures and OEM’s requiring an integrated, streamlined communications back-end designed from the ground up for on-demand B2B services, should investigate the ECGridOS API;  Currently, ECGridOS is the only  EDI intersystem commerce communications network granting complete operational authority to its clients. Savvy developers should peruse the online API docs at http://ecgridos.net API docs.

The implications of offering an EDI Communications platform API in the present-era B2B market is disruptive; especially for those giving the least bit of thought to the issues of EDI transaction management. With the industry in the midst of consolidation, upheaval, and some destructive actions driven by the fearful insecurities of its largest incumbent…. well, then, retaining full authority over your EDI Communications has never been more important. Therefore, I invite you to please, join us along with your colleagues who presently enjoy the security, independence, and substantial technical and support benefits of being ECGrid Clients.

I will end 2011 by rapidly publishing the following topical articles, before year’s end. Happy holiday, and a fine and profitable, spiritual new year.

Articles for year’s end:

The State of the B2B Communications Industry, from this analyst’s perspective

The “VAN Exodus” Dichotomy – what does it mean? Does it even exist? What could possibly replace a system that serves a population of 500,000+ VAN trading partners?

The essential truths of Communications infrastructure providers, and standards that we hold them to.

Todd has a new and insightful article about observing the flow of traffic through a busy EDI network, like ECGrid, and what it’s like to own and operate such a system. Read it here.

It was simply a matter of time until one of the foremost ECGridOS developers, NetEDI of the UK, scored another award for their superior integration offerings. We at Loren Data Corp are extremely gratified that Marc Nelson, Steve Martin, Mark See, and John Kearns, have persevered and built a powerful new business entry in what could only have been called until recently, a moribund EDI market.

With NetEDI gaining recognition from Sage UK for their superior innovation in integrating Sage’s offering with the world of EDI, well, I can only say, “hats off to the NetEDI team, what took you so long?”

Learn more about the fantastic, functional, cost-effective, and innovative product offerings of NetEDI. Read more about their recognition by Sage right here.

If you are operating a new or well established B2B venture that is dependent on EDI communications, just ask the guys at NetEDI – ECGridOS is the network infrastructure that you can build a business on.