In the first installment in my ongoing series of mashups posts I looked at the word itself and why edge driven integration and user generated applications are a potentially a disruptive force inside the enterprise as well as else ware. For this post I want to start a discussion on APIs and their impact on business strategy.
I thought it would be helpful to go right to the central topic at the heart of the mashup meme because without them you don't have anything to mashup. APIs have been around for decades, first as proprietary interfaces that developers used to gain access to a server application, later evolving to what we have today, a broad range of public and secure programming interfaces that are being used to create new applications on top of popular services, build ecosystems around companies, and lastly they have a promise of creating a potential new distribution channel for application providers.
APIs obviously rely on two basic parties, a provider of the API and a third party who wishes to use the API. It's like a pitcher and a catcher, one without the other is of little utility. The challenge for everyone is that the "sell side" and the "buy side" have different motivations and requirements that often put them in conflict with each other. Let's start by taking a look at the API provider and the challenges and opportunities they face.
So you have a hosted service (although you can certainly do this with on premise as well) and want to encourage third party developers to build out applications on your service. The first question you should ask yourself is why you want to do this, and "because I can" is probably not the best reason for proceeding. Do you want to extend your application with vertical add-ons, or encourage alternative client applications, or distribute your app through third party channels, or just create some buzz. A lot of companies just want to create buzz so APIs are really more a part of a marketing strategy than a business strategy.
Let's assume you want your API to encourage third party developers to create new apps that extend the reach of your service. You publish a spiffy new REST API and blog about it and then nothing, which does happen a lot because developers don't always consider the incentives built into such schemes. What is in it for developers who do wish to take advantage of you API if the primary benefit is going to you as the provider of the core service?
If you are Salesforce.com the carrot is the customer base you hold, and the promise of lowered cost of sales for third parties who build apps on SFdC and then offer them through Appexchange. For SAP and Oracle the same applies although it's delivered not through online but direct sales means and Microsoft has their SMB channel. What if you don't have a big customer base? Well I guess you need another carrot.
Smaller companies can use APIs to deliver functional components to external developers not as a means to tap a customer base but on the hope of growing one. Xignite is a great example of this approach, their web services are used by external developers to augment their products with functionality that would be difficult to build organically. Need realtime currency conversion functions or a data feed with live precious metal pricing, Xignite has service components for you.
Most companies are somewhere in between Salesforce.com and Xignite, they have an application service that could benefit from having external developers build out functionality or integrate with other applications and the technical means to that end is an API offering and a developer program built around it.
Challenge #1: If you business is dependent upon driving visitor traffic to your website, as is the case with a lot of web 2.0 sites, how do you support your business with an API strategy when the end result is that users of that API may in fact never visit your site, thereby depriving your business model of necessary oxygen.
Challenge #2: Your customers are paying a subscription to access your service and you want third party developers to build out extensions. Is your expectation that your customers will pay you for the service AND the external developer for his/her application?
Challenge #3: There is no such thing as free in software, everything has a cost. Assuming #1 and #2 are not insurmountable, how do avoid becoming a victim of your own success? Even Google limits the number of API call an application can make in any given period of time.
Let's assume that you have a well thought out business strategy upon which you will offer your APIs, you have a customer base that will benefit as a result, and a pool of external developers ready to take those APIs and do goodness with them. What do you do now?
First thing you need to tackle is documentation because a great API that no developer can figure out isn't going to do you or anyone else much good. Google Code offers a great example of an integrated approach to API documentation and community, but even their services are spotty with regard to documentation. Google Maps is fantastic, Google Calendar's documentation leaves a lot to be desired, which is just one reason why you don't see a lot of Google Calendar integration. DabbleDB has a great help center and provides a good example of how a small company can invest in documentation for the benefit of external developers.
I'm going to write about security and identity in a future post so I'll skip over that important topic here, but one area that does deserve a mention here is performance. APIs that are unresponsive or slow do not instill confidence in your external developers that you are committed to helping them and they won't build out on them as a consequence. If you are going to invest the effort in developing an API strategy then invest in managing that investment by ensuring performance is acceptable.
How will you determine what functions to provide under the API? Google Calendar offers read, write, update, and delete functions for public and private calendars, while Google Notebook's API is limited to read operations on public notebooks. What is the process by which Google determines what to provide in their API? The reality for most companies is that it's up to the individuals behind the products and is often driven by their internal requirements as opposed to what developers are asking them for. How about thinking through and implementing a community process for evaluating API requests and communicating what will be coming?
At some point you will also need to consider how you will handle the delicate scenario that arises when you wish to build out functionality yourself that steps on an external effort undertaken on top of your APIs. Publish your product roadmap so that external developers have confidence that when they invest the time and effort into building out on your app they will enjoy some breathing space for the forseeable future. If you acquire a partner then acknowledge the obvious, you are now competing with your other partners in that space, as is the case with Salesforce's acquisition of Koral recently.
I hope this was helpful, and keep in mind that while I have used just a few companies as examples the fact is that there are thousands of APIs and hundreds of companies taking advantage of these strategies. There are many source for reliable information on API offerings, the one I would point to is ProgrammableWeb.
link to original post