API-led Connectivity is a method of connecting data and applications through reusable and purposeful APIs. Organizations that adopt this method will be able to access their best capabilities in delivering applications and projects through discovery, self-service, and reuse.
Let’s first dive deep into the evolution of B2B Integration Technology, along with the “API-Led Connectivity” method and its advantages over traditional methods.
Evolution of B2B Integration Technology
Enterprises and Trading Partners use different back-end application systems that need to exchange data in different formats (EDI/Flat File/XML, etc.) The number of back-end application systems in any enterprise can vary from a few to hundreds. All the back-end applications systems are designed and built to operate in isolation which coined the need for B2B integration technologies.
B2B integration technology has evolved over time in several stages and the most important of them are:
- Point-To-Point Integration
- Hub-And-Spoke Integration
- Process Based Integration
- Service-Oriented Architecture
- API-Led Connectivity : The Next Step In The Evolution Of SOA!
Note: People who have knowledge on EAI/B2B can skip and move to the section API-led Connectivity: The Next Step In The Evolution Of SOA!
Point-To-Point Integration
It can be referred to as the pairwise integration of back-end application systems. For every pair of back-end application systems to be integrated, a direct data transfer is established that transports messages. Sometimes referred to as ETL, it has different approaches such as Synchronous and Asynchronous. It has its own limitations such as each back-end system has to be integrated with every other back-end application. For every integration, there will be two connections.
Hub-And-Spoke Integration
The data transfer is no longer between each pair of back-end application systems but it is between each back-end application system and the central hub. The central hub transfers the data to the target spoke. Data transformation needs to be done in the hub-and-spoke architecture. The central hub reads the message header and forwards the message to the target speaker after the transformation. When a spoke sends the data to the central hub, it does not define any target spoke at all. Instead, the central hub manages rules that determine based on the business data content to which of the spokes the message must be directed- pub/sub-models. 
Process Based Integration
The Point-to-Point, as well as the hub-and-spoke solutions, have few major drawbacks. Each message is sent from one back-end application to two or more(pub/sub). However, if a message is sent to one back-end application and it returns a result that has to be forwarded to a third back-end application system based on a value in the first message, this cannot be achieved using Point-to-Point or Hub-And-Spoke. No additional logic such as notifications or authorization can be added. If a message is received and has to be sent back, the result message is treated as an independent message. Neither the Point-to-Point nor Hub-And-Spoke solution will be aware of the fact that the two messages are related.
In order to address the limitations, the Hub-And-Spoke architecture is extended with process management functionality in the form of a workflow management system.
Service Oriented Architecture(SOA)
The main concept of SOA is to make a software component reusable, loosely coupling, autonomy, and discoverability, where the advantages are service, can be reused to make many applications, easy maintenance, platform-independent, availability, reliability, scalability, etc. Of course, it has its own disadvantages where it requires high investment i.e a huge initial investment is required for SOA When services interact they exchange messages to tasks the number of messages may go in millions and can be challenged in handling a large number of messages.
API-led Connectivity – The Next Step In The Evolution Of SOA!
Source – www.mulesoft.com
The main goal is to provide reusable assets that are made available for the rest of the organization. The key to this strategy is to make every asset become a managed API rather than connecting things point-to-point. The whole point of the re-usable asset is not just for easier maintenance and reuse by IT but for ease of consumption by other parties so that they can self-serve and build their own applications. This is totally different from traditional IT projects, where their focus is exclusively on production for the delivery of the projects.
A Common Project-based Approach
IT gets a request from the sales team for a web application to provide real-time order status and order history. Order data resides in the E-Commerce system, inventory in SAP, and customer data in Salesforce. 
Project Outcome: Order Status, Order History, and Aggregated Customer Data are hooked up with an API that can be used by the Web app. The result is a single application delivered on time and within the budget, which can be considered as successful. But it has limited or no opportunity for reuse. Point-to-Point connections are directly made to the data source systems making them tightly coupled. If anything changes, the application may break, and since the connections to the data sources are coded directly inside the application, they are difficult to secure and monitor.
The application may appear to have met the business requirement, but let’s take a look at when we get another request to build another application where they have to use some amount of the same data.
After the sales team used this for a while, they may decide to build a MOBILE version of it. For this to develop, they will have to repeat the whole process and re-write the whole code even though the functionality is the same as below,
This is a very inefficient way of doing it. MuleSoft has come up with a new model that leverages re-usability to avoid building the same functionality.
The API-led Connectivity Approach
In this new model, instead of building one application that encapsulates all functionalities and connections, this approach uses groups of services, to each of its own APIs which can be governed and monitored. Below is the diagram showing the way it can be developed, 
What are the Business Benefits of API-led Connectivity?
An API-led connectivity approach not only ensures you deliver on time and within the budget for your first project, but also built an infrastructure that offers visibility, compliance, and governance, and most importantly, meets your business needs.
It enables you to move faster on your first project and accelerate further from your second project, due to reusable assets and a built-in organizational capability. API-led connectivity liberates resources, allowing you to innovate and move quickly.
On average, MuleSoft customers found that the increase in agility and speed provided by API-led connectivity led to delivering projects 3-5x faster and increased team productivity by 300%, compared to legacy or homegrown integration solutions.
In a nutshell, almost every system is capable of exposing its applications as an API and can consume external APIs as well. Considering the benefits of API-led connectivity and its tremendous adoption by customers across the globe, is this a sign that soon the usage of EDI/Flat Files translations will come to an END!
