On Friday I swung by The Business of API's Conference at The Guardian's offices near King Cross station in London. Unfortunately some fires were burning back at the office which mean't that I couldn't stay for the entire event, however I caught the first three speakers and Q&A so here are my notes / thoughts from the first half of the afternoon... First up was Oren Michels, CEO of the event organisers Mashery. Oren took the crowd of about 40 through a whistle stop tour of "A complete history of API's (abridged)". Oren initially spent some time exploring the conceptual business concepts behind API's like opening up your company, and embracing collaborative working with partners. The first case study was a delve back into business history, looking at US retailer Sears, and how they embraced an expansion opportunity by partnering with logistic's companies & manufacturers to launch their mail order catalogue business. Moving into the pure play online world, eBay was singled out as an early pioneer in the field. Very early on the management team realised they were great at handling transactions, had developed a trust system based on ratings and feedback, but they were lousy at starting and running the auctions. They began to increasingly expose their internal building blocks to allow 3rd parties to offer a variety of complementary products to assist with the creation and management of eBay auctions. This ecosystem grew organically, until eBay's officially began developer marketing in 2004. The next important  innovation, after the exposure of previously hidden internal capabilities, was taking one of these capabilities and mixing it together with a capability from another company to create a new service, giving birth to the "mash-up". An early example of an API mash-up was 2005's housingmaps.com. The creator, Paul Rademacher, took real estate data from craigslist and combined it with Google Maps to plot properties for sale on a map. Rademacher achieved this before Google had actually exposed an official mapping API by reverse engineering their code, ultimately earning him a job at Google! Oren than described the common components or layers of an application:

1. Data (e.g. photo's, video, user information)
2. Logic (The things that happen & how the data is processed e.g. searching, buying, adding)
3. Presentation (The user interface e.g. the web site or mobile app)

By adding an API layer your company can expose the data layer to encourage 3rd party innovation and mash-up's. Oren made the point that a great app doesn't have to do everything. It should be simple and focused, "granting wishes". A great example of this keep it simple mantra is The Guardian's Eye Witness app, where The Guardian can "re-use" existing photo content to create a compelling new service offer. Oren closed by touching on the cookery analogy of API's. Historically companies have wanted to create new products behind locked doors. Now companies should think about API's as ingredients. No longer do companies have to control the end to end creation process (the ingredients, recipe, creation, and the baking). Just put your ingredients out there and see what other people can create with them. I've used this analogy a numbers of times inside my company. Once you can get your head around the concept, it is immemesily liberating for anyone that has been in charge of product development inside a large organisation. The internal pressures of resource & capex scarcity, risk aversion, process complexity, time to market, and the weight of creative expectation suddenly disappear. Like the example of the individual app, the focus for modern Corporate product development should be to analyse the core capabilities of your company and expose them in a secure and scalable way. If you can wrap those capabilities in an attractive business model, then you can tap into the hundreds of thousands of developers out there who will invent imagative ways to utilise and monitise those capabilities for you. A recent blog post by Alan Quayle notes that Google and Facebook now have 5 billion API calls a day. Twitter has 3 billion calls a day, which amounts to 75% of its traffic. The second speaker was Sam Lowe from Capgemini. Sam spoke about the use of API's in their Enterprise customers, naming it "3rd generation eBusiness" Sam set the context for enterprises - they are "under siege". They are having to figure out how they adapt to changing customer behaviour (e.g. Facebook), disruptive innovation (internet models rather than enterprise IT models), and new business opportunities (pure play online). The Enterprise generations of eBusiness were defined by Sam as: 1.0 - Initially getting online to match early pure play etailers like Amazon & eBay. 2.0 - Developing the online channel for transactions, customer self care, plus seamless multi channel experiences like online order & reserve with physical in store order collection 3.0 - Opening up and becoming inter-dependant on other organisations. Taking your services to where customers already are. In this 3.0 phase web sites can now automatically interact with each other to create new service bundles or offers in real time. Sam cited Dell's Idea Storm as an example of an Enterprise opening up both technically and philosophically to improve it's products and services, along side Apple's Developer Community, and O2 Uk's GiffGaff virtual mobile network brand where the GiffGaff community is incentivised via service credits to provide customer support to each other. API's represent a more cost effective and flexible solution vs. traditional IT integration, and can be used as a foundation to create ecosystems or platforms to generate new business opportunities that didn't previously exist in the old world closed model. These platforms allow other (external) people to create services that the Enterprise would have either never thought of, or backed. The API model seems to be well established; Programmable Web's API directory now lists nearly 2,200 individual API's, including API's from companies you may not expect to be playing in this space like Tesco. Expanding your companies relationships and connections via API's and mash-up's creates new business opportunity, as per Metcalfe's Law. [caption id="" align="alignleft" width="200" caption="Metcalf's Law - Network Effect. Image from Wikipedia.org"] [/caption] Sam touched on the challenges facing Enterprises looking to invest in creating API's, including how to pay, security, operational support, and dependencies on others. It would have been nice to get some deeper insight into the business case challenges. By definition, because your organisation is dependant on the creativity of others to develop new services by using your API, it is almost impossible to predict the return on investment for an API. It can become a science vs. religion debate. To help the business case debate the "eating your own dog food" or the more polite "drinking your own champagne" argument can be made. As well as exposing these API's for external developers, many companies also use the same API's to power their own internal services. This delivers a much more efficient and flexible reuse approach vs. traditional stove piped Enterprise IT delivery projects. During the Q&A session the GiffGaff case study was mentioned again, leading to a discussion on how "power users" are willing to offer their personal time to create and maintain online communities based around the products and brands they love. The conference moderator, Quentin Hardy, National Editor, Forbes threw in an interesting stat; In the USA 40,000 people spend 4 hours a week posting on company forums. The final speaker I caught was Emer Coleman from the Greater London Authority. Emer acts as an advocate for the London Datastore which is focused on opening up various public sector data in the London area via API's. Examples of the data in action are the live tube train map on TFL and a feed for the new London cycle hire service is next on the list. Other examples were Oyster card outlets, council tax bands, and they are looking into crime maps but of course that kind of data presents a number of privacy and social issues. Emer gave some interesting insights into the speed of development using their API's, with apps now being created in "an afternoon" vs. the traditional public sector procurement process which is measured in months & years. I'm sure many of us in the private sector can relate to that as well! Also interesting was the challenge around working with more sensitive data, like crime statistics. Perhaps an unforeseen benefit of opening up access to the data via API's, was that teenagers who would never visit an official government website, are now exposed and interacting with the same government data via brands they are willing to associate with. With heavy public sector spending cuts looming, I asked the question if this would lead to a national roll out, but there didn't seem to be a strategic plan. Surely allowing 3rd party developers to create compelling public services from this data would allow the government to innovate and improve services for citizens at the fraction of the cost....? Anyone interested in learning more about API's has to watch this video:

Darwin's Finches, 20th Century Business, and APIs: Evolve your Business Model from Apigee on Vimeo.