The Five Axioms of the API Economy (find a summary post here) presented in previous posts articulate some baseline assumptions about world that appear to be true – and are likely not just to hold –but grow stronger over time.
Having stated the Axioms, a number of questions arise: how do they relate to individual organizations? What effect do they have on the evolution of the web and the economy as a whole? What challenges are there in making the API Economy reality. As we continue the series, we’ll dive into these questions from different angles. The first, covered in this post, is what implications the Axioms have for individual organizations.
According to a research report by Wipro & Cutter Consortium, 83% of organizations are either engaged in an API program now, or are planning to in the next three years. (API research report) – so this indicates that there are clearly drivers in play for organizations to work with APIs – the question is what do our Axioms tell us.
To look at this, it’s helpful to think in terms of what the axioms imply for an individual organization (specifically, what can be derived from them). In particular:
- Axiom #1 tells us that it’s likely products, services and the organization itself will require APIs at some point in this future – as will those provided by competitors – the only question is how and when.
- Via Axiom #2, if the company is investing in social, mobile and cloud integrations or products, APIs are likely already on the agenda in some form and effort is already being put in – however, not necessarily with the right long term focus.
- Via Axiom #3, the api-ification is likely to have significant economic impact on the top and bottom lines at the point when it is carried out.
Axioms 4 and 5 together tell us that organizations need to find ways to provide their customers/partners access to their competences in API form. Additionally, they should find strong, stable partners to bring in competences that are secondary to them.
In other words, there will be a push for APIs to play a significant role for most organizations – at least those with some kind of digital presence. There is little sense of timing however. Although there is a general sense that API-ification is proceeding quickly in some sectors of the economy, it’s difficult to pinpoint sector-specific timing. The only clear indicator is that early movers potentially have a large advantage in locking up customer/partner ecosystems for themselves.
So, a statement like:
Go and do APIs, urgently!
is not particularly helpful, so in this post we’ll look at some of the most common use-cases for APIs today. At the end of the post we’ll wrap up with critical questions to help evaluate what the drivers for an individual organization are.
Common API Use Cases
In this post, we’ll cover six of the most common API use cases we see commonly – at 3scale it’s rare that customers seeking to launch APIs have use cases outside of these six or combinations of them. They use cases are:
- Mobile Enablement
- Customer Ecosystems
- Partner Ecosystems
- Distribution for Content and Transactions
- New Business Models
- Internal Innovation
A more in depth discussion of these can be found in the introductory eBook Winning in the API Economy.
First generation mobile applications typically offered functionality that was limited to the operation of the device itself – making calls, sending messages and storing modest amounts of data in local memory. Applications soon began to provide more utility and richer experiences by using backend services for added content and transaction functionality.
As mobile applications evolve, they are now generally available in multiple versions for various operating systems and devices—Android, iOS, Windows Phone or even next-generation non-mobile devices such as Smart TVs. This increases audience reach but also significantly increases management complexity.
Recently, it has become clear that the platform of choice for new applications is the mobile device. Smartphones and tablets are quickly overtaking the desktop as the place where developers have focused their efforts for new applications. Almost without exception, this new breed of mobile applications is being built on existing and emerging APIs.
According to Evans Data’s recently released Developer Population and Demographics Study, of the 19 million software developers in the world, 8.7 million are now writing apps targeted for mobile devices. That number becomes even more impressive when we consider that the mobile developer population has doubled since 2010 and added 700,000 new developers in 2013.
A common challenge for organizations is to serve special needs that vary on a customer-by-customer basis. In enterprise scenarios this typically leads to staffing significant post-sales engineering teams to provide on-premise customization and installation. In others, it can make products hard to sell versus in-house builds. In still others, companies simply cannot tackle certain market niches since they are not profitable enough to serve.
Exposing programmatic functionality to customers has multiple benefits. First, it enables customers to increase the value they derive from a service to suit their own needs more closely. Second, tighter integrations encourage customers to drive more transactions through the systems, often increasing revenues. Third, integrations by customers represent significant efforts, reducing the likelihood that they would switch vendors. Lastly, platform access is often an up-sell driver (for example, Salesforce API access is only permitted for enterprise level contracts).
Using APIs to develop customer-centric applications is changing the way organizations approach managing customer ecosystems. Organizations are building both customer-facing applications and allowing their development through and API program.
A similar but different opportunity for APIs is in exposing APIs to third party organizations that act as partners rather than customers. Specifically these organization may be suppliers, resellers, provide value-added features or generate a range of other benefits. A partner ecosystem and API typically differs from a Customer Ecosystem in that the functionality accessible to the partner tends to be in the form of management level interfaces (account creation, affiliate management, metrics across customers and so forth). Further, partners generally have differing legal agreements.
Partner Facing Applications: Exposing functionality in ways that allow third parties to re-package functionality and deliver it to new audiences is covered in more detail in the next sections. However, it is one of the most common ways to view platforms. Platform tools allow motivated partners to create specialized versions of a service for new audiences and market them separately.
Integrators and Software Partners: Rather than replicating functionality, a third type of platform user is one that augments the functionality of the original product, either by providing new software applications (such as the Salesforce Application Ecosystem) or by providing connectors to their own services (partner marketplaces for example, such as those run by Zendesk and Atlassian where the apps are often bridges to other systems).
Distribution for Content and Transactions
One of the areas in which platform thinking has been most immediately valuable, and deserves its own category, is in powering distribution.
The notion of a digital sales channel used to be tied to companies having and managing a web presence, an HTML destination site where customers could browse product information (content, media, services or physical goods) and engage in purchasing transactions. But mobile added another channel that needed to be managed—often in an entirely different way from how existing properties are managed.
In the new API economy, however, this thinking is outdated, and there are more opportunities for distribution than ever before. A multi-channel distribution channel is now clearly the strategy to pursue.
Building APIs that accelerate reach fall into two broad categories, depending on the type of product involved:
- Content and Data: Content and media businesses are always seeking new ways to reach their audiences. While a company’s own web property and mobile applications may provide the primary means to reach audiences, in the API Economy this is no longer enough. Because consumers expect content to be available whenever and wherever they need it, companies that become adept at delivering this have a powerful advantage, be this on new hardware devices or through partner channels or aggregators.
- Transactions: Providing inventory and transaction capabilities in a programmatic way and using both to drive transactions is a powerful strategy for eCommerce businesses, and it can also be beneficial to brick-and-mortar retailers. Since business success is strongly correlated with transaction volume, APIs can enable increasingly powerful affiliate models to drive business, or even more radically, support wholly self-sufficient third party resellers.
New Business Models
Although many API use cases involve feeding and extending existing business models, some are focused on the creation of entirely new business opportunities or even the establishment of new primary channels. A new API may even become the primary product for a company or one of its divisions. Consider these two examples:
- Google Maps: While many users experience Google Maps on one of Google’s own properties, it is also by far one of the most widely-used embedded APIs, which adds Maps to a wide range of third-party sites and applications. Although Maps are free to use for the end user, and though the API is also free up to a certain number of users, Google does charge for usage above this level, to recover the costs of serving the heavy traffic loads.
- Twilio: Twilio is one of the leading companies worldwide in programmable communications infrastructure. The company’s well known API makes it simple to set up voice calls, send SMS messages and carry out complex call management tasks using just a few API calls. Additionally, the company is widely praised as having developed one of the most developer-friendly API experiences.
The business model in both of these examples is directly tied to the number of calls on their APIs, the number of results returned or other metrics directly related to API traffic. Such metrics can be used in contracts, and are tied directly to billing.
In each case, the API is essential to the business model. Each API call (an SMS sent, a map tile served), is closely correlated with calls to the service and value to users.
Until now, we have provided examples of external-facing APIs, and we described how to use such APIs to build strong partner ecosystems and drive new business. Arguably, however, the most immediately accessible opportunity for many businesses is an internal use case for APIs.
Companies manage collections of important internal systems, all of which mesh in complex ways to deliver products and services. As an organization grows, these systems change, get re-purposed, and, if they are well managed, they can become key assets in delivering ever more innovative services. Unfortunately, the development of new products, services, and processes is often carried out in a manner that weaves a complex web of inter-dependencies across legacy systems. This can slow innovation significantly and in some cases, it simply rules out new projects. Potential issues include:
- Greatly complicated maintenance, since the layers of dependencies often need to be worked out prior to setting regular maintenance activities.
- A significant amount of refactoring forced on teams tasked with creating new systems.
- Challenging and lengthy work required to actively define the nature of the interfaces to different internal systems, departments and processes can create an environment that is ready for change and innovation.
Using APIs internally eases these burdens and can create synergy between divisions and workgroups that didn’t exist before. Many organizations—such as Amazon—require that internal groups provide API access to information and resources.
There are strong business and technology trends that are driving universal adoption of the API Economy and the trend of 83% of organizations being engaged in creating an API program is no accident. The benefits of an API program are proving to be valuable and measurable. As we have shown, the key business and technology drivers occurring in the industry are the same drivers that indicate organizations should do more than just consider an API program.
In the next few post we’ll be exploring the Macro affects of this proliferation of APIs and also the steps to take to run a successful API program.
The Five Axioms of the API Economy
This blog post is the fifth in a series of blog posts outlining the axioms of the API economy – and covers the fifth and last axiom. However, it won’t be the last post in the series – once we’ve covered all the axioms, we’ll proceed and talk about their consequences also.
The five axioms we’re covering are as follows, in order:
- Everything and everyone will be API enabled.
- APIs are core to every cloud, social and mobile computing strategy.
- APIs are an economic imperative.
- Organizations must provide their core competence through APIs.
- Organizations must consume core competences of others through APIs.
Axiom #5: Organizations Must Consume Core Competences of others through APIs
The fifth and final axiom is the converse of the fourth axiom. Just as there is value in exposing APIs for others to consume, there is value in consuming the APIs of others. So much value in fact it is very likely a critical failure not to do so. Examples of this have already been given with Axiom #2 – for social, cloud and mobile (the former two in particular), the amount of functionality now available via API to simple use “out of the box” is staggering.
More specifically – the effort required to rebuild the features of many PAAS, IAAS, SAAS systems to the same level of functionality and consistency is beyond the capacity of all but the largest companies. Replication of some services is furthermore impossible – while it is feasible to write code for a microblogging service, Twitter is Twitter since it commands a global audience, not because of the functionality it provides.
The richness of functionality now available “by API” extends into multiple different realms:
- Data: impressive data catalogues of many types – many unique.
- Communications: SMS, Telephony, Instant Messaging, Video, Email.
- Processing: IAAS, PAAS platforms or specialized services like Aniomoto.
- Transactions: Payment APIs, Subscription Billing and others.
With such a rich set of tools available, developing systems has become significantly easier than it was 5-10 years ago. While choices need to be made both between providers and which elements should be developed in-house it is clear that many of these systems have the possibility to be of very significant value to an organization.
Any work an organization does that this is not focused on its core competence is arguably overhead. In other words, if comparable competitors were to use external APIs to achieve some important but non-core / non-differentiating functionality and this worked at least as well as an in-house build, this competitor would have freed up time to move further ahead on their core product. The opportunity cost of in-house builds of non-differentiating services is great.
It is therefore an imperative for organizations to:
- Identify what their own core competence / differentiation is and ensure that the majority of effort is targeted towards this.
- Where possible consume APIs of others to bring in functionality that is non-core in in this way.
There is a final, subtle angle to this axiom – it suggests consuming the core competences of others, not any competence. This means that if an API is chosen for use, it should ideally be something which is clearly and obviously linked to the core business of the organization providing it. This ensures that:
- The provider is likely to remain committed to the API.
- They derive value (economic or otherwise) from third party use of the API and hence should continue to support it.
These are all very strong indicators that the API will be maintained and improved over time. They also means that in many cases (though not all) there are likely competing companies providing similar APIs – providing a switching path in the case of failures on the part of the chosen provider.
If an API is a secondary, side business for an API Provider or does not seem to be core, this may be a higher risk integration – generally assurances from the API Provider should be sought.
Axiom #5 makes it clear that any API strategy not only includes the publishing of APIs for other constituencies to participate with but for organizations to plan on integrating the core competencies of their constituencies into their applications services and infrastructure. Make sure your organization understands the dual nature of API publishing an API consuming.