Blog post

In the age of APIs why do 2 million companies interact via B2B networks? (Hint: “B2B Tower of Bable”)

By Benoit Lheureux | August 25, 2015 | 0 Comments

Integration BrokerageIntegrationB2BAPIs

While doing primary research in preparation for our soon-to-be published Market Guide for Integration Brokerage I’ve discovered that over 2 million companies (growing, fast) world-wide connect and interact electronically with each other via B2B networks, such as those operated by Comarch, E2open, IBM, Liaison Technologies, OpenText, SAP, SPS Commerce and Tieto.

In the age of fast-proliferating point-to-point consumption of API’s directly between businesses, such growth on these B2B networks may seem odd. The secret to understanding why B2B networks are – and will continue to remain – relevant in the API age is to understand the challenge of semantic reconciliation, aka the “B2B Tower of Bable”.

Let’s look at B2B interactions through the lens of the most ubiquitous form of B2B interaction – the purchase order – and think about it in terms of “who calls the shots”. If you’re Wal-Mart (“do you want to sell your products in my stores?”) or Amazon (“do you want to sell your products on my site?”), you definitely call the shots. Whether they issue an EDI implementation guide or an API specification, such channel masters require suppliers and vendors that wish to do business with them to utilize their approach to B2B, which means supporting whatever B2B protocol (e.g., EDI or API) is used and mapping in-coming purchase orders to whatever format is needed for their own internal applications. In other words, channel masters push responsibility for B2B semantic reconciliation onto their supplier community.

“But, hey – wait!”, you say. Aren’t there standards, e.g., for purchase orders in EDI or APIs? Well, yes – and, no. Yes, there’s EDI standards like the EDI 850 transaction for purchase orders. And, yes, different applications and SaaS providers publish “standard” API WSDLs for processing purchase orders. But, every channel master implements a unique “variation” of EDI or API for a purchase order. And if you’re a supplier / vendor taking orders from a bunch of channel masters you have to deal with the fact that even when purchase orders are similar, they’re almost always a bit different (e.g., unique fields and rules), and sometimes a lot (EDI versus API) – even in the same industry, and definitely across industries.

So back to our supplier / vendor taking orders – what are they to do? Competition fuels differentiation, and that means that every channel master does B2B a bit (or a lot) differently, perpetuating the B2B Tower of Babel. Even if you only sell into a dozen different buyers someone must deal with all the different forms of EDI and APIs and – you guessed it – the channel masters usually don’t. And if you sell into 100’s or 1000’s of buyers? It’s a mess, which is why most operators of B2B networks have been implementing canonicals – which are B2B standards on steroids which they use to mask many of the variations buyers implement into normalized transactions (typically XML, although for a fee most providers will map to your protocol or format of choice). Even then you may still need to process a few unique fields or business rules for certain channel masters which aren’t easily mapped to the canonical (these more deviant variations are typically segregated in the canonical, e.g., via special XML fields), but otherwise the B2B providers render purchase orders in a highly normalized, consistent fashion.

So, facing this complexity your choice is to build your own “semantic reconciliation” practice (via a B2B infrastructure and integration specialists) – or you can outsource this task to a service provider, i.e., integration brokerage (aka, integration managed services). Many companies, in fact, do this task themselves – but it’s a non-trivial effort and in the age of “move fast”, “cloud-first” and “core versus context” it’s no wonder that at least some companies don’t want to bother, and therefore choose to outsource.

Comments are closed