B2B Integration: Survival of the Fittest

In 2016, what really separates B2B integration from legacy internal integration architectures such as enterprise service bus (ESB) or extract, transform, load (ETL)? Have the natural forces of technology and the resulting evolution of business applications simply rendered the distinctions meaningless? If so, which architecture has adapted to become the winner? Which is on the endangered species list? And have any evolved into the ungainly evolutionary equivalent of the giant three-horned chameleon?

Although these are fun questions to ponder, determining an integration architecture's survivability is more than just an interesting thought exercise. It's an important matter to consider when choosing technologies, vendor partners and deployment options.

ESB and ETL integration vendors sell software— predominately on-premises software although some offer cloud-based versions called Integration Platform as a Service (iPaaS). B2B integration vendors, on the other hand, more commonly deploy and support B2B networks as managed services that are governed end-to-end by comprehensive service level agreements (SLAs). While ESB, ETL, iPaaS and B2B architectures may display more and more of the same traits as they all try to adapt to a changing technology climate, software development is a fundamentally different species than that of operating B2B networks. There can be no successful interbreeding and, for this reason, you need to know which one is best poised for long-term survival.

Admittedly biased, I'd like to put forth for your consideration a perspective of the forces that have shaped the application integration landscape over the last 15 years and why, today, these forces have led to the natural selection of B2B integration.

The term B2B integration is used to describe the integration, automation and optimization of key business processes that extend outside an organization's four walls. The term A2A integration (the use case for ESB, ETL, and other types of internal integration architectures) has historically been used to describe the integration, automation and optimization of key business processes that take place within an organization's four walls. I say "historically" because the definition for A2A integration is now often extended to include integration between applications within the same “application landscape of a company.” This add-on is sufficiently vague enough to incorporate some B2B style integrations and muddy the waters for low information consumers and aggressive ESB salespeople.

So why is A2A integration sounding more like B2B integration? Because business drivers and technological realities are blurring the distinction.

First, let me address the primary business drivers. As larger (and even smaller) companies began outsourcing more business processes (e.g. HR, R&D, etc.) in order to focus on their unique core competencies, more businesses became virtual or distributed. The traditional vertically integrated company concept has given way to a distributed supply chain, complex ecosystems, partnerships and joint ventures. In other words, the definition used to delineate A2A/ESB from B2B, which hinged on concepts of being “within a company” or “within the four walls of a company," is now not so clear as the concept of what constitutes a company itself has changed.

And now for the technological realities... Remember the good old days of walking through the company’s data center, led by the VP of Tech Ops from corporate IT? He or she would point out the racks of servers, the storage arrays and the miles of Cat 5 cables—and yes, the specific rack that held the DMZ servers, the “firewalls.” Well these days are long gone. The use of distributed data centers from cloud providers like Amazon’s AWS, SaaS (News - Alert), and now cloud applications have become mainstream. And the idea of “behind the corporate firewall” almost seems like an absurd notion like a typewriter or a 35mm camera. However, if you were to look up the term ESB, now 14 years after the term was coined, you will still find this “behind the firewall” distinction.  

In the end, the notion of “the company” as a contained entity with a distinct firewalled off place within which applications and data are integrated is now far from what it once was. Companies have evolved in the direction of diversification, distribution and ever-increasing variety. And the complexities of these traits are much more closely aligned with the strengths of B2B network providers than ESB vendors.

B2B integration providers are naturally positioned to knit all this diversification together. They have long met the challenges of distributed entities by managing varied information flows, handling payload sizes ranging from small transactions and real-time APIs to large managed file transfers, providing 99.999% system (not just software) availability, and having the operational discipline to ensure end-to-end compliance and security for sensitive information in transit and at rest.

If you look closely at current ESB solutions, on the other hand, you might see a resemblance to that ungainly giant three-horned chameleon I mentioned earlier. Like this evolutionary oddity, many ESB/ETL solutions have adopted a strange assortment of disjointed features in an attempt to stay relevant. These features include analytic and reporting bolt-ons (e.g. TIBCO Spotfire), disconnected master data management (MDM) software (e.g. Siperian which was acquired by Informatica or Velosel which was acquired by TIBCO), and even social media applications (e.g. TIBCO tibbr).

The bottom line? It is ALL external integration now and it is all B2B—no matter what TIBCO, Informatica, Software AG, or MuleSoft might tell you.