Last month I wrote a post questioning why, in the context of exponential growth in the number of companies creating APIs across many sectors, so few publishers were opening up their data and content (at least in part) in this way. The question is applicable to just about every area of publishing that is making the transition from legacy print processes, practices and approaches to those more associated with digital.
Gregg Alpert, who is Developer Relations Manager at Pearson, left a comment on the post mentioning the development of the Pearson APIs and how they had generated some innovative applications, more experimentation and some tangible excitement within the business. I was curious to know more about the experience of developing APIs within a large organisation, and Gregg generously agreed to do a hangout to answer some of the questions I had. His observations were insightful so I decided to pick out some of the key points here.
Pearson started with three APIs - FT Press, Longman Dictionary, and DK Eyewitness Guides, each of which has led to a number of new projects via thrid party developers. In fact the importance of not just opening up an API but also of focusing on developer relations is something which has been critical to the ongoing success of the process. Gregg talked about how an externally-facing focus toward the developer community enabled them to raise awareness and generate excitement around the potential of the content that was available. Attending and running hackathons has really helped this. Feedback from developers also helped with the prioritisation of APIs since some content turned out to be in notably higher demand (in their case much of their educational content), which in turn was fed back to the business.
Senior level advocates have been pretty critical to building and maintaining the momentum around data projects but once up and running, proof points and success stories were used to highlight benefits to other divisions (which speaks to the value of totems within businesses in driving change). They had some early successes and some neat apps worth shouting about. Maptouria (pictured above - a mashup using the DK Eyewitness Travel Guide, Yelp, and Google Street View Image APIs) allows travellers to find points of interest, information about tourist attractions, restaurant reviews and so on in one place. AngelCook(pictured below) uses the Pearson Kitchen Manager API to create a personalized cookbook where you can enter the ingredients you happen to have available and see a list of relevant recipes. As a result of developer interest the programme has continued to expand so that there are now eight APIs including one for Penguin Classics.
The interesting thing about what Gregg was saying I think, is around the value of APIs not only in terms of fresh thinking and pace of innovation, but also around the impact on organisational culture and approaches. He mentioned that they had progressed from having to convince people in the business of the benefits of providing APIs to a point where many business units were pro-actively coming to them. That's a good position to be in, and a great example of how APIs can be a catalyst for productive change, something publishers of all kinds are attempting to achieve.
My thanks to Gregg for his time and insight.
Neil, thanks a lot for taking the time to learn more about Pearson's efforts to create an API program. It was good talking with you! I look forward to your continued coverage of the evolving digital landscape.
Posted by: Gregg Alpert | January 14, 2013 at 05:10 PM