What do Expedia, Salesforce, and Stripe have in common?
Half or more of their revenue comes from APIs — a term familiar to software developers but one that often leaves business leaders puzzled.
Because let’s be honest: The call for an API strategy has been going strong around tech-town since the early 2000s. But it was only in the late 2010s that we finally saw where that trend was leading: 35% of today’s technology leaders generated more than a quarter of their organizations’ revenue as a direct result of APIs.
35% of today’s technology leaders generated more than a quarter of their organizations’ revenue as a direct result of APIs.
What is an API strategy and where’s the value?
An API, or application programming interface, is a code-level interface that applications can use to connect with each other.
In 2019, 78% of organizations both developed and consumed APIs. You’ve surely interacted with one if you’ve ever placed an order on Amazon, hailed an Uber, or ordered your coffee from an app.
Let’s understand the mechanics behind API first. For that, we’ll take ordering coffee as an example. When you walk into a coffee shop, the first thing you’re interested in is the Coffee Ordering Interface (aka the menu). It serves two purposes:
- Helps the coffee shop show you the types of caramel blond spicy cappuccinos they can brew
- Explains which words you should use to describe what you want: e.g. a tall flat white with soy milk to go
After a quick interaction with the Coffee Ordering Interface, you get your service (coffee prep) and drink (the product).
In more complex technical systems, APIs do the equivalent of the Coffee Ordering Interface — enable two-way data, service, and product exchanges.
Using API, you can:
- exchange different types of information (location, payment, analytics, etc.)
- authenticate people, devices, and services
- incorporate third-party services into your product
- launch new user experiences, digital products, and services
In essence, with APIs, you can allow third parties to incorporate your product into their ecosystem (or gain access to the data you have) — and vice versa. With API strategies, you can become a platform business: a service provider that generates value by facilitating interactions between a large number of participants.
And there are quite a few benefits to being a platform business:
API integrations: Why should I get excited as a non-technical person?
To better understand the value of an API business strategy, let’s circle back to 2002. That’s when Jeff Bezos dropped the now notorious API Manifesto to Amazon dev teams. It read: The only communication allowed is via service interface calls over the network… All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn’t [use APIs] will be fired. Thank you; have a nice day!
The only communication allowed is via service interface calls over the network… All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Anyone who doesn’t [use APIs] will be fired. Thank you; have a nice day!
What he was trying to say is this: If Amazon wants to innovate, we have to first improve the way we exchange data internally between one another. For that to happen, things need to get automated and reused.
Amazon first transformed their internal architecture into a collection of interconnected microservices, communicating via APIs, so that they could be easily externalized first across departments, then across products, and ultimately across all assets under Amazon’s control. Afterward, they went on to take over the external API business strategy (more on that in a moment).
But let’s keep it real: Not everyone can be as lean as Amazon and just crack their internal systems open like a bubbling can of Coke. Why? Two words: legacy architectures.
Most businesses still run systems that were never meant to support omnichannel business offerings, and their architectures are monolithic. But over the years, business operations have grown more complex. You now have CRM, ERP, analytics, marketing, and several hundred other business apps in your technology portfolio. Some communicate with your monolith (i.e. exchange data). Most don’t.
Some companies recognized a while ago that they couldn’t move forward unless they decoupled the components of that monolithic architecture, dropped the outdated parts, and molded what was good into a new system using a service-oriented architecture (SOA) and later microservices. Learn more about the advantages of a microservices architecture
Learn more about the advantages of a microservices architecture
Others decided to leave the monolithic rock of a system as their core and build something on top of it. Oftentimes, they did this without ensuring that all new add-ons could properly communicate with one another. As a result, several issues arose:
- When the great race toward big data analytics began, monolithic businesses could operationalize less than 1% of their data.
- Addressing integration and new API elements requirements (set forth by leaders) cost lagging companies over $12 billion last year.
The average organization has 900 applications, and only 28% are currently integrated.
Being dragged down by a monolithic system isn’t cool. But it’s never too late to adopt Amazon-style API-centric thinking and begin internal transformations. In fact, it’s a strategic priority because tight integrations, reusability, and agility are the key to digital transformations.
Merely growing your technical portfolio of isolated apps and products won’t give you an edge. Building a tightly linked, collaborative ecosystem of external and internal partnerships will. And that’s why you should focus on developing internal API first.
Benefits of internal APIs
Faster development. When standardized, internal APIs can speed up the development lifecycle for a variety of business apps or augment their existing capabilities. For example, an API sharing CRM data can be plugged in to all your marketing analytics apps, customer service products, and external POS systems — and even shared with an external logistics provider.
- Rapid scalability. APIs add modularity to your systems, meaning you can plug them in to any system whenever the need arises. This further increases development speed and overall business agility. 46% of teams using API-led integrations gained greater agility through self-service IT.
- Targeted automation. Menial and manual processes can be replaced with APIs so your apps and services communicate effectively without any point-to-point integrations.
- Streamlined traffic management.API Management solutions control the flow of data (act as load balancers) and prevent system overloads when multiple requests pour in.
- Ecosystem growth.Using APIs, you can enable communication between external and internal applications to support new partnerships and deploy new joint offerings to users.
This ability to enable communication between internal and external applications is what has made possible the now thriving API-centric approach.
Source: MuleSoft — 2020 Connectivity benchmark report
Benefits of adopting the API strategy
“Increased innovation” is a rather lofty concept. So what exactly are you gaining from using external APIs (or opening yours to the world)?
Well, that depends on your business goals. McDonald’s is saving costs on delivery and expanding its service reach by partnering with Uber Eats. Stripe ensured fast adoption and rapid profitability by building a developer-first product with solid API documentation. Slack has gained market dominance as a team communication app by integrating with literally every other workplace product.
The three companies above illustrate three main benefits of API business strategy:
- Reduce churn
- Create product stickiness
- Achieve a faster time to market
Today, competition happens at the ecosystem level. No industry has a first, last, and lone product that fills all a user’s needs (though many attempt to, right, Google?).
Your average user (B2B or B2C) has a portfolio of services they use every day, each for a single purpose. If your product doesn’t play nicely with other important apps, you may get kicked out.
By opening up APIs for your internal apps and services, you can reduce the likelihood of churn:
- by being there when your customer needs you (offering delivery at 22:00 on Friday night)
- without investing in new infrastructure (an in-house delivery service or a standalone app)
Create product stickiness
APIs are like glue — they stick together various services and then they trap users into using them.
That’s how Slack became the product of choice for 65 of the Fortune 100 companies and some 10 million happy daily active users. Slack is so convenient and easy to integrate with anything else that you just can’t quit it once you’re entangled in the ecosystem. We are not looking for Slack to be the ‘every tool.’ We are trying to take the product to where you are.
We are not looking for Slack to be the ‘every tool.’ We are trying to take the product to where you are.
Other businesses can borrow a page from Slack’s book and orchestrate their growth by:
- integrating with other services customers already use
- maintaining a strong value proposition of core features built directly on the platform
Achieve a faster time to market
With strong internal API governance, you can break your core services into blocks and make those blocks talk with each other. But you can also invite third parties to play. With some 20,000 public APIs around the web, why build something new when you can borrow? For example, instead of building a new KYC solution for authenticating customers during digital onboarding, you can set up an API integration with a third-party service and run the KYC process through them.
Treat various APIs as LEGO blocks that you can add to your core services whenever you want to launch new customer-facing solutions. By further integrating third-party services into your ecosystem, you can create an invisible layer of third-party connections that add up to a consistent, diverse, and highly delightful connected customer experience. Third-party services can also provide:
- a higher level of personalization across various products
- the ability to rapidly develop and deploy new products to a warmed-up audience/li>
Ready to answer the call? Here’s how to harness API for your business
With plenty of API gateways on the market, it may be tempting to plug in as many APIs as your systems can handle. However, accommodating new APIs doesn’t necessarily translate into generating value from them.
While APIs multiply, ensuring a secure and stable interplay between an array of participants, the revenue opportunities from distributed services aren’t that straightforward. The same holds when you attempt turning your core services into APIs and sharing them with the world.
But there are always three key pillars to remember: an API strategy, a tech modernization plan, and a centralized API governance model.
The goal of an API strategy is to help you identify and act on the best API opportunities.
Customer and user journeys usually present a ripe stream of insights for API use cases. Analyze where your users struggle — do they lack access to data or services? Assess how a new integration can add value. Then test a possible API use case for feasibility in terms of technological, business, and compliance requirements.
Next, decide on what types of APIs you’ll use:
- Public APIs provide data/products/services to third-party developers to foster adoption or commercialize access.
- Partner APIs promote tighter integration with strategic partners by providing access to your data/services.
- Internal APIs strengthen connectivity between proprietary apps.
You don’t have to settle for one option only (most businesses don’t). But your initial approach to API distribution channels will largely determine how your business model can evolve.
For instance, you can choose to focus on public APIs and assume the role of an API marketplace or an “as-a-service” provider. In either case, you can generate extra value (and revenue) through monetizing access to your offerings.
- Fidor provides an array of banking-as-a-service solutions.
- Stripe is a payment infrastructure provider available to everyone.
Placing the focus on partner APIs is a solid strategy for companies interested in assuming the marketplace business model — growing through adding new players to their ecosystem to deliver value-added services.
Examples of API strategies:
- Starling Bank Marketplace complements its core financial service with extra offerings delivered via partners (insurance, accounting, taxes, pensions, etc.).
- WeChat is a Chinese super app that houses an array of lifestyle, commerce, and financial services under one roof.
Read more about the super apps business model
By using a combination of partner and internal APIs, you can also take on the aggregator role. And it’s a lucrative one. Trefis estimates that Expedia, whose business is built mostly on APIs, will generate $12.3 billion in revenue by the end of 2020 (despite the pandemic).
- Credit Karma launched as a free credit scoring tool, aggregating data via APIs.
- Mint is a personal finance management app that aggregates account information.
Learn more about why you should look into the business of account data aggregation
Ultimately, if you can master the art of all three API distribution channels, you can take on the role of an API platform business — an ecosystem connecting both internal and external players and effectively governing relationships between them.
A monolithic core is the biggest roadblock to getting into the business of APIs. But we also know that breaking that monolith isn’t feasible for most companies (at least not immediately).
Granted, there’s an alternative. To retrieve access to the data stored in monolithic systems, you can add an API abstraction layer atop your legacy systems and connect it with newer microservices. This layer can contain multiple APIs that chip away valuable data from the core and transport it to other services that need it, both internal and external.
(Sample API abstraction layer)
This approach can be a good middle ground for extending the life of your backend systems while you assess different scenarios for their transformation. Learn more about how to approach modernizing legacy systems
Learn more about how to approach modernizing legacy systems
Centralized API governance model
The more APIs, the more technical and strategic oversight they need.
First of all, there’s the question of API security governance. All the APIs you produce must have security standards and protocols along with access management controls and network monitoring solutions. Leaving your endpoints without proper protection is like leaving your house door ajar — you’re calling for trouble.
On a more strategic scale, you also need to ensure the proper execution and management of your API strategy. As Matt McLarty from MuleSoft suggests, you should base it around four P’s: I propose four categories of API governance: program, product, portfolio, and platform. In my experience, any conflict in an organization’s API governance happens between these areas, not within them.
I propose four categories of API governance: program, product, portfolio, and platform. In my experience, any conflict in an organization’s API governance happens between these areas, not within them.
An API program is a cross-company initiative that promotes the execution of your API strategy to achieve your goals and move toward your selected API monetization model. The goal of an API program is to:
- promote wider adoption of the API-led approach
- measure progress toward goals and reassess them if needed
- monitor the API program direction and results
The Bezos manifesto we mentioned earlier is a gritty example of an API program.
API product governance is aimed at improving the lifecycle of created APIs and measuring their success against the selected business model. In particular, you should focus on:
- establishing clear ownership of different API products
- collecting customer feedback and measuring API performance against set KPIs
- managing API-related product risks
- aligning new API initiatives with your business model, marketing strategy, and overall product vision
As the number of APIs grows, you’ll need to also establish an API portfolio governance framework — an oversight measure for all API products created, used, and shared with others. At this point, you should:
- ensure that consistent security, design, and development practices are applied to all APIs
- identify and manage redundant, unused, and low-value APIs
- verify that standard security and data collection policies are applied across the portfolio
- look into scaling API collaboration opportunities across partners
- evaluate various concerns that emerge with regard to the use of third-party APIs
API platform governance is the last evolutionary step on your journey. With a rapidly maturing API portfolio, your key concerns will shift toward automating your portfolio management and technically enhancing the operational environment for your APIs. To achieve that, you should:
- focus on finding solutions to prevent operational anomalies
- ensure automatic enforcement of API product and portfolio governance across the board
- make steady progress toward becoming an API platform business
From an API solution to a platform business
With the right LEGO bricks you can build an entire spaceship. And with enough APIs, you can convert your business from being a monolithic solution (doing just one thing great) to being a platform — doing a lot of things great with the help of connected partners.
And that means you can become part of the global commerce market that WHO? estimates will be worth $60 trillion by 2025.