In an earlier post, we described 3Scale involvement in the APIdays series of events and especially the most recent APIdays Mediterranea in Barcelona. In this post, I summarize my talk “APIs: From Value Chains to Value Networks” which I gave on the morning May 30th. You can find the slides on slideshare and embedded at the end of this post.
Setting The Context
My intention was to describe the current evolution from value chains to value networks, which is to a great extent enabled via APIs. Related to this I wanted to highlight some of the benefits that come with that evolution (such as new business models) but also some challenges. These challenges are mainly relevant for API providers but also affect API consumers (i.e., developers). There are several challenges; the ones I focused on were
- Providing an attractive offer (the API itself)
- Improve the discoverability of the API
Overcoming both these challenges will increase the rate of API adoption. I also discussed some suggestions about how these challenges can be addressed. In the API Evangelist Kin Lane’s classification my talk falls into the Business of APIs area.
The Evolution Into Value Networks
In business and management the notion of value chains are established and very well known. Michael E. Porter is primarily responsible for this is mainly due to publication of his 1985 book Competitive Advantage: Creating and Sustaining Superior Performance. His main idea is that a product or service (this applies mostly to physical goods) is passed from one discrete organizational unit to the next — each one adding value. The organizational units can be within an organization as well as between organizations. A crucial point: there is no feedback. A product moves through the chain in a unidirectional way.
This is changing now.
Increasing digitization of businesses results in their value chains being more multi-dimensional and more complex. Gartner argues that four main drivers strongly influenced the digitization trend, in what they call the Nexus of Forces: namely, advances in social, mobile, information processing (big data analysis), and the opportunities of cloud. The consequences of these developments are in line with the notion of value networks. The idea is not new and several works describe that notion. One interesting article was published in the European Management Journal (2006) that addresses the evolution from value chains to networks, specifically in the context of mobile network operators with a lot of generally applicable principles. I prefer the Norman and Ramirez definition (1993) which says:
A value network is defined as a value creating system in which all involved stakeholders co-produce value.
A very representative example of value network is Twitter. The Twitter network has a lot of stakeholders that contribute to value production from all sorts of different angles. Some good examples were recently acquired by Twitter, such as Gnip or Mesagraph. Moreover, every developer who uses the Twitter APIs is a stakeholder too and co-produces value, too. In fact, a great portion of Twitter traffic is not actually produced by Twitter products, but comes from third parties out of Twitter’s value network. An older article on ProgrammableWeb from 2010 cites that this portion is actually 75%.
Implications Of Value Networks
The consequence of value networks is the co-production of value between stakeholders. Central to every value network is a platform that enables this co-production. A vendor (Twitter in the earlier example) decides to create a virtual or physical platform which enables third parties to leverage the assets provided by the platform (Twitter’s API and developer program). Such a platform facilitates integration and makes collaboration a lot easier.
This fact gave rise to the Platform Business Model, which is a way to define, create, and capture the value co-produced between the stakeholders in the network.
The benefits of platforms are primarily scalability and speed as they mainly build on network effects (see Metcalfe’s law vs Dunbar’s number). This was also reinforced in the talk by Redbooth’s Jordi Romero who explained in his presentation the API-first approach to business development and highlights how difficult and slow business development and subsequent technical integration was in the times before APIs.
A great example for a physical platform are the railways and how the U.S.A. was conquered by them. It is an example for platforms in two aspects. First, before the railway officials could even start to build the railway network they had to agree on the shape and form and width of the rails itself. They had to come up with a standard. Once this was specified they had their standardized platform on which they could build to establish the nationwide railway network. The second aspect refers to the time when the railway network was established. It then served as an effective distribution network to deliver, for example, the post, goods or people. In other words, the railway network represented the platform which was the basis for a lot of considerable economic benefit. Other examples of virtual platforms, which are very well known in the space of the API Economy, include Spotify, Airbnb, or Evernote.
It goes without saying that probably the most influential enabler for the establishment of the Platform Business Model for virtual platforms are APIs. Platform providers who expose assets via APIs face several challenges to achieve one of the most essential objectives – to increase the API, and hence, platform adoptions. I will cover two of these challenges in more detail.
Challenge 1: Be Attractive
The attractiveness of an API is strongly related to the developer experience (DX) delivered by the API provider. The two core underlying principles of DX are, first, to provide a valuable service and, second, to make access to it really simple.
Another related element to attractiveness is the deployment of open standards. Using open standards means that concepts are re-used that are in most cases tested and established. So, developers can rely on the fact that this works. The wheel does not have to be re-invented (an image API is an image API and will not differ much between image API providers) and the whole value network around an API provider can move faster and more effectively. The same code can be used on the server as well as on various clients. Common standards can also lead to the establishment of tools or tool chains that can be shared across different platforms.
One such standard is API Commons that does exactly that. API Commons can be used in two ways. Either existing and registered API designs can be re-used under Creative Commons licenses as is or modified, or anyone can submit API specifications and see how the community develops it further.
It is very simple to add API designs to API Commons. An API Commons manifest needs to be created and then submitted. The manifest is JSON and can either be created manually or by using the API Commons manifest generator (see screenshot below).
Challenge 2: Be Findable
Being findable is really about the discoverability of an API. What is the best API design and most efficient API operations worth, if no one can find and adopt it? This is crucial.
In that context I found the works of Sangeet Paul Choudary (@sanguit on Twitter) very interesting and helpful. In a Harvard Business Review article together with co-authors Sangeet describes the three elements of a successful platform strategy. He denotes those elements as Connection, Gravity, and Flow. I recommend reading up on these, but for the scope of this post will only focus on Flow, which the authors define as “how well the platform fosters the exchange and co-creation of value.” That ties in with what they call matchmaking tools to achieve flow, which facilitate the connection between producers and consumers in a value network. A perfect example for such a matchmaking tool facilitating Flow is Google. In the world of APIs equivalents would be API directories such as ProgrammableWeb or Mashape.
A new API search service is APIs.io, which differentiates via an envisaged automatic discovery service. APIs are described and discovered based on the standardized APIs.json format, which should enable crawling and automatic addition of new APIs to the API search engine. APIs can also be added manually by describing an API according to the APIs.json format, hosting this file on a server and registering the URL on APIs.io. The API can also be described using the APIs.json Builder which is basically a Web form that generates the json (see screenshot below). Additionally, the whole APIs.io search engine is open source. So, everyone can take it and build her own API search.
Value networks have emerged from value chains due to digitization and its consequences. A value network is characterized by collaboration between all the stakeholders to co-produce value. At the center of a value network is a platform. To define, create, and capture value the Platform Business Model encapsulates the platform. Platform or API providers are primarily confronted with two challenges: how can the platform be (1) attractive and (2) findable for API consumers (developers). As discussed in this post, a contribution to address the challenge of attractiveness can be the deployment of open standards (such as API commons). To tackle the challenge of discoverability making sure to register an API at API directories and especially automated API search engines is recommend (such as APIs.io).