Monday, March 10, 2014
API Magazine Newsletter (Feb.’14): About APIs and Developer Evangelists
The February 2014 edition of the API Magazine Newsletter went out a bit later this time. I clearly blame the MWC14 hectics for this delay. This edition featured topics including:
- Slides and video about a talk I gave at the Operator API Seminar at MWC14 about what developers think about operator APIs and services
- Two really useful tutorials about how to establish REST APIs using either Node.js/restify or PHP/Slim
- The infographic about the API Economy
- A thorough write-up of a panel about a API design (and DX) held at DeveloperWeek
- Rationale about private APIs
- Info about the APIDays event in Barcelona (May)
- And many more…
Thursday, March 6, 2014
Operator APIs — What developers think
Here is a summary of the key message of my talk
Developers are key!
You may think you have the best API or service in the world. If no developer adopts it, you will not be on the market and you will not have end users to capture value from. Value does not necessarily have to be monetary value as I have discussed in my article Leveraging APIs as part of Digital Strategy. Developers are the crucial element in the API value chain. Without them this chain is broken.
(Note: I am sorry, in the video I refer to Pamela as Amanda. That’s wrong. Her name is Pamela Fox.)
In general, DX has two underlying principles:
- Value: provide something of value
- Simplicity: make it easily accessible and useable
Another important aspect is that there is not the typical developer. According to the Evans Data Corporation there were 18.2 million developers worldwide in 2013. That is a lot and developers have very specific and diverse requirement and what means value to one developer may be worthless to another. Hence, as someone who provides APIs or technologies for developers in general you need to have a very clear understanding of the pains and gains of your developer segments.
Coming back to the two DX principles – value and simplicity – and the main topic of the seminar – operator APIs – we conducted a global survey to find out how developers perceive the value of operator APIs and services (find this survey here).
This study showed that developers clearly see a value in operator APIs and services per se. However, there is also a gap in this perception and the actual adoption. 81% of the participants claimed that operator APIs could improve their apps; but only 33% actually adopted these APIs. I believe that this gap can be narrowed by addressing the two DX principles.
In terms of value a lot of the typical operator assets were confirmed as valuable. However, reach is underutilised, which according to Vision Mobile’s latest Developer Economics report (2014/Q1) is the most important criteria for tech adoption. Revenue BTW is after speed and cost of development, performance, and documentation only on the fifth spot as important criteria for adoption a technology. Operators could provide developers with much wider reach by providing cross-operator APIs.
Simplicity, however, is a major area (and concern) for operators to work on based on our study. There is a significant difference about how younger API providers engage with developers compared to how operators do that. For more details have a look at the Stripe case study I wrote earlier. The quote below is quite representative about what we got back from developers regarding qualitative feedback.
I concluded this talk with the following quote by Abraham Lincoln:
With public sentiment, nothing can fail;
without it nothing can succeed.
This idea is perfectly transferrable into developer engagement. Developers are the crucial element that makes the API value chain work. That needs to be embraced. As an API provider (regardless if operator or not), you need to be in the mind of the developers and you need to be experienced with a positive sentiment.
Here is a link to the Value of Operator APIs for Developers survey.
Here are the slides:
Here is the video:
Sunday, February 16, 2014
The API Economy Infographic
I put together several aspects, contents and technologies related to the API Economy and established an infographic.
This infographic has two sections:
- What is the API Economy?
- How can it be realised?
This is the direct link to the API Economy infographic.
I used piktochart.com which is quite handy. If you visit the direct link above, try out their infographic presentation mode. It’s quite cool:
Below is my infographic also directly embedded into this blog post.
I would like to know your thoughs. Feedback is more than welcome; I plan to do various revisions of this infographic as the API Economy evolves.
Friday, February 7, 2014
API Magazine Newsletter (Jan.’14): About APIs and Developer Evangelists
The January 2014 edition of the API Magazine Newsletter went out earlier this week. It featured topics including:
- A prezi on Identity in the API Economy by Craig Burton
- An Economist article about platformization
- A discussion about defining the API Economy and its impact
- Some articles around REST and hypermedia (including some Roy Fielding work)
- Concurrency control in practise (nginx)
- More on APX (Application Programming eXperience)
- The gap between academy and industry (especially related to knowledge in software engineering)
- And many more…
Thursday, January 30, 2014
API Economy defined
The Rise of the API Economy
More and more companies from a variety of different sectors and industries recognise that they have valuable assets to offer (data, functionality, or computing resources) to address different objectives. Via APIs they found a way to open up these assets to the public – or to be more precise to developers. A prominent example is Expedia, that launched their Expedia Affiliate Network developer program to allow access to their travel services and by doing so created new revenue sources. Today they have about 5,000 developers whose apps and services account for over half of Expedia’s revenue. A collection of further frequently cited examples of business cases related to APIs are summarised in this whitepaper or in Robert Medrano’s guest post on Forbes.com “Welcome to the API Economy”.
This trend gave rise to the notion of the API economy. But how can this concept be defined?
The dictionary defines “economy” as an “entire network of producers, distributors, and consumers of goods and services.” Very generally that means that in an economy goods or services are produced, sold and distributed to consumers. To keep an economy alive, consumers need to see value in a product which leads to a purchase decision; producers need to make profit, which is the idea of demand and supply.
Many articles can be found on the Web specifically talking about the API economy. Rather then re-inventing the wheel, I wanted to find and discuss existing attempts to define the API economy; and then see what that means and how this can be used.
All commerce generated by the business of providing, consuming, integrating, and adding value to data (and thus often to products and services) via application programming interfaces (APIs) that create economic value.
Another definition comes from the Cutter Consortium:
While Forrester’s definition is certainly appropriate, I prefer the second one by the Cutter Consortium as it is more concrete. Internal business assets broadly are either data, functionality (e.g., algorithms) or computing resources. These are made accessible to third parties via APIs, which is irrespective of the technology or protocol to achieve that. Regarding “additional business value” the current consensus is that this can be captured through four benefits:
- Wider reach (e.g., customer, partners or brand)
- Service/product enrichment via open innovation
- Additional sources of revenue or extension of existing sources
- Improved (internal) efficiency
My interpretation of “new asset classes” is that via APIs existing assets can be extended, enriched, or mashed up with others to create innovation, new products or services, which subsequently can be regarded as a new asset class serving as input downstream of the value chain.
The “third parties” or the consumers of APIs are developers. This is where the application programming experience (APX) and more specifically developer experience (DX) become relevant. In fact, I believe an outstanding APX is crucial in the value chain of the API economy and will determine the successful players in this economy. Several companies recognised that trend and positioned themselves between the producers and consumers to provide API management solutions (or API Gateways).
With the above definition and discussion we should now have a good frame of the API economy. Why is that useful?
A definition helps to make clear what people mean by a specific term describing a concept. This is the necessary basis for creating and extending the body of knowledge around that concept. It also helps to identify the core elements and relations between these and understand the dynamics. This is useful for existing players in that economy but also for new entrants to be successful.
There is a lot of space and opportunity for success. The API economy is horizontal and could span various different industries. The potential of APIs could be enormous.
The McKinsey Global Institute identified 12 technologies as “advances that will transform life, business, and the global economy” in their report on “Disruptive Technologies.” I can see APIs beneficially leveraged in all of these. The most promising with the largest potential economic impact are also the ones that are already intensively discussed in combination with APIs. These technologies are:
- Mobile Internet: Estimated direct economic impact per year in 2025: $3.7 trillion (up to $10.8)
- Cloud technology: Estimated direct economic impact per year in 2025: $1.7 trillion (up to $6.2)
- Internet of Things (IoT): Estimated direct economic impact per year in 2025: $2.7 trillion (up to $6.2)
To put this into perspective the lower bound of these three technologies combined are $8.1 trillion; the upper bound corresponds to $23.2 trillion. The GDP of the whole European Union in 2012 was about $16.5 trillion; the whole world’s GDP was about $72 trillion. Cisco claims that driven by IoT (Cisco refers to it as Internet of Everything) the global net profit “up for grabs” should be $14.4 trillion between 2013 and 2022.
The graph below is from the McKinsey report and relates the media attention versus the potential economic impact of the identified 12 disruptive technologies.
Source: McKinsey Global Institute: “Disruptive technologies” report, page 18.
The power of software is being recognised in almost all business sectors and the benefit for technology and process improvement is highly visible. APIs are the next evolutionary step. The concept of exposing (internal) assets via APIs is so powerful and with recent technological advances getting simpler at the same time. The API economy which subsumes this concept has the potential to horizontally span many business sectors and hence, its economic impact can be substantial.
In this post I summarised my thoughts about the definition of this API economy because I think it is useful for existing players and newcomers alike to understand and exploit the elements, relations and dynamics.
Optimistic estimates claim that the API economy has the potential of contributing to an accumulated $23.2 trillion economic impact based on the technological areas of mobile Internet, Cloud technology, and IoT.
Explanation of the “API Economy Scale” illustration
An economy consists of a collection of markets which are defined by demand and supply, i.e. the power of consumers and producers. Because the API economy is so new these forces are not yet clearly defined. Also the type of competition – a range from monopoly to perfect competition according to economics theory – has not yet emerged.
Currently the players in the API economy engage in market development activities. So, the dynamics of the market and the forces are not yet determined, hence it is not clear what to put on the trays of the scale. For now, it is fair to say that the potential value of exposable assets clearly outweighs the current awareness. That’s why market development to educate the market is necessary. The content of the trays will change. Also the orientation of the scale will shift probably a couple of times with at least some temporary equilibrium phases.
Thursday, January 23, 2014
Application Programming eXperience: It’s all about *X
We all know user experience (UX) and understand the importance of it. Developer experience (DX) is fairly established by now, too. With the emergence of open APIs, a further X joins the party, which needs to be taken care of: APX (=application programming experience).
APX – Application Programming eXperience
There are two dimensions of APX as illustrated in the figure below.
The first dimension of APX is the experience an API management solution delivers to the asset holder (e.g., Expedia’s assets are their travel services). That is, for instance, how easy it is to encapsulate and describe assets as an API and then expose it. The API operations donut is relevant in that context (see the API operations and donuts post) but also industry initiatives such as the RESTful API modelling language (RAML) or API Commons. There are several suppliers of out-of-the box API management solutions (aka API gateways).
The second dimension is the APX that the exposed API eventually delivers to the developer. This dimension is strongly related to developer experience (DX). Also the slowstarters recognise the currently occurring power shift in favour of developers. At the end of the day it is developers who are the missing link between an asset provider and the consumer at the other end of the chain. Developers add value by adopting APIs and bringing products to market facilitating a potentially large scaling through network effects. Hence, it is not enough to “just” expose APIs; there needs to be an API strategy around it that is in line with and contributes to the overall business strategy. A great developer program is a hygiene factor as part of an API strategy.
What is a great developer program?
A great developer program has two underlying principles: First, design a product (e.g., API) that provides a clear value to developers and addresses a clear pain or gain. This can be monetary value but also others such as a way to increase reach, brand awareness, customer base, indirect sales, reputation for the developer or the pure joy of using great technology that works.
Second, the product needs to be very easily accessible. That refers to things like having a very lightweight registration mechanism (or none at all), access to testing features, great documentation, and a lot of free and tidy source code.
Pamela Fox established a useful guideline for producing a great developer program. Next to aspects like providing clear value and sign-up recommendations, she also covers how to help developers getting started quickly. A good measure for that is the TTFHW (=time to first hello world). She also talks about how to steepen the learning curve of developers adopting APIs. This is achieved through excellent API design quality in the first place – the better the design the less documentation is necessary – but also supplementary content such as getting started guides, API reference documentation, source code, and API consoles for testing. Ideally that should be sufficient for self-serving developer portals. Support is the final recommendation and must be appropriate. The better the product and documentation the less support is required. There are many best practices such as FAQ, email or chat (which are high maintenance), or a forum. The more vibrant a developer community around a product the more the forum will flourish and developers will help each other to a large extent.
The challenge: API discovery
A core challenge in the API economy for an asset provider will be how to make the API discoverable – especially in light of the increasing number of published and often similar APIs. Directories help but are currently only human readable. Strongly related to this challenge is API description. Formal languages or standards are slowly emerging but far from being mainstream.
One approach is RESTdesc which postulates the use of ontologies and semantic technologies to describe APIs. The languages and tools are quite complex though and do not yet offer mature and simple to use tools. Semantic technologies is a huge topic and I am sure there is some value in it for describing APIs; it has not yet have been made very clear, though.
Another way to increase API discoverability is via aggregators. 3Scale describe the trend that more and more aggregators emerge as “middle layer initiatives that combine APIs in a specific segment into a single addressable uniform API.” This should lead to a better structure of the API space and less “points of interaction” are necessary for a developer to liaise with.
These aspects – API description, discovery, and aggregation – play a part in APX.
The API economy is here to stay and, in fact, expected to grow rapidly. Developers are the enablers. Competition for developers will increase. To woo the best developers helping an asset provider to achieve the objectives, APX is key.
Both dimenstions of APX needs to be right and outstanding DX needs to be delivered. The design of the API strategy needs to start with the developer in mind; that is developers must not be regarded as just another resource.
Tuesday, January 7, 2014
API operations and donuts
API operations really is about making sure that API’s are accessible and deliver according to developers’ expectations. As such it has two functions: internally the processes need to be streamlined and efficient to reduce cost; externally API operations need to be effective in meeting developers’ expectations. Or in the words of the authors of the “APIs — A Strategy Guide” book, it’s about “making sure that users of the API have a positive experience and are happy with the API’s performance. This positive experience will ultimately carry on to your end users, generating greater value to your business.” In this post, I would like to summarise some considerations relevant for managing API operations.
What the operations text books say
In the Operations Management book (2007) the authors Slack, Chambers and Johnston argue that there are three main functions in an organisation:
- Research & Development to create new and modify existing products.
- Marketing (including Sales) to bring the right products to the right customers in the right way.
- Operations to constantly deliver the products as expected by the customers.
Slack et al define operations management as:
The activities, decisions and responsibilities of managing the production and delivery of products and services.
Generally there are five accepted key performance objectives along which operations can be managed. This is a model that should help to improve efficiency and effectiveness and align the operations strategy to the overall business strategy. These objectives are:
The figure below is an illustration used in the Slack et al book – also referred to as the donut model. The inner circle shows the organisation internal effects; the blue ring holds the five performance objectives and everything outside of that embodies the external effects (to customers or any other external stakeholders).
Source: Operations Management book (2007) by Slack, Chambers and Johnston
This is a general operations management model and can be applied to any operations aspect of an organisation regardless if it delivers a product or a service or which industry it serves. The metrics and means will surely differ, but the concept stays the same.
The role of an operations strategy is to understand the dependencies between the five performance objectives based on the organisations specific context (type of products or services, markets, customers, competitors etc.), to prioritize objectives in line with the business strategy and to define metrics and means accordingly.
The operations donut and APIs
The operations donut model with the same performance objectives can be applied to API operations, too. The donut can be used to define operations tactics to achieve an organisation’s API strategy (see also my earlier post about Leveraging APIs as Part of Digital Strategy). I re-created Slack et al’s donut illustration with API specific means. The inner circle remains a representation of organisation internal activities and effects; same is true for everything outside of the ring as external effects. I changed the arrows in the inner circle to indicate means an organisation can deploy to achieve the various performance objectives.
Let’s have a look at all the five objectives in turn:
Dependability is the actual availability of the API to developers. A useful metric is the downtime, which should be as minimal as possible (relative to a developer’s expectations). An organisation can achieve that by means such as redundancy or spike arresting. Another metric is a quota (with rate limits as internal means) which defines how many API calls can be made by a developer within a certain time frame. A quota protects an API and makes its management more predictable. Also – or more importantly – many API providers’ business models (and price plans) are based on quotas.
Flexibility relates to the options developers have in adopting APIs. This could be manifested in technical options – e.g., different supported protocols (REST, SOAP), different formats (JSON, XML), different tools (various SDKs for popular platforms such as Android, iOS, Web, Windows etc.) – or business options – e.g., the possibility or simplicity of changing between price plans or cancellation. In almost every case, flexibility can be found in releasing API and whether the various releases are compatible between each other and how much effort is required by the developer for adopting new versions or achieve a smooth transition. The internal means is version control and versioning. It should be clear that in general, the more flexibility that is provided the more efforts (and cost) the organisation needs to bear internally.
Quality is the consistent conformance to developers’ expectation and, hence, influences their satisfaction. As such quality is an overarching performance objective which is related to the four other objectives. Conforming to expectations can be achieved by defining and meeting SLAs. Streamlined and purposeful automated processes can improve internal efficiency and contribute positively to quality (and cost reduction).
A specific case related to quality (and expectations) is how an organisation interacts with developers. That is subsumed under the term Developer Experience (DX) and contains means such as developer portals, documentation, tools, testing, support or evangelists (see also my post Developer Experience — because developers are people too).
One important aspect related to the speed objective in API operations is access latency (i.e., the time that elapses between an API call and the receipt of the response). Latency is related to the throughput aspect (i.e., how much communication can be successfully executed). Both latency and throughput are important for a developer and can internally be influenced by means such as throttling or caching. Throttling in particular (like quotas) can also be used for defining an API providers’ business models on top of the APIs. The speed objective is also influenced by the dependability objective’s means of rate limits.
The cost objective is to provide the best value-for-money relation to developers. Internally that means to optimize costs wherever possible without hampering the experience (i.e., perceived value and quality) of customers. Depending on context and implementation, all the other four performance objectives contribute to the cost objective either direct or indirect proportionally.
A special case: developer on-boarding
A special case in API operations is the developer on-boarding phase, which subsumes the process of identifying, targeting, and (hopefully) convincing developers to sign up to an organisation’s API program (i.e., developer marketing). It is thus recommended to differentiate between this phase and the active API usage by developers after on-boarding, which is essentially the donut as I described above. Depending how important and elaborate an organisations developer marketing activity is, it makes sense to construct a separate donut with prioritized performance objectives, metrics and corresponding means. The on-boarding donut depends strongly on the specific context of an organisation. The dependability objective could be about the availability of an online registration and admin portal for a developer. Flexibility could mean whether an organisation provides different variants of developer outreach means targeting different developer segments. With respect to quality, also in the on-boarding phase an organisation should live up to the developers’ expectations. Otherwise developers would not be won over in the first place. Speed is related to how quickly a developer can use an API. A related metric is “time to first API call.” Finally, cost is influenced by all other objectives and should be optimized as much as possible.
A meaningful way of implementing API operations is by using an API gateway, which could encapsulate most of the necessary functions and processes (i.e., the internal means depicted in the inner circle of the donut). It is an elegant way of separation of concerns from an organisation’s backend servers into dedicated entities. In addition to the means of the API operations donut (e.g., rate limiting, spike arresting, versioning, automation, DX, caching or throttling), an API gateway can perform tasks related to mapping or translating between technologies and formats, aggregating or splitting up API calls, or handle security. API gateways could be hosted on premise or in the cloud.
API operations is all about delivering an API product to developers and as such needs to satisfy the potential value established by R&D and the promise communicated by marketing. The operations management donut is a useful model to break an API operations tactic up into the five distinct but interdependent performance objectives: dependability, flexibility, quality, speed, and cost.
The selected metrics and means are dependent on an organisations specific context and in line with the API and business strategy. It makes sense to break API operations up into various phases – such as developer on-boarding and active API usage. API gateways (hosted on premise or in the cloud) are a meaningful way to implement API operations as it allows a better separation of concerns and thus increases manageability and maintainability.
Monday, December 30, 2013
API Magazine Newsletter (Dec.’13): About APIs and Developer Evangelists
The December 2013 edition of the API Magazine Newsletter just went out. It features topics including:
- Leveraging APIs as part of digital strategy (on wired.com)
- Preview of the API Strategy and Practice conference (March 26-28, Amsterdam)
- The new RESTful Web APIs book
- A video of John Musser talking about “Great APIs”
- Vision Mobile’s Enterprise App Developer Atlas
- Some market predictions
- And many more…
Friday, December 20, 2013
Leveraging APIs as Part of Digital Strategy
Content of the post
- A definition of API economy (by Cutter Consortium).
- The three types of API benefits with some case study examples.
- An overview of the purpose and theory of strategy related to APIs.
- The relation between business, digital, and API strategy.
- A discussion of internal and external view of strategy (including VRIN and Five Forces).
- The influence of these views on tactics for strategy execution.
- A list and descriptin of API related tactics.
- My view on the discussion whether APIs are a strategy in their own right or if they are only tactics (triggered by Daniel Jacobson’s article).
I used the below image to illustrate these thoughts.
My conclusion in this post
It is clear that the future moves towards more and more digital business and things get more and more connected. A huge potential is seen in the Internet of Things vision. I believe one important element for this vision to happen that is not yet entirely clear, is to understand how services and applications — not only computer, things and people — can be connected in a “smoother” way.
The current trends in APIs and the emergence of the API economy seem to embody steps in the right direction. Modern organizations need to seriously think about digital and API strategies in line with the overarching business objectives (considering the internal and external view) and execute accordingly. Digital is and will be even more the key channel to reach customers. APIs are the enablers.
Tuesday, December 3, 2013
Reblogged: Why We Chose API First Development
I like this post as it is a great experience report about an API-first development provided by POP.co. They highlight the benefits how they saw it as:
- Separation of concerns
- Developer liberation
- and some more…
At POP, our site is entirely API driven. We separated our frontend codebase from our backend API in it’s entirety. The two sites are even in separate repositories. There are several reasons we decided to use this architecture which I’ll cover below.