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.

Todd has written a very clear topical post on a question we get all the time: “Is ECGrid a VAN?”, and  ”how do ECGrid and ECGridOS differ from typical VANs?”

Todd goes through the differentiation and has a great chart, and then explains the competitive politics relating to companies that want to operate as VANs, or as Service Providers. It’s an excellent post, one of his very best.

See Here

Todd has posted a December update http://www.ld.com/december-2011-notes/

To expand on Todd’s update of the Loren Data Corp v. GXS antitrust appeal, Glenn Manishin, our new attorney for all matters going forward, is quite the force in telecom antitrust, Internet, and technology law practice areas - Atty. Manishin was a former DOJ litigator intimately involved in the landmark DOJ antitrust case, United States v. Microsoft, and also played a role in the AT&T divestiture while at Justice.

Atty. Manishin also blogs prolifically at  http://law.manishin.com/

Did you ever wonder  - “what’s involved in bringing an expansive, transactional API to market? What’s it like being the sole EDI Network management API provider? What’s it like to care and feed the ECGridOS API, supporting it, keeping its domain specific syntax relevant, comprehensive,  and easy to use? There’s no other EDI Communications provider offering a platform API; I think if you read the rest of this post, you will see, in part, why there is only one EDI Network Management API Platform provider.

Take a glimpse into the world of “the hardest working man in the EDI Communications business”, while you take a quick look at this link, which is a list of ECGridOS API revisions chronicling Todd’s updates to the API. Wow. That is quite the tour de force, in my opinion. One man and his machines.

To call our President, Todd Gould, a programmer, would be like calling Werner von Braun a rocket technician. Todd runs the company, manages the key accounts with assistance from our incredibly competent VP, Crystal Kuczynski, and our GM of Contracts, Kristine Finlay.

Todd is the sole architect and performs all software engineering for ECGrid – multithreaded core code and I/O modules controlling hundreds of VPNs, dozen’s of FTP and AS2 clusters, EDI software routers and comms node handlers, the mail bagging, archiving, and the administration of MS SQL fault tolerant database running > a million daily database operations, triggers, and stored procedures. All of the love and attention given to ECGrid is purely at the service of our clients, specialized B2B service providers who depend on ECGrid for their EDI Data Communications. All of our network members totaling 23,000 QIDs (addresses) are the beneficiaries of the advanced architecture of ECGrid and ECGridOS API. Not bad at all for a specialized Commerce Data Communications network –  eh?

Never content to sit on laurels, Todd has a product roadmap stretching out at least 36 months. The roadmap is a living thing, and is fed by my industry research, working with our expanding network of developer partners, and from suggestions from major accounts. At the base of the magic is ECGrid, a multitenant EDI Routing system that is, in its native functionality, far ahead of any competing EDI Communications system – but how am I so sure ?

The answer is ECGridOS, the web services API platform for EDI Communications; this allows our partners to write custom EDI applications, or to embed user accesible EDI functionality within Enterprise Software, such as ERP and Logistics management suites.

The ECGridOS API now gains AS2 functionality, and is now in stable beta, with release to developer access before the end of the 2011.  This is an important milestone for the EDI communications community. Here are a few thoughts about why As2 communications was added to the ECGridOS API (a multi-network, mailbag-managed routing system):

As2 is….something else. At first glance, AS2 looks great, with direct connections between the trading partners, secure certificates, HTTPS transport. In other words,  AS2 looks like the answer to what some perceive as our present-day VAN ills (that’s another article). Until one experiences the pleasures of maintaining and operating a large AS2 system servicing dozens, hundreds, or thousands of trading parters, one can’t imagine the complexities ensuing from AS2. Most of the pains are inflicted upon the administrators, especially inexperienced As2 hub operators that are new to the game of communications infrastructure and the direct support of arms length trading parters. All good fun. Not.

Sometimes, a new hub initiative travels down the As2 primrose path, and then finds that they have gone too far, it’s too late to gracefully back out the trading partners onto the (marginally) more rational, routed VAN services. That’s the story we often hear: As2 was thought to be a messiah, yet after adding the thirty-seventh trading parter, things started falling apart, operationally speaking. Big support headaches, big licensing, software support fees, an expanding gang of dedicated machinery,  and never ending End User (trading partner) support calls! I can hear my grandmother saying, “oy vey” (“oh pain”, but much is lost in translation).

AS2, as run by large hubs, is famous for massive and unwieldy “forced march” certificate change overs. Changes to trading partner As2 IDs, the URIs on both ends, firewall port configuration nightmares, etc. Shall I go on?  The lesson here is that internally run and maintained As2 may be an acceptable communications channel for some, a burden for many, (trading partners) yet in any case, is never a picnic for the largest trading hubs.

For the few enamored of large, self-administered As2 systems, that’s great, I will not take issue, however, ECGridOS As2 will improve any organization’s operational efficiency.

I am rather evangelizing 97% of the largest retailers, manufacturers, and logistics operators that have had their sanity stolen by in-house As2. Our brave EDI Service Providers, the communications experts we specialize in serving, also complain about AS2 management headaches they experience in the course of supporting several hundreds to thousands of As2 spoke users.

ECGridOS As2 Web Services allows developers to command a powerful, multi-tenant communications cluster with centralized directory services and certificate management. The AS2 instances you create are accesible by any method supported by the ECGrid host network – FTP, SFTP, As2, Web Services parcel up/down, X400 SMTP.

Salvation is now at hand with ECGridOS AS2. Developers may now create, command, and embed the functionality of the EDI industry’s most sophisticated and trusted communications cluster, unifying both VAN routed communications via standard interconnects, and AS2 communications. Such functionality cannot be purchased or licensed at any price. Yes, there are hosted As2 systems, and they seem as difficult to administer as licensed As2 software packages. For example certificate management in most managed As2 systems seems as fraught as licensed software. Thankfully, ECGridOS As2 is an EDI  Service Providers or in-house developer’s dream.

AS2 instances runs on ECGrid’s infrastructure, residing in a best in class (Sungard) SAS70 data center. No hardware is required, and all of flexibility of ECGridOS (110 Function API) is retained. You will have total control over account creation,  mailboxes, reporting, sessions, security, certificates, tracking, and more. The power in bringing As2 communications to the proven ECGridOS Web services API, remedies the inherent deficiencies of in-house, licensed As2 systems.

If you don’t yet understand my enthusiasm, please go see our API Docs here. This is big.

Making  As2 communications a managed protocol within the ECGridOS EDI network management API is the one of the most newsworthy items I have seen in 2011 – it makes perfect sense, too, as ECGrid, ECGridOS, and now ECGridOS AS2 have all innovations of and by Todd Gould, President of Loren Data Corp, and possibly the EDI industry’s most prolific and far seeing communications engineer.

If you are interested in development using ECGridOS, including the As2 extensions, or would like a quote on standard communications on ECGrid at great wholesale rates, drop us a line or call. Remember, developer API accounts are free until you enroll  production users. We also have flexible account models for every type of Service Provider, Enterprise Software OEMs (build EDI into your applications, instead of sending your customers packing for an external solution).