Blog: B2B Integration vs A2A: A Chicken and Egg Story

Welcome to the Think Tank
with Frank Kenney

With decades of analyst and integration industry experience, Frank Kenney is a fountain of knowledge on all things tech. Now, he aims to share that awareness with you. Visit this blog every other Thursday for your biweekly dose of thought leadership from one of technology’s most insightful thinkers. Gain perspective on a variety of integration topics ranging from what’s happening in today’s climate to what’s poised to disrupt the space going forward.

***

To get started, allow me to frame this post with a common causality dilemma (aka a tricky question): “Which came first: the chicken or the egg?”

In all my years as an analyst/technology evangelist, one debate that I continue to have with my colleagues, industry analysts, and experts of virtually every business domain reflects the chicken or egg scenario.

While presenting the debate in overly reductive terms, here is that persistent question in the simplest of terms:

“Which came first: business-to-business (B2B) or application-to-application (A2A)?”

The chicken or the egg.

The question central to this debate fundamentally centers on the topic of integration. A more apt reframing follows:

“Are B2B integration platforms a part of the larger A2A integration domain or is A2A integration representative of a portion of the overall B2B equation?”

Integration Market Dynamics

Before digging further into trying to answer the central question, I want to touch briefly on the size and trajectory of the integration market, specifically the platform as a service market segment.

According to Forrester vice president and principal analyst, Andrew Bartels, the global business technology, software, and services market is slated to grow by around 4 percent in 2018. That’s stronger growth than 2016 and 2017, but not exactly jaw dropping.

By comparison, the integration platform as a service (iPaaS) market is set blow that figure away. This segment of the application integration technology market is set to expand at a greater-than-34 percent year-over-year pace – displaying the most dynamic growth in the integration space.

I would be remiss if I didn’t also note that the B2B integration market – with origins going back more than 40 years – remains extremely vibrant. The B2B integration market is projected to continue expanding at a respectable clip of approximately 8 percent year-over-year, doubling the total global business technology rate.

And with that, let’s get back to it.

Whenever I get into the integration chicken or egg debate, I set out to accomplish the following three points around B2B vs A2A:

1. I logically detail why B2B is more closely aligned with the business.
2. I address how most, if not, all application integration deployments support higher-level revenue-generating business processes.
3. I explain how we’ve come to a place where it is still necessary to pose the question in the first place.

Why integration is most closely aligned to the business

Consider the following hierarchical list of entities your business can “integrate” with. This list is recursive implying that the technologies and methodologies required to integrate with an entity that’s lower on the list is also necessary for the ones that are higher. Here’s the list:

• Partners
• Applications
• Data
• Servers (OS folders etc.)

Integrating Servers

Starting from the bottom, integrating servers means server integration.

We can think about the work that’s required to integrate servers at the operating system level. SMB, for instance, is an excellent example of the functionality needed to achieve this. This internal protocol requires that we have an IP address as well as permissions.

Integrating Data

Integrating data means to integrate data and the underlying infrastructure (i.e. servers).

Moving up the list, we land on data integration. Make no mistake data integration can be a complicated thing. But at the most rudimentary level, it’s about being able to climb into some type of data store like a database and extract information, transport that information, and then load that information into another database. We start to inherit complexities when we have to perform transformations on the data that’s being moved. Still, I need to know how to interface with the database.

Integrating Applications

Integrating applications is a fairly substantial jump from integrating data.

Now I have to have an understanding of data models, data formats, application programming interfaces (APIs) to be able to get to the data, and all of the data movement and communication capabilities that I’ve inherited with other forms of integration.

Integrating Partners

Finally, we get to partner integration.

Partner integration by itself would represent B2B integration in its purest form. However, with the partners I must do everything I was doing before, and now I must take into consideration external environments. In other words, the efficacy of B2B integration must include system, data, and application integration capabilities. Due to the need to reliably and securely cross digital business borders, partners add specific complexity to the B2B integration scenario.

In dealing with partners (unless I’m the hub) I won’t dictate governance rules. Further, there are variable expectations that commonly differ from partner to partner. Some examples include service levels agreements (SLAs), non-repudiation requirements, and preferred communications protocols and proxies. With these factors in mind, I must consider how to create and manage the lifecycle of the artifact that represents these rules and expectations. That’s referred to as trading partner or community management.

B2B/A2A vs A2A/B2B – The Order Matters

My point is that if you rearrange the integration hierarchy – shuffle this list into any other order – it doesn’t hold up.

For example, if partner integration is, in fact, a subset of application-to-application integration, then the importance of trading partner management (TPM) and governance is diminished. We know that isn’t the issue. TPM should therefore not be reduced to endpoint management. Additionally, while many of us look at technologies that will only manage controllable endpoints and static APIs, managing partners is more complicated than managing static APIs. Case in point, communities made of partners and customers are vibrant and dynamic with all parties changing expectations constantly.

So why do we even have this conversation at all? The answer is deceptively simple.

B2B vs A2A: The Chicken vs the Egg

While the price tag for application integration can be enormous, the audience for discussions about A2A integration is relatively small within an organization. In most cases, we’re talking to architects, analysts, developers, and administrators. Executive management is required to approve any purchases mainly because of the high cost associated with these technologies. On the other hand, the audience for conversations about B2B tends to be a lot bigger and oftentimes more invested. That’s because B2B integration reflects underlying revenue-driven activities within the business – a topic set that’s broader in scope and impact.

For example, like a ton of enterprises, we use a CRM to manage the sales automation experience that ultimately results in a business-to-business transaction, which is hopefully fulfilled by B2B technology. And, like most companies, we use an ERP to manage invoices and finances associated with business-to-business transactions, and so on. Because the dynamic nature of trading communities and customers, it’s a lot more efficient to agree on sets of standards to represent these B2B transactions flowing through our core business applications. Naturally, EDI is the choice. EDI and the established B2B standards inherent in this technology are exceptionally adept at representing the transactions central to our own revenue-driven activities.

While the growth exhibited by the iPaaS sector tells us of the increasing adoption of API-centric A2A integration, companies will hit many of the same integration brick walls that EDI hit before standardization some 40 years ago. The mature nature of B2B standards, protocols and methodologies mean innovation can become stifled. However, there are providers that recognize the opportunity provided by breaking the mold and bringing fresh innovation with a modern view to strategic B2B.

While I may not have convinced you, what I’ve hopefully done is given you something to at least think about.

***