Chief API Officer

Hackathons help you explain APIs to developers. But, do you know who you should be really selling the value of your APIs to? It goes way beyond the developers and IT operational folks. Who do you think it is ……CIO, CTO, CSO or someone else? You will be surprised. Read my article on ProgrammableWeb for more details.
http://blog.programmableweb.com/2013/03/11/is-the-cmo-now-the-chief-api-officer/

Watch out for my API strategy article series soon to be published.

Why are APIs so popular?

Kin Lane recently wrote a couple of blogs about why copyrighting an API is not common. I couldn’t agree more that copyrighting API is uncommon. First of all, the API definition is just an interface (It is the implementation detail that is important, and needs to be guarded), so it doesn’t make any sense to copyright an interface. (It is almost like copyrighting a pretty face 🙂 ). Secondly, the whole idea of exposing an API is you are looking for others to finish the work you started by just providing the plumbing work. Why would anyone want to get involved with a copyrighted API and finish your work for you?

Kin Lane says, “API copyright would prevent the reuse and remix of common or successful API patterns within a space. We are at a point where aggregating common, popular APIs into single, standardized interfaces is emerging as the next evolution in web and mobile app development.”

http://apivoice.com/2012/12/08/api-copyright-would-restrict-api-aggregation/index.php (to read his complete blog).

We have gone from the services aggregation concepts to mashups, and now I am seeing the newer trend of API aggregation.

Keep in mind APIs are generally offered by vendors who want to expose a specific functionality or platform. If you need cross platform, cross provider, cross functionality options, you need to have API aggregations. Remember during the services days how much of a hard time we used to have in integrating and aggregating services from different vendors? I know some companies are making a good living by just building aggregated APIs. 🙂

One of the common usage patterns I see time and again is customers use the strongest points from vendors of their choice. This was not possible when you were building services. You ended up buying one vendor stack, and you were limited what was offered by them, unless you custom built the weak parts by yourself.

Now imagine the power of what you are getting now. You are cherry picking the best of breed platforms, best of possible functionalities from multiple vendors of your choice and liking.