Monthly Archives: November 2014
My good friend and mentor Phil Windley recently published “The Compuserve of Things“. As usual the information is well thought out and clearly articulated. It is so good I wanted to reiterate portions. Here is the summary:
On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980’s, or will we learn the lessons of the Internet and build a true Internet of Things?
This also reminds me very much of the saying Doc Searls gave me:
Freedom of choice does not equate to choice of captor.
The way the internet is being used today, we have become numb to the process of being herded into silos of captivity. The first step to remedy this is awareness. Not always easy to resolve.
A Real Open Internet of Things
If we were really building the Internet of Things, with all that that term implies, there’d be open, decentralized, heterarchical systems at its core, just like the Internet itself. There aren’t. Sure, we’re using TCP/IP and HTTP, but we’re doing it in a way that is closed, centralized, and hierarchical with only a minimal nod to interoperability using APIs.
When we say the Internet is “open,” we’re using that as a key word for the three key concepts that underlie the Internet:
- Heterarchy (what some call peer-to-peer connectivity)
I really like these concepts. It all begins with awareness.
It’s been a pleasure for us to work together on trying to derive a sound basis for thinking about the API Economy – but that basis isn’t very useful if it isn’t built upon. So today we’re introducing the second part of the API Economy Axioms series – a look into what the consequences of these axioms are.
We’re starting off in this post by summarizing the five axioms and from next week we’ll be covering what happens next:
- Implications for individual organization
- Implications for Internet and business ecosystems as a whole
- The challenges to be faced – both technical and organizational
If you missed any of the Axiom posts, they are linked below in each section.
Summarizing the Five Axioms
In summary, the Axioms are defined as follows:
- Axiom #1— Everything and everyone will be API-enabled: This Axiom highlights the fact that almost every network connected endpoint is becoming an API that can be invoked and read by other software systems. This transformation, when seen device-by-device or step-by-step, seems logical – perhaps even mundane. However, the point behind this Axiom is that as a macro phenomenon we are quickly accelerating into a world where almost every device and system is addressable via APIs. [Axiom 1]
- Axiom #2— APIs are core to any cloud, social and mobile computing strategy: More concretely than Axiom 1, this Axiom describes how APIs form part of what are arguably the three most important transformational forces in the online economy today: cloud, social and mobile. It’s very clear that many of today’s innovations in these areas would be impossible without API-like architectural patterns (even if not always named APIs) and that APIs are enabling yet more of this same transformation. [Axiom 2]
- Axiom #3 – APIs are an economic imperative.: This Axiom shows that APIs are at their core not simply a technical phenomenon, but are intrinsically linked to the creation and access to value – resulting in economic impact. This does not necessarily mean relevant APIs are “paid for services” (although some are), but in fact that almost all APIs enable, improve or scale value in ways which increase economic impact. [Axiom 3]
- Axiom #4: Organizations must provide core competence through APIs: This Axiom zeros in on the fact that the transformation that matters most is when it’s core competence as an organization is made available as an API. In other words when APIs become drivers for core business, and enable partners and customers to engage, provision and consume that core competence in new ways. [Axiom 4]
- Axiom #5 – Organizations must consume the core competencies of others through APIs: This Axiom is a counterpart to Axiom #4 and highlights the fact that consumption of the APIs of others is of equal importance to provision. When this consumption is of the core competences of others then this provides the strongest foundation for business partnerships. [Axiom 5]
By themselves, these Axioms can seem rather dry or disembodied – why these Axioms and not five others? While it is hard to know whether we chose the correct five building blocks they were chosen because they illustrate different dimensions of what is happening in the API Economy today:
- Scale – Axiom #1: reaching almost every software and hardware system being deployed.
- Momentum – Axiom #2: underpinning huge global transformative trends.
- Economic impact – Axiom #3: moving from a technical phenomenon to a business essential.
- Imperative to provide –Axiom #4: demonstrating the impulse to offer APIs.
- Imperative to consume – Axiom #5: closing the loop on provider – consumer relationships for services.
But, the proof in the pudding is whether or not, these Axioms allow us to say something about how we think the API Economy will evolve, change and impact business.
This is the subject of the next set of posts we have queued up – we’re looking forward to people’s thoughts on both the Axioms and what we can derive from them!
Having stated the Axioms in previous posts, a number of big picture questions arise: beyond how they are related 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 a reality?
The first post covered implications the Axioms have for individual organizations. In this second post, we cover implications for the market in general, the API providers, consumers and infrastructure organizations.
To look at this, it’s helpful to think in terms of what the axioms imply and what can be derived from them for the technology market in general:
- Axioms #1, #2, #4 and also the arguments in the previous post on the imperatives for individual organizations to become API providers, show there is very clear pressure for more organizations to open APIs — both to smaller selected groups of partners and to the wider world. The value of each API is initially in the ecosystem built around the API and this is already sufficient to push many organizations over the edge. One of the important byproducts of this is also to increase the supply of APIs available in the economy — essentially each launch creates a new building block for others to use.
- Via Axiom #5, there is huge benefit in consuming the APIs provided by others — often the organizations providing them offer specialist services of very high grade which would be impossible to replicate internally. Not using these often results in significant loss of competitive advantage. This fact creates clear demand pull for available APIs and further, leads some organizations to go as far as asking their existing partners and suppliers for access to API capabilities.
- As the economic imperative plays out (Axiom #3), organizations are naturally drawn to want to exploit these opportunities for increasing gain: providers to reach a greater audience with their offering and API consumers seeking increased benefits from external services.
So, one can think of the API Economy emerging initially as a series of strong individual ecosystems around valuable individual APIs — each of which has its own growing customer or partner user base. However, over time more and more APIs emerge, and those API consumers getting benefit in one place begin to demand it elsewhere.
This dynamic implies a “positive feedback loop” between new APIs becoming available, new API consumers and increased API consumer pull — an autocatalytic chain. The growth of new APIs is the driver for new API consumption and vice versa. The question is – what are the signs that this interconnectivity is emerging and acting as a loop?
We first look at the API supply-side, then the demand-side and finally end with some thoughts about the feedback loop.
There are some excellent API programs we can examine that can be examples for how all providers should design their programs (Twilio, Sendgrid, Stripe, NPR, Twitter, Facebook for example) and they have gone on to build huge audiences. As a result, all of these organizations have large and successful developer programs with a significant number of apps and services that use their APIs.
The ultimate objective of any API program is to garner a relevant group of developers that use the provider’s APIs. Each API Program – whether tailored to the broader public, customers or close partners creates its own community of value, as illustrated in the Figure 1 (Source ProgrammableWeb):
Figure 1—API Growth Source:ProgrammableWeb
In Amazon’s case, APIs spurred both internal innovation, resulted in a large network of resellers, power their own mobile devices, and added a whole new line of business. The API layers built by the company are now an intrinsic part of their business.
Once a customer/partner community is within this particular orbit, they are able to plug into existing services. However, Amazon has also added new services over time to serve more demand. For example:
- Amazon Redshift—distributed hosted data warehouse services
- Amazon Route 53—highly available DNS services
Similarly, many other organizations extend the functionality of their APIs over time – Paypal, Twitter and more. In some cases functionality is also restricted over time as business models change.
As we have noted in previous posts, an interesting dynamic occurring in the industry is as more new and traditional vendors are jumping into the game with solid API programs, this stimulates interest in partners, competitors and other constituents to do the same:
- Walgreens was one of the first retailers to open an API, many other retailers have since done the same.
- USA Today and the New York Times were very early in the media field — many other news and content organizations have since followed.
The result is impressive annual growth in the number of APIs — both public and private. The number of APIs now listed on ProgrammableWeb is now approaching 14,000.
The other dynamic regulating the growth of the economy feedback loop are the dynamics occurring in the consumption of APIs and mashups of APIs from all sorts of organizations and independent groups and developers. Some of these dynamics are recognized in the following ways:
- Each of the APIs has its own user base,
- Each user of the API is deriving value from the APIs,
- Many API consumers use more than one API.
As an indicator of developer engagement, the number of developers using APIs is continuously rising — 3Scale now has 150,000 developers using the APIs it powers as does Mashery. While there is likely overlap in these populations, there is strong regular growth in developer numbers.
It is a little harder to measure demand-side pull for new APIs. Anecdotally however:
- Quora regularly surfaces questions of the form “Does X have an API?” — Recent examples for X include WhatsApp, Uber, Square, ZocDoc, Viber, Qwiki and Quora itself.
- Many of the organizations working on new API programs also cite customer and partner demand as a major reason for opening a program.
In sharing the first API Economy axiom with a close friend and programmer we received his response that brought up some relevant questions:
“Maybe this will be covered in later axioms, or maybe it isn’t appropriately part of the axioms, but this is my gut reaction as an old programmer when I read about the API Economy: ‘Gaaaah!!! It’s hard enough keep track of the few hundred APIs in the Windows SDK and the handful of web libraries I use now. So now I’m supposed to be able to use potentially billions of APIs for every service, company, platform, and potentially every user on the internet? Who will document all those APIs? Who will test them? Will there be meaningful version control so I know when something changes? Will there be any consistency in syntax, performance and data usage? I think I should have listened to my Dad and gone to law school’.”
As this programmer asks, what about version control and search? Many organizations use Github to present their APIs to API consumers to address this.. Indeed Github has its own set of APIs to automate this process. Kin Lane—API Evangelist—gives a great example of a coder that instinctively figures out how to make this happen on his own (the post is here.)
There is much done, and much more to be done on the consumer side of the dynamics of the API Economy.
With some exceptions, todays APIs are individual silos that are focused on interacting with just the constituents of a specific organization. They are islands of functionality – the question is, will these islands join up into a coherent “economy”?
A Feedback Loop And A True “Economy”—Distributing, Managing, Monetizing And Aggregating The API Economy
Each API grows its own user-base over time but there are often overlaps in the mesh of APIs and certain API providers with together — for example Twilio, Sendgrid and a number of others often participate in hackathons together. There is also clear API consumer demand being expressed.
The question is, are these individual islands driving and feeding each other enough to create a big enough loop to generate autocatalytic growth?
The answer is — yes. There are clear signs that this supply-demand loop is acting, accelerating, and at the same time causing acceleration of growth in the creation of API programs. Further, there are also clear signs that while the API landscape is still a patchwork of ecosystems and technologies, there are structures emerging that are beginning to cut down the friction and create more connectivity. At the most fundamental level, there is clear cross-pollination between API programs:
- API consumers of one type actively demand and subsequently use APIs in other areas
- Organizations that see competitors provide and consume open APIs are driven to follow
- Technology best practices are increasingly being re-used across APIs so developers are less often faced with unfamiliar design patterns.
These are now being reinforced by a wide range of fledgling activities which act to glue activities that when combined together reduce the “friction” in any economy:
- Conferences: A number of API conferences have now sprung up from the API Strategy & Practice Conference to APIDays, Nordic APIs, API World, iLoveAPIs and APIcon as well as Gluecon which cover APIs often and early. These and smaller technical events like RESTFest and API-Craft do much to share best practice and encourage technical development.
- Best practice blog posts and books: A large amount of blog materials, video, presentation and other content is now available to share how to achieve things with APIs – both from technical and business perspectives. Efforts such as APICodex (by 3scale) and APIAcademy (by Layer7) help categorize and track the best of this content.
- Analyst reports: all major analyst groups and most subgroups are proactively monitoring and reporting on the API economy.
- Directories, discovery and search: A fundamental element of a genuine economy is the ability to find APIs to use – ProgrammableWeb was an early pioneer in this respect, acting as a directory for open APIs, Mashape plays a similar role and APIs.io is attempting to add a search engine style approach.
- Tools for API providers and consumers: The technology for deploying and managing APIs was complex and unwieldy early on – however companies such as 3scale, Intel-Mashery, Apigee now provide tools which make it easier for providers to get into the game. On the consumer side, the toolset is also increasing with tools such as APItools, Runscope, oAuth.io, APIMetrics, SoapUI making API testing and usage much easier.
- Ratings and Trust: A problem that arises as an economy grows is knowing which APIs to trust and api500 is a first attempt in that direction.
- Aggregators: The emergence of aggregator APIs which wrap other APIs are also another sign of structure being added that connects individual APIs – examples include Newscred, Segment.IO and Singly (now part of Appcelerator).
- Mashup Tools: Lastly tools such as IFTTT and Zapier are making it easier for end-users to combine APIs – improving the value that can quickly be gained by using multiple APIs at once.
In some of these cases products and services are still in early stages, while others are already very mature. Together they are all signs of a connective tissue forming which helps the iterative interactions between API providers and API consumers. The two-way flow of demand is therefore becoming more agile and efficient and creating the autocatalytic positive feedback loop we are looking for.
APIs as a tactical means to support the business of an individual organization deliver value – in general both to the provider and the consumer. This, in and-of-itself makes them valuable to build. However, what is also clear is that there are many transversal benefits to the development of many APIs – competing and complimentary. Shared technology, conferences, inspiration and re-use in unexpected ways all drive the feedback loop to make an Economy of APIs more valuable than the sum of the parts.
Many of the structures that glue this economy together are still extremely nascent or not widely used, but the fact that they exist at all suggests there is increasing value in the feedback loop. It seems likely that both the number of individual APIs and these structures will all accelerate.
In the next post we’ll explore how we might define the API Economy and in posts that follow we’ll look at challenges for individual organizations and the Economy as a whole.
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.