Introduction
Today, in the age of APIs an API is not just a technical interface on top of a database. On the contrary your API is your new Business Model. In the past APIs were seen as some tools for Developers. But now a days their scope is not only limited to internal use, the API makers (companies) are exposing their APIs for external users around the globe. For example Google maps APIs use the Uber APIs to calculate fare and travel time to destination.
In this API-Led business model it’s a new way of thinking how to engage with partners and customers through APIs. In other words your product is the API. So one must take proper care while designing based on business crietria, deploying and managing the APIs.
In this article, I am going going to discuss about the paradigm API-Led connectivity which has gained a lot of popularity in this decade.
The Digital Transformation
Now a days everywhere is happening the digital transformation with the involvement of Mobile and Cloud technologies. APIs once seen as developers’ tools are now being exposed to market. For example, through the Product Advertising API , Amazon sells its product through third parties.
However digital transformation is not an easy task. It involves the ability of the organisations to bring in multiple technolgies to create distinctive and disruptive services to the market. To happen this they must be able to retrieve data/information from disparate sources and provide them to multiple consumers (customers, suppliers and employees) in various formats.
Problems With Traditional Connectivity Approaches
The traditional approaches used for integration applications do not work for digital transformation. These approaches were designed where fewer endpoints were necessary to meet the business needs as well as the speed of delivery was not considered too much. Here are the problems faced with the traditional integration approaches,
P2P Approach
In P2P approach one business operation is connected to another operation by direct connection. In an organization where a lot of applications need to be integrated it becomes a mess with P2P approach. Here are the three main drawbacks of this approach,
- Hard to change
- Maintanability
- High operation risk
- Time to market
E2E
This approach focusses on centralizing information as much as possible. In this approach an integration platform is used (ESB) which serves as the base for collecting all the information and serving them to the final receiver. It centralizes and reuses components e.g logging, error handling, transaction etc. This approach is much more efficient than P2P approach. However to meet the digital transformation of today’s age it is till not efficient enough because “Time to market” is till bigger with this approach.
So, to overcome these problems the new approach API-Led Connectivity is born.
API-Led Connectivity
This approach is based on Pace layers.The main purpose of API-led connectivity is to enable the integration flows to be reused by many parties and to be reused inside the integration platform. With the reusability of the already available logic (implemented in flows) the developers can evolve their logic in a faster and safer ways and thus leading to high uptime to the market. APIs are created in layers and the best plus point as comapred to E2E approach is that more components (flows) can be reused which makes easier to implement new systems and services.
As per research it shows that API-led connectivity approach makes the development process 3 tmes faster as one does not need to reinvent the wheel and thus decreasing the uptime to market. As the reusable APIs are already tested use of them makes the new implementations bug free. The reduced development time reduces the integration costs by around 70% (as per the statistics).
In this approach the APIs are based in three distinct layers: System, Process and Experience. With API-Led architecture the IT infrastructure of an organization should look more or less as shown in the diagram below.
System Layer
This is the foundational layer of the three layer architecture. These APIs can be defined for various domains of an organisation for example ERP, key customer and billing systems, proprietary databases etc. System APIs provide a means of accessing these underlying systems of records and exposing the data in canonical formats. A System API defines the contract RAML/WSDL to describe how to interact with the the domain. For example, a System API for Customer domain can contain resources with methods GET,POST,PUT,DELETE etc and the related schemas (XSD,JSON) and responses (200,400,500 etc).
So basically one can see that System APIs generally expose the sensitive informations of an organization. They should not be exposed for public use.
Process Layer
Process layer APIs are responsible for shaping the data by orchestrating and choreographing various data by calling multiple System APIs. The orchestration involves aggregating, splitting , routing etc of data. The main purpose of Process APIs is to strictly encapsulate the Business Process independent of the source systems (System APIs) from which data originates.
For example, in a Purchase Order process it needs to interact with various domains of the organization. So the Process API (Purchase Order/Order Fulfillment) interacts with the already available System APIs to implement the logic.
The Process APIs shoud be held privately inside the organization as per recommendation and should not be exposed for public use.
Experience Layer
Now at this point we have all the sensitive information of an organization are exposed privately by System APIs and the Process APIs have already exposed the Business Process logic. The business process data is consumed across a broad range of clients/channels with different formats. For example our Order Purchase API (Process Layer) has exposed data in JSON format but we have a client appliction that accepts only in XML format or vice versa. So this simple transformation logic are implemented in Experience Layer and the implementations are exposed as Experience APIs.
In another words Experience APIs are the means by which data can be reconfigured easily to meet the needs of multiple audiences. Also we can remove the unnecessary methods and expose only the necessary methods in Experience APIs in a simple way.
The Experience APIs are the ones which should be exposed publicly for consumption. In short they are the final products of an organization in the API-Led connectivity approach. Various Policies can be applied to the APIs as well as they can be monetized to earn revenue for the organization.
Main Advantages of Three Layer APIs
The main benifits of the three layer can be summerised as below.
System APIs
One can modify the System API logic without affecting the other APIs (Process and Experience). For example if a System API is using SAP and in future SAP needs to be replaced with Salesforce. So this replacement can be done easily modifying only the System API without touching anything in Process and Experience layer.
Process APIs
Common business logic can be shared across the organization. For example if an organization already has the Purchase Order process API implemented it can be reused whenever necesary.
Experience APIs
Experience APIs are simple. Basically they involve only transformation of data. So to meet a wide range of clients that accept data in diverse formats the Experience APIs do this rapidly thus decreasing the uptime to market.
Role of Mulesoft in API-Led Connectivity
The Anypoint Platform provides a very nice Integration Framework as well as an API Management platfrom. Using the Anypoint Platform as a whole one can achieve the API-Led connectivity in a smoother way.
Conclusion
In this article I have given a brief overview of the API-Led connectivity. In the next article I will try to show how to achieve this with some examples using Anypoint Platform.
Thanks.
Reference links:
https://www.mulesoft.com/lp/whitepaper/api/api-led-connectivity
Learning Trail 