Back to All Stories

As we enter the third decade of the 2000s, it’s clear: we live in a digital world. The ways we learn, communicate, and work are increasingly digital. What powers this new world isn’t just the digital information — data, images, graphs — itself; the real power of the digital world comes from the connectedness that allows us to interact, integrate, and innovate using this information. This connectedness creates a non-linear relationship between the amount of digital information we produce and its impact on society.

As long as there has been digital information, there has been a desire to share it. In the early days of software applications, that meant extracting, combining, and processing data through scheduled batch jobs. As personal computers became more powerful and connected through local networks, client-server computing provided a new means of sharing information in real time. Not only could you now share data, but you could also share the application functionality used to process it, leading to the concept of “application integration.” The possibilities for application integration exploded with the rise of the world wide web, through both its global ubiquity as well as the protocols and technologies that enabled its interoperability. The web began as a collection of static homepages but has since evolved to become the backbone of our digital society. Today, we can listen to personalized playlists on smart home speakers, plan fitness regimens through health data telemetry, shop and move money from our phones. All of this is possible due to a simple application integration mechanism: the web API.

 

What a tangled web we weave

In technical terms, a web API (or simply “API”) is nothing more than a network interface to software functionality that uses the protocols of the web (e.g. HTTP, JSON, XML). However, in business terms, this integration tool allows organizations to open up their core capabilities for consumption by other organizations, through new distribution channels, and on new digital devices. We — generally regarded as the first company to offer a web API — were able to revolutionize the software industry in part by using our API to facilitate customer data migration, integrate with customers’ core enterprise applications, and connect with stakeholders through their preferred systems of engagement. Amazon and eBay used APIs to sell goods on third-party websites, Facebook and Twitter used APIs for likes and shares, and the mobile app economy was founded on the data and services provided through APIs. Companies like Twilio and Stripe have achieved unicorn status with APIs as their primary commercial products. APIs are so foundational to the current digital economy that one cannot imagine a company like Lyft — who uses APIs from Google Maps, Twilio, Stripe, and AWS — getting past the concept stage without them.

Some of the APIs involved in ordering rideshare from a smart speaker

 

Influenced by this cross-organizational web revolution, application integration was taking off inside enterprises as well. Driven by a need to integrate data and functionality within their own walls, many companies appropriated web API protocols like XML and SOAP as a means for connecting applications. The first wave of post-web enterprise application integration — known as Service-Oriented Architecture (SOA) — aimed to provide shared services for the enterprise. Although SOA’s focus on reusability was a step forward, it delivered limited returns since implementation focused almost exclusively on web technology. We are now in the second wave, where leading organizations are taking a new integration approach — API-led connectivity (ALC) — that still uses the technology of web APIs, but adopts the best practices of leading web API organizations as well.

 

From application integration to API-led connectivity

Companies like eBay and Twilio learned early on that an API is only as valuable as its adoption. To drive usage, they introduced a consumer-first mentality and focused on making their API products as useful, usable, and understandable as possible to ensure consuming developers could work rapidly without requiring hand-holding. Amazon recognized the power of decoupling their internal product teams through APIs, something Jeff Bezos codified in a legendary memo. The ALC approach synthesizes these practices with lessons learned from previous generations of enterprise application integration.

Early application integration focused on connecting application and data endpoints for a particular project or purpose. SOA introduced the notion of application endpoints that could be reused for multiple purposes. ALC builds on this approach by exposing an organization’s core business capabilities as long-living API products with defined business models. ALC puts the consumer first. APIs are designed “outside in,” with a primary focus on the needs of consumers despite constraints and biases of the provider. Furthermore, ALC organizations treat developers of API-consuming applications as first-class customers whose user experience — or in this case “developer experience” — is a major product consideration.

Evolution of application integration approaches in the enterprise

 

Some key practices are necessary to deliver consumer-focused APIs at the heart of ALC. Organizationally, APIs are often owned and managed by cross-functional product teams that align to specific business capabilities or broader business domains. These teams include business and technology roles — such as API product manager and lead API engineer respectively — who own the consumer relationships, the API product roadmap, and the solution architecture. Teams should function as autonomously as possible, mimicking the Amazon structure. This setup has an affinity with the DevOps and microservice architecture movements that are also sweeping enterprise IT. However, most ALC organizations balance the development of net new microservices with the API enablement of existing application assets. Legacy application functionality and data exposed as base level “system APIs” are composed into core API products (sometimes called “process APIs”) made to be consumed in multiple business contexts. Further API abstractions are added as needed to serve the needs of new consumer contexts (for example, “experience APIs” intended for a specific consumer channel like mobile), in order to drive API usage and maximize business value.

 

Takeaway: The application network effect

Enterprises that employ API-led connectivity experience numerous benefits by exposing their business capabilities through APIs. With previous approaches to application integration, these organizations might achieve a high degree of interconnectedness between their systems, but identifying the endpoints in an exchange could be difficult, let alone reusing them. ALC’s emphasis on self-service APIs makes it much easier to discover business capabilities in the IT landscape. The APIs, in aggregate, form an “application network” of services to be consumed, regardless of their underlying implementations. This application network also provides a means for governing highly-distributed enterprise software systems through consistent monitoring, security, and other control mechanisms. Its value increases as more APIs and more consumers are added.

Example application network from a mobile retailer

 

Our experience has shown the value of an API-led connectivity approach, especially as enterprises create an application network that serves as a platform for their digital transformation. Even as success on this path towards an application network is incremental and ongoing, you can still use ALC to help navigate towards your digital destination.

To learn more about how APIs can help your organization’s digital strategy, check out the MuleSoft API Strategy Hub.