Blog post

SaaS APIs are Retro – You Know, Just Like EDI

By Benoit Lheureux | March 17, 2009 | 3 Comments

SaaS Integration

The CEO of a respectable mid-sized supply chain integration company has a clever schtick to convince prospective customers that they don’t *want* to do B2B integration themselves – he keeps a pile of thick plastic binders stuffed with various retailer EDI implementation guides in his executive conference room.

EDI specifications are generally heavyweight – often 25 to 75 or more pages. For example, Target’s EDI 850 (Purchase Order) Implementation Guide is 48 pages long. Despite standards even the ubiquitous EDI 850 purchase order varies substantially from supply chain to supply chain. (“Standards are great – everyone should have one!”).

The “EDI binder” schtick is clever because the degree of EDI complexity and diversity is daunting – so many companies often can’t or won’t deal with EDI themselves. FUD generates business, right?

So what about SaaS API’s? These are proliferating to the same degree that SaaS solutions are proliferating, i.e., fast. Are SaaS API’s better, i.e., easier to deal with, than EDI specifications?

In some ways, yes. For example, SaaS API’s are typically implemented using Web services via SOAP, REST or other Web technologies. You can directly execute these using any modern Web-enabled middleware and application development tools. This is generally easier than translating EDI, then importing or exporting data from applications.

But are SaaS API’s any less complex than EDI? Or any less diverse? Consider:

The dirty little secret of SaaS API’s is the “Devil in the Detail” – that, yes – like EDI, these specifications are, generally speaking, remarkably complex and diverse.

Robert Mitchell of ComputerWorld has learned that SaaS integration a leading cause of IT headaches – but many IT users are only now beginning to realize its complexity. But some companies understand this complexity – which may explain why offers 90+ SaaS integration solutions across 40+ 3rd-party technology partners. This may explain why there’s a whole cottage industry of IT vendors (e.g., Boomi, Cast Iron, Pervasive, et al) that are focused on SaaS integration solutions.

It’s because, well, you know, SaaS APIs are cool – in an EDI Retro sort of way. 🙂

Comments are closed


  • Simon Peel says:

    It’s great to see someone expose the myth that all you need is an API and suddenly the integration problem goes away. It’s also worth saying that even if you do wade through the API manuals for each of the disparate systems you’re connecting and manage to write the code required to establish a connection, you’ve still only addressed the connectivity issue. You’re on your own when it comes to transformation, workflow and run-time monitoring, which it gets really tricky and where all the time really goes. Then if you make it that far you get to rare treat of maintaining that code forever as the endpoints endlessley change while sysadmin’s point and click their way to adding field after field in SaaS heaven. Why bother when you can make the entire problem go away in days and make it someone else’s problem forever, while cutting your costs by 80% at the same time? Newsflash: the wheel has already been invented, has thousands of published deployments and is probably at least worth a quick look.

  • FYI, Robert Mitchell of Computerworld just posted a decent article on the challenges of SaaS Integration @

  • The integration problems facing EDI are split into two legacy areas:

    1) The mapping and translation of the commerce docs to the relational tables and internal record structures of ERP systems – while the industry as a whole makes HUGE progress in decoupling the strictures of exchanging data between source and destination schemas, the EDI industry has kept the lid on manual mapping and testing, in order to preserve the EDI reseller and service bureau industry.

    2) Communications. EDI is captive to a set of privately routed mailboxes administered by Value Added Networks. As time has progressed, these VANs have become more like VARs with IPSEC routing agreements between them.

    Any control over EDI communications has been, historically, via the VANs external administrative services, a web interface, forms, phone, or email to net ops. This, plus the metering of KC’s, is an anachronism in this world of ubiquitous, intelligent, internet based IP routing.

    Loren Data Corp, as far as I know, is the only company supplying an API for EDI communications, and carries the torch at every X12 industry meeting for the advocacy of open EDI message routing.

    I work with the President, Todd Gould, and if people knew the sacrifices he and his company makes to stimulate modernization in the EDI communications industry, they would beatify him as a technology saint. Todd has sponsored several VAN summits, and I work with him to stimulate the use of the ECGridOS web services EDI communications API. We often grant test accounts and give massive amounts of technical hand-holding to early adopters of our API.

    We want to change the industry for the better – and no, API’s are not a panacea, but the lack of them has greatly hampered the interoperability of what could be a very power systems, i.e., the established system of 100,00’s of EDI Qualifier ID’s and routes to every merchant on planet earth.