Let’s start with the simple premise that, despite being a second-tier set of capabilities, business-to-business (B2B) functionality remains an essential component of integration. However, what vendors mean when they claim they offer B2B capabilities can vary greatly.
Looking Past Analyst Reports and Squares
Organizations continue to base the technologies they buy for integration on criteria centered on multi-enterprise collaboration with interoperability standards and protocols, such as electronic data interchange (EDI), AS2 and XML, strategically gearing up for ecosystem enablement—pulling in data from the edge and handling the Internet of Things (IoT)-ness of futuristic integration architectures.
It’s not uncommon for integration technology vendors to segment out the types of B2B patterns that align with specific B2B use cases, including:
- B2B gateways.
- Managed file transfer (MFT).
- Application program interface (API)-based B2B.
- Data synchronization.
- Application-specific transport adapters.
The vendor will then label the standalone pattern where its software best fits as the one and only fit to handle B2B in its entirety. Not only is the claim hyperbolic and inaccurate, the actual delivery framework for B2B capabilities is not especially useful to companies that depend on EDI-based B2B patterns for more than a single B2B use case.
One of the reasons we end up with this artificial approach is, in the push for modern innovation or digital transformation, the truly heavy lifting of B2B integration got lost in vendors’ rush to deliver snap-together as-a-service offerings without really considering what customers’ foundational B2B needs really require.
To keep the billions of dollars of daily transactions moving, this artificial segmentation falls well short and continues to necessitate real B2B integration specialists providing robust, comprehensive solutions that address multi-patterned B2B challenges.
Let’s call the as-a-service flavor of B2B what it is—diet B2B. But it’s a diet offering in an integration world that still requires the full-bodied functionality and capability framework that only real B2B can deliver.
What It Means to Do Robust, Full-Featured B2B Integration
The continuing allure of the cloud is simplicity and interoperability. By leveraging the cloud for infrastructure technologies, integration-platform-as-a-service (iPaaS) companies believe they can be absolved from complete B2B functionality with the runtime aspects of middleware technologies, and shift their focus to better defining and refining their business processes.
But what these vendors are talking about are the one-off B2B connections with partners and systems that color and give context to their B2B messages and transactions. An example would be using an API to look up parts, but EDI to order them. While helpful, this type of B2B is not complete.
In many cases, however, these business processes span numerous disparate enterprises and systems, and must invoke B2B-centric processes and data transformations, such as EDI.
A leading global pharmaceutical manufacturer and industry leader sought similar differentiation to deliver at scale and objectively speed the time to market for new product introductions. An innovator in the concept of open science as applied to research and development (R&D), the company, with a dispersed international workforce and distributed R&D facilities, leveraged secure and scalable B2B integration to enable rapid project launches and facilitate massive pipeline growth. The new systemic capacity to ramp up the number of concurrent development programs resulted in an astounding six blockbuster releases on the horizon.
Another example would be ground-based logistics services within the dedicated trucking industry. Here is a powerful need for a fully integrated multi-enterprise EDI ecosystem to facilitate operational distribution, maintenance and transportation solutions. Where demand, fuel rates and increasing regulatory burden continually affect the bottom line, real B2B integration can be the difference-maker to process efficiencies that translate into company profitability.
And sure, cloud-hosted managed services do offer this complexity, customization and scalability on par with on-premise solutions (and also cloud-hosted B2B managed services). But there’s often a significant disconnect between what companies need for B2B functionality and what iPaaS vendors offer.
The Need for APIs
That’s not to say there isn’t a need for iPaaS. An iPaaS solution works great for one or two connections, and to generalize this type of technology, leverages APIs to connect the software-as-a-service (SaaS) ecosystem extremely well. APIs also are very complementary of the B2B topography.
Exchanging documents that represent business transactions, such as purchase orders, transformed the e-commerce landscape, and gave multiple industries speed and agility, as well as consistency and accuracy when doing business. At the same time, companies understood the value of extending their internal applications to their partners via APIs.
Doing so helped their partners, for instance, browse a catalog before ordering or perform detailed inventory lookups—more specialized actions than what would be represented by an EDI document—using the applications that housed product information. The proliferation of API web services and service-oriented architectures (SOAs), then, meant partners could integrate with applications in a programmatic way, and present that information in a customized portal or as part of a larger internal supply chain application.
This approach eventually created new questions and challenges for IT teams: How do you best secure these interfaces, and how do you best manage availability and partner usage of the applications? Service monitoring, service virtualization and metering technologies specifically focused on interfaces, and services became critical components of any successful SOA deployment.
It was only a matter of time, however, before the API management vendors that provided this integration capability focused on B2B use cases as selling points for these technologies. Unfortunately, in doing so, core B2B functionalities, such as onboarding, protocol and security negotiation, and data transformation became secondary to virtualization and metering.
Thus, API-led integration remains insufficient for large trading partner networks that require lots of scale, lots of onboarding and even more community management, especially when it comes to EDI-based industries.
EDI Is Complex and Heavy
Simply offering an EDI adapter that contains pre-mapped configurations is not enough to power most businesses, especially those in such EDI-centric industries as automotive, logistics and wholesaler supply chain, retail and financial services. For most companies whose revenues top $1 billion, the matrix features thousands of partners with hundreds of EDI maps, tens of thousands of service-level agreements (SLAs), and hundreds of thousands of internal and external business processes. Understandably, it is initially attractive to snap interfaces and APIs together to achieve B2B context.
In reality, though, the underlying B2B transactions that power digital economies and ecosystems include many types of communication mechanisms that may involve protocol negotiation, data transformation and governance spun around a need for compliance. It’s this depth that is often overlooked by companies doing “quick and dirty” one-off integrations.
Companies are realizing that true B2B integration technology will take them further than the flashy ad-hoc snap interfaces, especially when you look at what it means to be a trading partner in today’s digital context and the work it takes to manage those communities.
Trading Partner Does Not Equal Endpoint
Too often, vendors without the historical context of B2B integration look at trading partners and API interfaces as being the same thing. They are not.
APIs tend to be more static, and thus, change management issues rarely arise from a partner provisioning point of view. The case is much different for trading partners: Security certificates expire, published IP addresses change, and all types of SLAs are modified to promote business needs and market expectations.
A big-box retailer, for example, decided to regain its strategic dominance of the grocery store industry by shipping their expectations regarding purchasing, fulfillment and payment, all massive trading partner ecosystems. This is a $6 billion initiative in 2017.
The ability for a company to understand all of the nuances related to doing business with its partners is a true competitive edge. Most financial institutions, for instance, use the same applications and systems, and are subject to the same national and industry regulations. What makes each different is how they go about meeting their customer and partner expectations, the foundational truth of successful trading partner management.
Summary
Deciding on the best integration approach starts with a single yet critical question: How many trading partners do I have?
The diet B2B one-off, transactional EDI approach of iPaaS can’t facilitate the multi-enterprise enablement modern businesses crave and organizations may be left pumping out an endless loop of custom code to attempt full B2B functionality.
On the other hand, pure-play B2B integration technology closes the gap for achieving real B2B. Robust file transfer functionality requires flexible connectivity, and scalable trading partner onboarding and management, and handsomely complements iPaaS scenarios.
As long as enterprises need to focus on the complexity of EDI and B2B, the snap-together-as-a-service vendors will continue struggling to solve the rich functionality requirements of full-featured B2B. Look for a vendor partner that brings together the strength of both capability sets to handle the heaviness and complexity of real B2B, but with the ease of use and extensibility of an iPaaS solution.
