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.