The Pros and Cons of API-Led Connectivity

API-led connectivity is the most important design pattern facing IT today. It is the key to digital transformation and an IT strategy that unlocks an organization's products and services to its consumers. There are many aspects to this pattern, so in this article, I will put down some key tenants and a few ideas from this. Then, I hope, through comments and conversations, I can begin a discussion and follow up with more articles in the future.  

As a Senior Solution Architect in EPAM's API Practice, the most impactful change that we can bring about is the adoption of API-led connectivity. Most organizations have APIs to some degree, often evolving out of an SOA or microservices approach. APIs are brought into an organization, one at a time, so that, from natural evolution, there will be many APIs, but they won't follow an API-led connectivity approach. The next step is to follow this standard, but there is often resistance, as in all changes. This leads organizations down a point-to-point path of connecting their systems, which is an anti-pattern in the API world. This was like the days of client-server applications, which were ultimately replaced by a model-view-controller design pattern. API-led connectivity has a similar concept. In the model-view-controller, the users of the system connect at the view layer, the controller manages the orchestration, and the model connects to the data.

Similarly, in API-led connectivity, there are also three layers; experience (view), process (controller), and system (model). These three layers allow you to de-couple the consumers of your application through the experience layer and your systems of record in your system layer. Your business logic and orchestration sit in the process layer. There are many benefits from this, as I'll outline below. The following diagram shows an example of API-led connectivity.

1. Experience Layer

You can apply security to different application consumers depending on who they are at the experience layer. These consumers could be web, mobile, and third parties who could be either internal or external to your organization. You can provide multiple security policies such as client id, certificates, OAuth, and multiple SLA tiers based on subscriptions. You can manage these consumers by providing or withdrawing access to your applications, authorizing access, and monitoring these APIs to measure the volumes and throughput. This also makes it easy to monetize your products or services at this layer.

2. Process Layer

The process layer will contain your business capabilities and can be divided into various domains. Each line of business can have its own APIs defining the product or services they provide. For example, you would have a set of APIs defining the customer, products, or billing. These APIs at the process level are accessed by consumers from the experience layer. In addition, the process APIs can call other APIs at the process layer or can call on APIs at the system layer, which provides or update information from your systems of record.

3. System Layer

The System layer exposes information from your various systems of record. These will be your legacy systems, your databases, CRMs (Customer Relationship Management) like Salesforce, and ERPs (Enterprise Resource Planning) like SAP. For example, you could add queues, caches, timeouts, and circuit breakers at this layer if you are experiencing performance issues. In addition, some API framework vendors automatically create this layer and use AI to improve performance, eliminate redundancies, and remove unused functionality.

Large Organizations

The API-led connectivity approach is beneficial in a large organization where you'll have multiple development teams. Your different lines of business can each work on APIs within their own domain in the process layer. For example, your web, mobile, or third-party partners can connect to APIs at the experience layer. Likewise, the system layer can be managed by Central IT groups associated with your various systems of record.

Pros and Cons

Some common complaints I hear related to this three-layered approach are that there are multiple networks hops from layer to layer, and there is an added complexity to this approach. These are the same questions I heard when we moved to model-view-controller or when we used to have different servers for the database and the application. However, a well-designed application will always trump a few milliseconds of performance. An API-led connectivity approach can lead to improved performance by adding caching, spike control, and monitoring of multiple consumers and right-sizing the security on the system layer. Also, note that the security is usually kept at the experience and system layers, whereas the process layer is usually secured with a faster client id and password level security. This can lead to the overall faster performance of your systems.

Two other important benefits of an API Led approach are reusability and the ability to quickly plug in new consumers and systems of record.

Summary

This is a high-level view of what API Led Connectivity is and why you should use it. Do we need an experience layer? Should the experience layer be divided by domain, channel, or partner? How should you model the data in your system APIs? In the future, I'll go into more detail with use cases, examples of each layer, and how this can help your organization. Please share your experience with API-led connectivity, including both benefits and consequences.