With less of my pre-ambling than usual as commentary, Todd has posted an article that is deeper than its title suggests, and is quite timely and pertinent to our market: http://www.ld.com/to-build-or-to-buy-that-is-the-question/

My 2 cents:
The build / buy decision for B2B service providers  of the new era is not the same as a build / buy decision for enterprise software buyers; there are services that you will never build, and services that you can’t buy at any price.

New ventures aspiring to provide more than generic partner connections, those building a new class of advanced B2B Cloud solutions, have access to an overabundance of “me too” EDI mailbox services. If you really wanted to build a vanilla grade VAN from the ground up, I doubt it could be done quickly, on any reasonable budget. Negotiating internetwork agreements is far more fraught today than it ever was in the heyday of the VAN’s innocence –  when the industry grew like a wild weed.

Creating a web services communications platform on the scale of ECGridOS and ECGrid (the interconnection and routing engine), would take many man-years, the testing alone would swamp all but the likes of an IBM or Oracle. So, it is easy to answer the question: “Why did IBM buy Sterling after selling a most wonderful IE VAN?” It’s plainly too difficult to re-interconnect, tidy up all of the channel customizations, reestablish personal relationships, etc., when the in-house expertise has gone with the wind.

This is also why a behemoth, such as GXS, does not offer a communications API via REST or web services. Communications APIs are difficult, long term undertakings – Todd has been crafting the underlying architecture of ECGridOS and ECGrid since 1997 – one does not uncork such a mission critical communications API in a few months or even a year, regardless of the size of one’s off-shore development staff. For competitive reasons as well, GXS caters to corporate end-users,  while opposed to Loren Data Corps focuses on multitenant, Cloud B2B service providers and OEM Enterprise Software vendors.

Loren Data Corp ECGrid is completely focused on the service provider – we do not service end users – therefore the vein of philosophical divergence runs fairly deep between ECGridOS, crafted for the B2B SAAS / PAAS / Cloud operators, and the rather limited fare of FTP upload and download mailboxes, and the similarly limited, and unfulfilled  promise of AS2.

Fortunately, we are taking a completely fresh look at AS2, top to bottom, and reinventing it for a new vanguard of B2B service providers. Stay Tuned.

Wouldn’t you just love to know about  the profoundly messed up routing architecture of VANs, how they work, and what kind of software and systems they use? How do VANs  implement 12.56 interVAN signaling? Interested?

Well, you are out of luck. There is precious little or no software available for VAN operations, and absolutely no commercial software that can be unwrapped, installed, and delivered to enable, “here is your VAN, yo!”

Most VANs have some code, some OS scripts, and some backend DB stuff for account management. The level of systematic cohesion to manage accounts at the Professional Service Provider level is questionable. The ability to handle mass account migrations and even the daily system level support of an SPS or DiCentral type of account, with 10′s of thousands of users is a crapshoot. But if we did want to see the fundamental primitive operations of an EDI Network, where could we see it, if we so desired. I’m glad you asked.

The ECGridOS API Documents exposes all of the external fundamental operations of a high-usage EDI Network.  Anyone can become an ECGridOS network, we offer free accounts for test and development. But the underlying infrastructure of the machines, code and Net Ops interfaces are of course, another matter altogether. One could adapt, as NetEDI has, a complete B2B commerce network upon ECGridOS. Constructing the data center, or even cloud services based architectures, from scratch assumes knowledge of the VAN world, the basic EDI file header parsing, and all the 12.56 happy horse hockey. The machinery is one thing, the cloud costs are another, the fact there is no commercial stack for VAN Ops is is the coup de grace.

BTW? What is the Real Difference between a Service Provider and a VAN? Just ponder that for a minute.

Now, if you wanted to see what underlies the VAN technical Ops, you could do that by taking a hard look the ECGridOS.net site docs. There are 90+ SOAP Calls and a WSDL description file that packs up the functions for Integrate Code Editors like Eclipse and Visual Studio, there are many ways to inspect ECGridOS Netops API functions, including a linear list here.

So, let’s say you have no interest in becoming a developer or client of Loren Data ECGridOS, or even ECGrid® - but you want to know the down and dirty business of how to create VAN technical operational s solutions? Well, if I were you, I would click on the WSDL link, or better yet, get one of the tools to unwrap the WSDL and inspect the SOAP Function Calls that comprise ECGridOS – and now, there are 90 of them covering every conceivable aspect of running an EDI network -  including some functions that most VANs simply can’t do. I will not say what these are, but clever, savvy programmers and engineers will look at the ECGridOS API and say, “I can do a great deal more than commerce functions, there is whole network file systems here with manifest management an a plug-gable routes configuration.  Say whaaaattt? Yes, we knew, rather Todd knew long ago that the VAN based start connection scheme was a loser – and that just like the internet that all of our traffic goes through, EDI will, eventually, be hierarchically routed. VAN interconnections are for chumps, and we have started the liberation with ECGridOS – use one web services connections and get all of your interconnections here with Loren Data Corp, at the best rates, until the tyrannical system of KC’s and BIGVAN hegemony is killed off in a year or two with our fellow colleagues and EDI rebels, and the cadre is gathering, I promise you by my life.

Because the code level integration of ECGridOS allows EDI Network functions to be glued into products or SAAS services, you are the VAN, you are the network and the comms functions now reside in your product. You shall assign functionality to users what you have always wanted to grant and access, but never had the chance in the old world of VANs, as you had to go to a web page to set mailbox configurations, or email the man at the VAN, or call some drone on the phone. Those days are so over.

The ECGridOS SOAP function list proves that you can recreate a VAN’s communications repertoire. That’s what we did. ECGridOS did not exist before ECGrid® did!

We have operated ECGrid for over ten years as a very busy, viable, commercial EDI Network hosting the largest On-Demand commerce companies, like SPS Commerce, ESG, and many others. We already owned and operated VAN infrastructure that exceeded the largest VANs, who are actually particularly  not technologically agile at all. The industry standard has remained rather stagnant with FTP and As2 handing off files that you practically kiss goodbye after sending.  The VAN world has been woefully inert.

But, ECGrid supports directory services and manifests – so we rolled up our sleeves, and created a Web Services proxy and a new Domain Specific Language for ECGrid – OS.

This is how you make a VAN

That’s right: We created a VAN operating system for EDI communications and trading partner community management. It is a fine, state of the art system where a service provider, one who has everything except VAN interconnects, can create an entire suite of VAN and managed file transfer OS integrated services, including user control sessions, mailboxes, well, come on, there are 90 functions here. Better than FTP, AS2, better that any large MegaVAN, supported by a community of developers and the principal network engineers. Yikes. So much better.

So to create a new VAN, study the ECGridOS functions. Then, buy a data center and create the application calling code, hire a net ops staff, and get your first clients to subsidize cashflow, then call us back, because in the end, you will really really need ECGridOS, because you will be broke by that time! Just ask Edison Carter, he knows.

Or, just start with ECGridOS. We did this all for you, for anyone who has thought or said, “How can I be my own VAN?”.

ECGrid handles the traffic of 18,000 active trading partners. These trading partners average over 30,000 transaction per 24 hrs. This graph shows the system processing mid week 72 hrs spikes, seeming to indicate a retailer holiday orders, but there is no way to actually know, because we do not look beyond the ISA headers.

ECGrid At Work

We need to fix a broken global ecommerce communications industry.  There is an increasing industry-wide march to what seems like an unviable future path with  fewer choices:

1) We have a system of increasingly larger VANs, and fewer of them

2) More ‘Top of the Chain’ companies are leaving routed EDI Networks, those that have typically cooperated with interconnections, and are now standing up closed hubs, suppliers be damned.

3) After all, who cares how many FTP and As2 connections and certificates you need to connect to? Dozens of closed trading communities? Stress, lack of scalability, and the increasing fracture of global trade is your legacy.

4) Private hubs with large partner communities that insist on no-cost attachments. They do not realize the damage this is causing, as their systems ops, while competent, are no match for what they are taking on. Think twice.

5) The motivations for ‘going hub wild’ are pure. We sympathize that the ecommerce communications market has made managing trading partners a crazy and frustrating business. We try and address these issues with the best wholesale, service provider only EDI host network that connects everywhere.

6) Last but not least: The largest EDI Communications networks must act like good shepherds and good corporate citizens, participate in equal peer routing, and in standards like the X12 Connectivity Caucus,  please act as the good peers you used to be, and stop the trade damaging madness. You can turn it around guys.

This is really not a post to beat the ECGridOS horse, but the fact is:

Back in the late 1990′s, the seminal idea for creating a “network of networks”, an EDI routing and interconnection broker architecture, mediated by the best technology and operations standards, was in response to these nascent issues of broken, high maintenance routes.   We continue to strive, to work with colleagues and peer networks, to further automate interconnects and partner pairings, directory services, etc. Web Services standards are tailor made for such network to network agent communications.

That was the whole raison detre of ECGrid and ECGridOS.  I want influencers to think for a minute: as the mid market starts to look at better and more available B2B systems (not just bottom up supply chains), we have an opportunity to streamline and automate, instead of fracture and isolate. Serendipitous trading partner discovery will never happen with closed hubs sprouting like weeds, and with the leading VANs holding down industry innovators with fat, furry paws.

Now, it’s your business, your prerogative as to your choice of communications topology - I just want the issues aired and the alternatives exposed. This is not just a boost for Loren Data Corp alternatives, either. As a network that connects wholesale accounts only, we have a provincial yet compelling, interest in the ultimate evolution of our industry.

Having been in the game since 1987 and operating the 18,000 partner ECGrid EDI network since 2001 – it just gives us a perspective. Rather than simply complaining, we have proposals, just make contact with us, anytime. And join the Caucus.

A reminder to our key developer partners:

Our commitment is to your success – assistance with architecture or API issues, special account features, etc., are close at hand. When hands-on API help is needed, we are here. The ECGridOS developer community is growing, and more peer help becomes  available daily, on-line, but we recognize that fiercely independent developers in stealth mode must carry on like quiet commandos. 

We also ask prominent ECGridOS developers to participate in defining the future of ECGridOS API services in .(DOT) releases.

We are floating more network level controls, better message tracking between systems, and we are outlining specs for automated partner pairing, over the network. Much of this work arises out of the x12 Connectivity Caucus, which we participate in.
Before year’s end, a feature and bug management systems portal for ECGridOS developers will facilitate your involvement in the ECGridOS API architecture.

As the API evangelist, I understand the problem of offering merely “better” technology. Better is better, but  ”strategic fit” of the organizations is even more important. I bring strategic partners into our planning process. It can take a year to release new ECGridOS API functions, and many things are happening right now in the X12 Connectivity Caucus, such as WS Reliable Messaging, TA3, and network invokable  methods for automated partner pairing.

These trends will find expression in various EDI network provider’s tool sets, and we want our partners to have a look at what we will be proposing and delivering, and to have a say in how we deliver these new Network API’s. 

EDI Communications is about to enter an important transformational period, and we should be working together.  This is especially true as Loren Data Corp is not like other VANs, we do not service end users, and we do not offer solutions – we exist solely for B2B application providers, and we treat these strategic partnerships with great care.

We have been a branded EDI network since 2001, and a EDI solutions company since the 1980’s, we are positioned to thrive, even in today’s consolidated industry. The aftermath of recent mergers are big industry events, no doubt, and we meet the changes with relish.

We are holding true to our pledge of independence as a pure network.  This strategy is surely working, drawing in more influential partners – indeed we increase our parity with the largest VANs, and this fact stands us in good stead as  your EDI communications network partner.  After all, ECGridOS was built to manage large and diverse multi-tenant user populations.

Umair Haque is my hero, he thinks and writes profoundly about the mess our economy is in due to the past era of profligate spending, credit creation, and stoopid institutional investment practices – social Networks for Cats….if you get my drift.

Who's yo EDI Daddy?

here is a link to Umair’s blog. he writes with wit and brevity.

In the Business Process Enabling Industry, we have (for so long), seen the leaders of our market sector sit on their hands, buy up other companies, run crappy networks and innovate nada. It has been a waste of capital that will be hard to recover. Oversized, laggard technology, with too much liquidity ill-spent and allocated by “others” – it’s a bad recipe for innovation.

We must look to lean innovators who create new contemporary systems and methods that answer current needs.  ECGridOS is the only EDI Network with API controls for the multitenant crowd, but there certainly are other lean innovators. SPS Commerce, a Loren Data Corp client, with a recent IPO in a dry climate, was one of the first companies to make on-demand supply chain a reality, and there are others. There are tool-smiths aplenty, and not all are B2B systems. As the old guard ages, I see the next wave of value coming from application services on-demand.

There is something about the multitenant model that answers a unique set of problems for the Small to Medium Enterprise, the SME we hear so mich about. I used to jawbone with the analysts in the 06-07 era. They had resources to commission expensive and expansive quantitative surveys. They thought there might be 5-10 Billion additional dollars waiting with the SME for supplier enablement. And now we know that this is true.

The manufacturing verticals and alternative enterprise software companies (open source, SAAS ERP), are seeing an increase in business through the last two years of the recession. It seems their special sauce delivers the exact streamlining  of labor and multiplication of effort that the big B2B companies have totally missed by MILES. We are happy that ECGridOS API is helping this renaissance along for our Cloud Commerce disruptors, our EDI Cowboys, and On-Demand B2B scientists (you geeks) that have adopted our API.

They know there is no better way to integrate EDI Communications into a custom code base. So there.

Back to Umair Haque. Umair says that recovery of capital and the skilled jobs can take years, unless innovators start putting their technology into the hands of hungry entrepreneurs who really, really have the desire to succeed; then the inventor ecosystem can start to lift the economy off the ground.

We can’t do it in isolation, no matter how innovative, hardworking, regardless of how much better ECGrid Network support is; it will never be enough. to turn our industry from the torpor endured at the hands of the overweight and un-innovative old-line B2B companies. But you can create the next great SME B2B applications with a killer EDI feature set. That’ll show ‘em!

Our Pledge to you, our Present and Future ECGridOS developers and the ventures based on the The Loren Data Corp API:

1) We will give you All: all the help, support, and co marketing you can handle.

2) We will never make it solely about Money. We want you to lift off and earn, we will help with that reallocation of technical capital

3) We will be there even when it gets tough. we never sell out our partners for a dollar.

4) We will keep you in the loop. Always.

Thank you Umair, you have inspired me to suck it up for another term and take it to the market. Thank you Todd and Company, for allowing me to speak the truth, no matter what short-term deficits result. Thank you Edison Carter, EDI Guy, for being the muse that helped me write the song.

Non API Stuff, But I really can’t get away from it!

Hey, I am the EDI API Guy pushing a 90 function API, but if you are upload and download guys, read on:

Todd Gould, Loren Data Corp’s Founder, Engineer, Guru, and Respected man about x12 says to me:

We can  cut 10′s of  thousands off of your FTP and AS2 systems budget. Yes we Can! If you run in-house FTP or As2, call us, we will save you big time power, reduce or eliminate support, streamlined operations, all while offering real routes, not dead end connections -

9) We know you went in-house due to VAN Frustration – We Totally Get It – We can solve that problem – Your Frankenstein Experiment was noble but it is over now!

As the only EDI Communications Network offering access via API (application programming interface), we must take the lead in creating services that optimize EDI Networking for the Industry Power Providers.  We are a small company, we compete on technical merit and differentiation, on uptime, or handling exceptional network considerations. When things are going well with brand ‘X’ Value Added Network, who cares? When things go very, very wrong…then you want real NetOps, the engineers and owners of the network to handle your massive issues. At Loren Data Corps ECGrid® Netops, the engineers and network owners cover all three support shifts. But there is so much more to the story than “better Netops”!

ECGridOS is the only Web Services API Gateway offering globally routed EDI. We interconnect with a long list of VANs and ecommerce providers; we handle the internetwork peering relationships with cool competence. ECGridOS Network developers, building EDI Communications into products (or as the SAAS B2B system connection), attain a higher level of reliability. If your company runs an in-house As2 or FTP  out of VAN-Frustration, we bring back sanity and save big  money.

We enhance operational reliability. It is all in the EDI Song. Web Services Message handling is the best and most reliable handler of messages – it just is….better than FTP or As2. 

ECGridOS allows ecommerce services, such as on-demand SAAS providers, to assert the EDI Communications authority of a Network Owner – be that a white-label provider, or as a licensed product that has client EDI functions built in – it’s a step up in reliability. If you look at the ECGridOS API Docs , you can see that there are parcel and mailbox functions for detecting network level message issues and failures. By being in greater control over the parcel, you can automate recovery.

Network and message delivery error handling will become even easier, with a set of objects for message recovery. A new implementations of Recipient System Verification, the Proposed ANSI X12 TA3 Standard for Recipient message notification will be introduced by Todd Gould, Loren Data Corp’s President, to the X12 Connectivity Caucus, as a proposed implementation. The whole industry will benefit.

As2 and FTP based systems have limitations in regards to failure recovery. As2 is barely any better in actual practice than FTP. The only people stumping for AS2 are System Administration Gurus who babysit AS2 clusters. We love you guys, but ECGridOS is better, reports better status, implements recovery routines, and is backed with better netops.

We are always better at Netops that an in-house teams – no offense. We offer globally routed connections. Hub and spoke As2 systems, go from system hub to the trading partner. They feel that they are dead-ending, with no routes, with multiple hubs making them repeatedly configure new connections, where there is no upside.

Most larger ECGridOS  accounts are EDI Services Providers, on-demand B2B powerhouses , our ‘never say die’ customers, moving massive volumes of messages. These companies will see the immediate impact of Recipient System Verification. Why, whats the bottom line?

1) Using the API allows competent systems programmers to automate message failure recovery, and to detect message status at the session and network mailbag level

2) This type of granular control only exists in ECGridOS – no legacy EDI Comms service using FTP or As2 can match the kind of error recovery that can pass parameters to your program logic

3) EDI service is all about “exceptions”  - most of the time, things are fine, it is when they are NOT FINE that really counts and distinguishes a real network from a FTP upload and download service

So you want innovation? Evolution of the state of the art? Where are you going to get EDI network services if you are one of a new breed of service providers, a super B2B application hub, an On Demand B2B Power House?

Are you going to BE an EDI Network, or ever more dependent on the increasingly consolidated EDI communications provider market?  Be you OWN EDI Network, with ECGridOS – Sing the Song

If you are planning a new, ground-breaking B2B application, a SAAS ecommerce venture, or are contemplating EDI Communications as an integral product feature (i.e. liberating your customers from external EDI systems), then we have a briefing for you in our Scribd document collection. This briefing covers the different features of ECGrid and ECGridOS, and the various models of Network Ops.  Being your own EDI network is a new model for the B2B ecommerce industry, and  we lay it all out.

CTO’s and Product Managers Briefing