Monday, April 14, 2014
The API Magazine supports the largest developer survey by VisionMobile
With my API Magazine I am supporting the 7th global Developer Economics study surveying over 7,000 mobile app developers. This study is conducted by VisionMobile – the leading research company in the app economy and mobile business models.
VisionMobile produces very valuable insights into developer attitudes, trends, platform mindshare, tools and monetization opportunities. I find their work and insight extremely useful and regularly refer to it. Many mobile industry players and experts use that resource constantly, too.
And that is why I support their work.
So, if you are a developer, have your say and complete the survey.
It takes less than 10 minutes. The resulting report is free, usually around 50 pages and participants will get a notification when it is ready for download.
In addition, respondents can win great prizes, including:
- An iPhone 5s
- A Galaxy S5
- A Lumia 930
- A Blackberry Z30
And a lot more!
More about the resulting Developer Economics report
The Developer Economics report is the de-facto research on the app economy and developer ecosystems by VisionMobile, based on the largest, most global developer surveys. The Developer Economics survey is conducted twice a year, tracking platform Mindshare, monetisation by platform and revenue models, use of tools and investigating opportunities and challenges in mobile development today.
This 10-minute survey is aimed at app developers. Survey respondents can enter a draw to claim great prizes, such as latest handsets and cool gadgets. Each of the respondents can also claim a free, 1-month subscription to Bugsense’s crash reporting tool.
As always, the survey results will become publicly available as a free download - so that respondents can get a sense of what the latest trends are and what other developers have to say.
Tuesday, April 8, 2014
API Magazine covers APIDays Berlin
The APIDays are a global tour covering six cities: Barcelona, Berlin, Moscow, Paris, San Francisco and Tokyo. APIDays is also vendor-independent and genuinely wants to drive to API space forward and covers a wide range of topics such as scalability, versioning, developer experience, testing, mobile, security or business models. For a complete overview of the agenda see here.
For the Berlin edition already 50 speakers in three tracks have confirmed and over 250 attendees are expected.
APIDays Berlin is solely focused on the builders of the web. The goal is to provide a great learning experience and an open forum to bring together the finest minds in the API space and foster dialogue.
I will organise and hold a workshop at APIDays about the elements of an effective developer program. I will invite some experts to present and discuss this topics. My objective is to highlight the importance of developers in the API value chain and also to inform about how to build a successful developer program.
I will provide more details about this workshop and the speakers soon.
You can sign up and get a ticket for APIDays Berlin here.
Below you can find a selection of the currently confirmed speakers.
Tuesday, April 1, 2014
API Magazine Newsletter (March’14): About APIs and Developer Evangelists
The March 2014 edition of the API Magazine Newsletter just went out. This edition featured topics including:
- My summary and key take-aways from the API Strategy and Practice (APIStrat) conference in Amsterdam and another coverage by ProgrammableWeb
- Several hijacked Maslow pyramids
- An elaboration of the building blocks of API management by the API Evangelist himself
- Mike Amundsen’s keynote from APIStrat
- Several videos of excellent keynote talks — including one about the husbandry of developer evangelism
- A tutorial about Grape on Ruby to expose REST APIs
- Top-10 IoT concerns
- A discussion about APIs vs SDKs
- And many more…
Monday, March 31, 2014
Impressions and take-aways from API Strategy and Practice conference
3scale.net and the API Evangelist organised the API Strategy and Practice (APIStrat) conference in Amsterdam on March 26 – 28, 2014. It was a great, vendor-independent event in the Beurs van Berlage building at the heart of Amsterdam. APIStrat was really nicely balanced between technical, strategic and business aspects. In this post, I would like to summarise my personal impressions and take-aways:
The theme of the conference was “scaling in the API economy.” This theme did not prevail in every session but it was discussed in various parts. It basically, as also highlighted by Mike Amundsen, comes back to an older idea. The idea of scale free networks – and the idea of building APIs nodes rather than API hubs.
Mike also gave a fascinating keynote talk in which he raised scalability concerns considering the billions of connected devices in the future. Developing programs as we do at the moment may reach its limits for this. Hence, Mike essentially suggests an approach by using rules. The way he conveyed that in his talk was very unique and inspiring by referring to the works of John von Neuman, John Convay, and Theo Jansen. Find the details of his talk (including slides and videos) here: “Self-Replication, Strandbeest, and the Game of Life.” Two ideas I take away from that are, first, the best bug-free code is no code and, second, the next big thing is small.
There was one session about developer marketing, which is a topic I personally find crucial and is currently a bit underrepresented at API conferences. The developers are an essential element in the API value chain who eventually bring the assets exposed via an API to the end consumers. Hence, I totally agreed with Ricky Robinett, Developer Evangelist at Twilio, who introduced the analogy of “being Alfred.” That means as developer evangelists we are serving developers just as Alfred Batman’s butler served Batman. Andreas Krohn did a probing talk entitled “I hate developers” – with which he basically criticized the fact that in the API outreach too much focus is on developers and other stakeholders (e.g., budget holders who are often not the developers) are not targeted. Finally, another key message was that although hackathons are currently trending they are not the answer for everything.
Mehdi Medjaoui in his keynote encouraged to start defining open APIs. He phrases that as the leap of faith (with a nice analogy to the Indiana Jones movie). He claims scaling in the API economy will only work if there is an open API standard. A first draft of a manifesto subsuming nine principles for open APIs are published on Github. Mehdi also referred to the API Commons as a good basis.
There were especially two interesting talks about API descriptions. Ruben Verborgh raised the problem that hypermedia is not sufficient. It could work for describing a single API, but since we are not aiming for API silos on the long run but for Web scale, and because we cannot predict all possible client functionality a priori, we need other mechanisms. One possibility is to use hypermedia-based self-description for responses and the API itself. Here is the video of Ruben’s talk. Another talk that covered hypermedia-based descriptions was delivered by Markus Lanthaler who presented Hydra, which is an approach to describe hypermedia-driven Web APIs. Hydra is based on JSON-LD and the Hydra Vocabulary.
John Sheehan talked about the increase of APIs that are integrated in apps or services and the challenges that arise from that. Another aspect he covered was the benefit or drawback of SDKs to wrap APIs, which was also recently discussed by Holger Reinhardt in his blog post. I have a different view as I do not believe there is a default answer as to whether SDKs are good or bad. In principle SDKs do lower the access barrier and make API adoption easier. But it always depends on the context of an API provider (technologies and platform supported, rate of change, served developer communities etc). You can find John’s slides here.
The keynote by Twitter developer evangelist Romain Huet was a spectacular experience in itself. After a couple of figures and use cases of the Twitter API (e.g., predicting elections), Romain combined the Twitter API with a camera on the Raspberry Pi (BTW, every attendee got a Pi in the swag bag) and triggered a photo with a tweet. Not enough with that, he then let a drone fly with a tweet. Actually everyone in the audience was then invited to tweet to the drone. But watch Romain’s keynote for yourself.
There was a great panel discussion on the role of Enterprise APIs. This is very thoroughly covered by Mark Boyd in his post “4 Ways APIs Are Being Talked About in the Enterprise” on ProgrammableWeb.
Bruno Pedro's talk was a personal highlight for me, too. He stated that the API economy is still “the wild west, where anything can happen.” In order to counteract he gave a lot of practical advice. He mentioned his personal API tool chain, of which the Postman is an essential element. I have not come across this tool but it seems very useful when it comes to testing web APIs, composing requests, analysing responses, and also allows exports.
Some of the features of Postman seem to overlap with the APITools which were launched at APIStrat too. APITools provide a developer an overview over the used APIs, the ability to monitor the APIs’ performance and to react if something is wrong, 3rd party APIs can be debugged and tested, and it creates a Swagger-based documentation of the used APIs. Developers can also inject a caching mechanism to change requests and responses.
Finally, I also found the presentation by Anselme Jalon from FABERNOVEL about API business models very interesting – especially the four Japanese case studies: Seven&i, Omron, Cookpad, and Fujitsu. Vision Mobile's Michael Vakulenko presented what developers really want, the developer pyramid of needs, and their segmentation model (see also this blog post for more). Finally, I liked the talk and demo about the possibilities with WebRTC by Apidaze.
In conclusion, a lot of people from the API community were present and it is simply very enjoyable to finally meet the experts in person. APIStrat is clearly not about products and pitches. It is neutral and as such tries to genuinely drive the API space forward and contribute to the body of knowledge through dialog. This is great.
Here is a link to two more detailed write-up by ProgrammableWeb's Mark Boyd: “Day One at API Strategy & Practice: A Whole New Paradigm” and “API Strategy and Practice Day Two: The Values Behind an API-enabled Sharing Economy.”
Wednesday, March 19, 2014
What motivates us in a job?
Dan and his team set up three experiments to find out what drives people and what makes them feel good about what they do – in short, what motivates us. Is it really about the money and bonuses?
The first experiment was about building Lego robots. The goal was to examine two conditions: the meaningful and the sisyphic condition. In both conditions the participants were paid cash but in the “meaningful” case the people performed much better. That shows the importance of experiencing progress in a tasks versus doing a tasks cyclically without seeing a clear value (meaning) in it.
In the second experiment, participants were asked to identify and highlight pairs of letters on a printed sheet of paper. When handing in the work, the participants experienced three different types of reactions: acknowledgement, ignorance, and the total destroying of their work in front of their eyes. As you would expect, acknowledgement is the strongest motivator. Interestingly, plain ignorance has a similar effect than brutal destroying of one’s work. Dan Ariely also found out that it is fairly simple to acknowledge: simply showing interest is often enough.
The third experiment was about building Origami with instructions. After building an Origami the participants were offered to buy the product they just built. People were willing to pay 5x more for their own product than people who did not build any of these Origami. Dan Ariely also found out that the harder the task, the more valuable the final product is perceived by its creator. This is also referred to as the “Ikea Effect.” Most furniture you can buy at Ikea you have to assemble yourself. Because of that you feel stronger connected to the furniture eventually.
The video made me think and I would like to summarise my personal take-aways:
I believe purely the love of a craft (eg, programming) is not enough. People like to play Lego, but if there is no real meaning behind building something, the pure act of building does not give joy and satisfaction on the long run.
The purpose or meaning in doing something is essential for long-term motivation. It is probably ok sometimes to do something without clearly understanding why you have to do it. But for good, sustainable performance understanding the purpose of why I am doing this tasks is essential.
Feeling challenged is very important. The bigger the task, the bigger to opportunity for great results and, hence, intrinsic motivation can be higher.
The sense of progress and completion eventually is another critical element for motivation. It is important for people to get this feeling to work towards something. Even if there is no actual completion – at least a certain kind of ending ritual should be defined.
If there is clear ownership (skin in the game) of a certain part or task, people feel a much stronger connection and identify themselves more with that particular part or task, which leads to increased performance.
Acknowledgement of performance is crucial and, in fact, can be achieved in a very simple way with very effective consequences.
Finally, having the necessary freedom in deploying one’s own creativity as one sees fit is another important element which makes us feel good about our work.
I see these take-aways bi-directionally: These are what I would expect from a job environment for me to be motivated – but at the same time these are what I want to contribute back to the environment (peers, direct reports, and managers).
A final thought that I found really interesting too, is when Dan Ariely compared the ideas of Adam Smith and Karl Marx.
In the Industrial Age, it was all about efficiency. It is still about efficiency but in the Industrial Age, this was primarily concerned with physical efficiency. Smith for that time was certainly more right with suggesting to break up a production line into its individual tasks. However, there is a rethinking necessary about how we approach efficiency and motivation since we moved into a society that now has a lot more “knowledge workers” as defined by Peter Drucker. Now, Karl Marx may actually have a very strong point with focusing on “meaning” of our work. In his theory he called it the “alienation of the worker from working” (=Entfremdung) by breaking the whole down into individual tasks, which takes away from workers the chance of fully identifying oneself with a product. There are a lot of parallels to what Dan Ariely found out in his experiments.
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.