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.

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.

Oakland Software is ready to Rock with EDInow!, an Eclipse-based Mapper and ESB Run-time Translator with fully integrated EDI Network management. And you can steer the Product’s final feature set by contacting Francis Upton, Oakland’s CTO, and getting into the beta program. Don’t be fooled by the beta status of EDInow – the beta program is just to refine the ECGridOS network management features in the otherwise mature Oakland Data Transformer EDI Tool Suite.

An email went out a few weeks ago announcing our new developer partner, Francis Upton, CTO and Founder of Oakland Software. Francis is a monster software engineer at the Top of his game, and he has been delivering his product ODT (Oakland Data Transformer) for quite some time to the Big Pharma market – a very demanding EDI market for the mapping and transformation experts in that field. Now, he is concentrating on delivering EDInow!, an Eclipse IDE based mapper – a mapper like no other. The EDInow tools from Oakland are based on an ESB, an Enterprise Service Bus, a super connector and runtime orchestrator ideal  for companies requiring the power to consolidate multiple data sources, apply  complex maps, generate custom code, and then run the translations in real time on Mulesoft ESB.

This is the future of EDI data management and communications. Have you been subjected to wining, dining, and a round of golf by the salespeople from the old line VANs?; that’s because they don’t have Jack to offer – nothing new to sell or demo, just the same old solutions. But Oakland and Loren Data Corp now bring you the latest, most up to date technology that is proven  and designed for demanding service providers, integrator / operators, and B2B Cloud Commerce ventures.  The combination of Eclipse, MuleESB, and ECGridOS is a killer combination for professionals whose needs are just not met by old line, smokestack era mapping tools. (ODT used by several prestigious companies for mapping and translation, and ECGridOS is used by a rapidly growing cadre of established and new EDI ventures).

Francis Designed EDInow to exceed the capabilities and power of “old-line” EDI mapping and translator offerings. There is nothing like EDInow, because it inherits the extensible power of Eclipse, the most popular Open Source Language Agnostic IDE, and Runs on the Proven Mulesoft ESB (soon other ESB’s as well).

I know there are B2B SAAS and EDI service providers that have been lurking and getting my emails, and you are waiting to make your architectural move to EDI for 3PL and other complex transactions that exceed the reach of most of the worn out old mappers that were designed in the Smokestack Era. And, the first group that gets in on Oakland’s Beta of EDInow will get hands-on support and help from the program’s author and engineer himself, Francis Upton -

Francis is very modest, perhaps too modest. He is one of the leading thinkers and doer’s of the data transformation world -in and outside of EDI. This is a rare opportunity to get plugged in, get the best tools, and expand your horizon as to what can be done with real power tools in an ESB environment. And, ECGridOS EDI network management is built in.

This future is here, and I invite all on the ECGridOS list to experience the future of EDI data management on Eclipse and Mulesoft ESB – life will never be the same for service providers and B2B Cloud Operators who have been frustrated with the limitations of Old Line EDI Tools – So See the EDInow details here.

Participate in the beta and demo-  by  Contacting Oakland Software here.

Anything in a press release must not be accepted at face value, especially concerning technical products or services touting the following terms: “Cloud, SAAS, PAAS”, and “Elastic”; watch out for any claims that attach to the cloud buzz of the day.  We include ourselves in this advice, as a provider of  hosted infrastructure services. Check us out.

I hope that you, the buyer of B2B services, will verify what we claim in regards to ECGridOS product collateral. We justify claims, show use cases, and have impeccable references. As a specialty EDI network with a service provider focus, we have to be real. As the only EDI VAN with a network management API, we have a short leap to show real functionality – ECGridOS either works and scales, or it does not work as specified. We can send you to several partners that have built their business on ECGridOS.

So, when we say, “embedded EDI communications” , we mean that you can consume ECGridOS function calls, and use them from within applications, bind them to custom code, call them from your UI, and make each and every integration server or ERP box a native communicator, not a 3rd class FTP citizen.

If you ever see the word, “Embedded”, be very cautious, because the marketing behind that statement most likely does not understand what such a term means in the world of data communications. Most sincerely, be careful with the pronouncements of embedded elastic services. Elasticity as a feature of hosted applications is very arcane subject matter that exists layers below your applications. For Bare Iron web scale systems, for multi-homed blade farms, and for other native OS and Virtualized computing environments, elasticity is an important concept for the engineers planning back-end computing and applications resource management.

However, for the EDI shop, your elasticity needs are levels below the nodes you connect to, and the responsibility for ensuring compute resources for your communications needs are taken very seriously by the Senior engineering staff of the VAN or EDI API provider (Hi!!!!), that you choose to power your B2B applications.

So, when a EDI sector giant, mostly without a clue, uses nomenclature that is so plainly out of their marketing department’s grasp, be sure to ask what they really mean.

Meanwhile, here at Loren Data Corp, we remain same folks who write the code, and operate the ECGrid EDI network for over 19,000 connected users, and refine the 90+ language functions of the ECGridOS API.

We will always be plain spoken about what we mean by the word, “embedded”.

Interconnected industries thrive when private policies and external politics liberalize the environment favoring ubiquitous meshing of networks. Whether roads or pipelines, telecom or ISP backbones, the reason we are here, reading and writing about EDI, bringing EDI Communications to the modern web, and into cloud platforms, is that we all ride on a globally meshed IP network that provides pathways for EDI messages. Private networks using  leased and analog, frame relay, i.e., VANs of the bygone era are gone. Some have survived to use secure tunneling to recreate private paths for EDI messages – but they are all otherwise connected.

However, VANs are not connected at messaging layer 7, and so we have an odd situation of VANs making individual interconnects on a network by network routing basis, at the message layer. These are VAN interconnects. Think Mailbags.

At Loren Data Corp, we know quite a bit about systems affecting VAN interconnects, as we provide interconnect management for eCommerce Service Providers, often knows as B2B Cloud Commerce Systems. We manage over 100 interconnects to a global cohort of VANs, Specialty Hubs, and Federal systems. We have a liberal Interconnect policy for the collegial commerce networks we connect to, and we base ECGrid interconnect policies on a short list of technical checks-offs. However, beyond technical competencies, netops support of the new network, our due diligence, etc., there is one overriding value that we adhere to that takes primacy above all, and we apply this at each stage of administering our liberal interconnections policies: The Primacy of the Trading Partners

When partners need to get trading, we take that responsibility seriously, and we make every effort to work with other bona fide commerce network operators to make Layer 7 interconnections as fast and painlessly as possible. ECGrid® Tech Operations is empowered to make interconnects with a fairly small data set, as long the trading partners on both ends of the relationship are on record as needing the interconnection. Rarely, we hear from a network, a specialized smaller operator, that does not support X12.56 Mailbag – and we always extend ourselves to help these folks out, even if we do not gain extra revenue in every case.  Why would any network go through the hassle of interconnecting to a smaller provider, when the upside is negligible? The answer is easy in every case: Because the Trading Partners Come First.

With over 18,000 active EDI trading ID’s on our network, and as the EDI backbone interconnection manager for several prestigious On-Demand commerce application providers, we take our charge as guardian of the transaction seriously. We interconnect liberally, so that our clients and their subscribers can choose the services that they feel are best for them. We never rely on any one criteria for enabling an interconnect, we judge the opportunity by how important the trading relationship is to our clients and their partners.

Are there problems brewing or already fermenting in the VAN interconnect system, especially after the recent mergers of GXS / Inovis and IBM  / Sterling? Yes, there are present problems and possibly other (solvable) problems with some x.400 EU networks, which are mostly cultural. But how far will certain network operators go before trade is damaged, and certain actions are seen for what they really are – blatant attempts to arbitrage interconnection in order to roll up the EDI industry into one MegaVAN? The coming months will be witness to a most active phase of legal and policy changes to the EDI and VAN system – that was once so obscure, but is increasingly being revealed to our regulators and the courts as a particularly vital resource to economy and trade.

You will never see such behavior at Loren Data Corp ECGrid; we specialize in enhancing electronic commerce, not disrupting it. ECGrid connects networks and service providers with the most modern, intelligent EDI routing network, and the only Web Services API designed  to empower developers and cloud integrators. Creating the technologies that enhance trading communities and streamline interconnection amongst the collegial cohort of cooperative Value Added Commerce System Operators, is exactly what we do.

And we love helping other innovators get the job done with the best EDI Network Services and support. The Trading Partner comes first at ECGrid, and that goes for both sides of the wire – for after all, they  come in delicious pairs!

Sign up here to Learn about the amazing ECGridOS API, the only service delivery platform granting full operational authority over EDI Communications via a programmable interface. GXS Doesn’t have it,  no one has an EDI Network API, but we do.

The  date is 11/22/2010  at 11:00AM EST – The Webinar will be recorded for later playback. But being there for the live webinar is better! You can ask us questions.

There are about 45 active and semi-active developers on the ECGridOS list and another 50 dabblers and interested parties that have engaged us over the past 14 months. It’s about everything that embedded EDI Networking can do for your products or B2B services. It’s time for a showcase. The event will be live via Webinar, Each Presenter 5-7 minutes (more if required) to show what they are doing.

Shameless Self Promotion is permitted if your product or speculative experimental Mashup uses ECGridOS in a clever way.

We will also have Todd and another top rated ECGridOS guru do a sprint of the functions in the IDE (not all 90, but will cover each family and show the relations between functions).

There are partnership opportunities in the E 2.0 communities and even competitive VANs can benefit from the component network model of ECGridOS Web Services – so start a conversation via the webinar, and take a walk through the ECGridOS functions. We have never done a live expert driven event before, with the father of ECGrid & ECGridOS, Todd Gould Himself. If you have a novel, mind bending Idea for EDI services never seen before, here is you chance to do business with a willing partner with a substantial, programmable (and that makes ALL the difference) EDI communications infrastructure.

Sign up here, If you are an ECGridOS developer and want more exposure , here is your chance to shine, we will be pushing this campaign to market.

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.

The Peanut Gallery: “Ain’t it easier to drop a file in an FTP Upload Directory, huh?” Let us RAP!

The EDI API Doctor, “Not if you manage 100′s and 1000′s of Users, Tenants, Machine and Process Relationships between 10,000 trading partners spread across 6,000 accounts in a managed cloud data center in a highly dynamic ecommerce environment – in short, B2B service providers that have outgrown EDI Account and Network control via manual processes.” That’s ECGridOS!

ECGridOS API is real stuff, and ECGrid is really not your daddy’s VAN. We service the high volume and dynamic multi-account ecommerce providers, who, until now, configured EDI as a one off per account process by actual human contact with legacy VANs….shiver. They (and you) need EDI Communications built in to their native code where it can be customized and invoked for self service by your hosted clients, or controlled centrally by your admins. OEM’s, SAAS B2B Hubs, and Cloud Data Centers all need fundamental EDI Comms; AS2 and FTP has outgrown their usefulness in On-Demand Service Delivery, where accounts are managed with stunning alacrity. And we sing about the real problems we have solved by giving our partners control over their own network – not some VAN’s Network, their very own.

We back this up with the best network operations team in the EDI Business – no third level support, no phone menus, or holding. The API will reduce Net Ops support by at least 50% by virtue of the platform being composed of repeatable and atomic processes that we use internally for Loren’s very critical Wholesale EDI transit operations. But when Netops are needed, you essentially have acces to an extension of your own support organization, responsible party to responsible party. Let us RAP!

New Sample code is up. And well commented,too, so that  the easy to read VB (virtually self documenting anyway) is even easier – so you Java, Ruby, and PHP cats can pretty much see what’s going on.

Each sample in the set shows a complete calling cycle of Loign() – functions() – and Logout(), there is no UI cruft, just console IO.
Anyone can see that the ECGridOS functions are pretty easy, the return data is understandable, and even the inner SOAP exceptions are easy to catch and work-in Todd makes it simple.

State of The ECGridOS EDI Communications API