For companies exploring MuleSoft as an enterprise integration platform, you may have encountered the term API-led Connectivity. Within the MuleSoft ecosystem, an API-led approach is recognized as a robust, scalable best practice for building large-scale enterprise integrations. This approach serves as an alternative to the fragile point-to-point connections between systems that are prone to breaking and difficult to scale. But what does this mean for your business and your integration needs? Let’s examine these concepts and understand why they are considered best practices when building MuleSoft applications.
The Problem with Point-to-Point Solutions
Point-to-point integrations offer a simple way to connect systems, but they come with many issues as you grow. Let’s review what a point-to-point integration landscape looks like for a bank with multiple core systems.
Similarly, the following diagram shows an example of point-to-point architecture in the real estate industry. In the real estate example, we see systems like Salesforce, external property websites and a mobile app for tenants to report sales and submit work orders, which are connected point-to-point to a variety of backend accounting, ERP, and budgeting platforms like Yardi, MRI, Realpage and Argus.
As shown in the images above, each system connects individually to your backend platforms. This setup quickly becomes hard to scale and maintain for several reasons:
- Diverse Technologies: You might need different technologies for each integration. In both diagrams, you see a mix of Salesforce Apex, Java, and .NET code used for different frontend experiences. This requires developers with various skill sets to maintain the system. The disjointed nature of these tools makes scaling resources to support higher volumes difficult, needing different approaches for each integration path.
- Unmanageable Connections: As the number of systems grows, your point-to-point connections will multiply, becoming unmanageable. Duplicate business logic will appear in multiple systems, with no central platform to orchestrate data between backend systems.
- Fragility and Downtime: This approach becomes very fragile as the number of systems increases. If a backend platform changes, all downstream systems are affected, requiring each integration to be evaluated and adjusted separately. This process is time-consuming and can lead to prolonged downtime.
API-led Connectivity: The Three Layers that Make it a Scalable Solution
MuleSoft recommends a three-layered API architecture to avoid the pitfalls of point-to-point integrations. Here’s an example of core banking integrations: the architecture diagram below shows an integration to Salesforce, showcasing Experience, Process, and System APIs arranged from top to bottom.
Another example illustrates how these architectural patterns can be applied to solutions in the real estate industry. MuleSoft powers integrations between popular real estate accounting platforms such as Yardi, MRI and Realpage, as well as tying into budgeting systems such as Argus.
With API-led Connectivity, you can connect backend system data to your frontend applications via APIs. Emphasizing reusability, these APIs have specific roles such as data surfacing, orchestration, aggregation, and presentation. They are grouped into System APIs, Process APIs, and Experience APIs, each acting as a reusable building block in your system landscape.
Let’s dive deeper into each part of this three-tiered architecture:
- Experience APIs power robust user experiences like mobile banking, online applications, and your Salesforce CRM platform, where users interact with transactional data. These APIs use the business processes provided by Process APIs to retrieve and orchestrate data from backend systems. Since each application has its own Experience API, adding new frontend experiences is easy without impacting existing systems. Each can be scaled individually based on business needs. Experience APIs are typically lightweight and quick to create, built on top of your reusable MuleSoft building blocks.
- Process APIs surface data related to various business processes. For example, opening a new deposit account for a customer might involve a Process API calling the necessary System APIs from your banking cores to update data and onboard the new customer. Process APIs interact and orchestrate data held in disparate backend systems or databases to provide specific business functions.
- System APIs access the core systems of record, abstracting their complexity. For instance, a System API might provide a lightweight layer over a backend database or SFTP server, making it easily accessible by your Process API layer. System APIs can also wrap around third-party APIs to normalize their request and response formats. Once built, a System API can be reused across multiple projects. When underlying systems change, only the relevant System APIs need updating, without impacting the entire integration landscape.
API-led Connectivity is the Future of Integration Strategy
APIs represent the future of integration, and MuleSoft’s API-led approach puts this at the forefront. API-led Connectivity is a proven pattern for building integrations that can scale from one or two systems to hundreds, capable of growing with your business needs while avoiding the pitfalls of point-to-point integrations.
In a well-designed application network, each API can scale and grow individually as demand increases. APIs can be reused as you introduce new frontend experiences for your customers. This approach also protects your integrations from change by providing a layer of abstraction from backend systems, unlike tightly coupled point-to-point connections that require significant maintenance as changes occur over time.
