API-Led connectivity is the founding principal of MuleSoft. MuleSoft defines API-Led connectivity as “a methodical way to connect data to applications through reusable and purposeful APIs [ref].” Translated, this means rethinking your development strategy around how your organization connects various systems and applications that drive and support your business. Traditional thought is around direct, or point-to-point integrations, where System A talks directly to System B through a dedicated API or solution. In today’s IT environment, this strategy leads to the generation of a messy web of one-off connections that becomes increasingly difficult to maintain as new systems are added and old ones are removed or changed.
In this example, none of these implementations are reusable. It is not the fault of any one person, but is the result of implementing quickly without a clear strategy. With the convergence of IoT, Saas, Big data, more IT teams today are met with increasing tools allowing businesses to do more. Even with new tools, IT teams are facing a continuous increase in demand without comparable increases in resources. Therefore, it is to the benefit of the business as a whole for IT strategies to adopt a new approach. This approach, the API-Led Connectivity approach, shifts the idea from one-off, non-reusable, point-to-point integrations to reusable, layered APIs.
Figure 1: Point-to-point leads to a web of connections
By layering APIs, you create a form of a hierarchy that defines what goal each API should be achieving. As you move higher in the hierarchy the consumers of the API are abstracted away from underlying processes and application specific nuances, allowing integrations to occur easily and quickly. The layers that manifest themselves when taking an API-led connectivity approach are:
System APIs are the bedrock that all subsequent APIs will utilize. These APIs grant access to core systems and unlock data by implementing a simple, reusable API. The purpose of this API is to abstract away the complexities of the underlying system interface (if there is one) and provide a managed and secure way to access key data. These APIs should be built in front of systems with APIs of their own (SAP, Salesforce, etc.), databases (data-warehouses or any system with direct database access lacking an API) or any miscellaneous systems requiring interaction and lacking an API (file servers, FTP Servers, etc.).
Process APIs are the second layer. These APIs build upon the system layer by merging together one or many core assets (system APIs) with business logic to create a higher level of value. These higher level objects then become assets to be further reused by other Process APIs or by Experience APIs.
Experience APIs are the top layer. These APIs are specific to the experience required by the applications that will use them (web interface, mobile applications, etc.). This level of API is abstracted away from business logic and core system integrations, allowing developers to consume underlying data without needing to understand how the data arrived at this point
Figure 2: Sample Anypoint Network utilizing API-led Connectivity
API-led connectivity not only depends on three categories of reusable APIs to compose new services and capabilities, but also decentralizes and democratizes access to enterprise data.