APIs as business assets. "A big truck" or a "series of tubes"?

Everyday there is more written and presented about what makes a good API.

In recent years, much discussion related to APIs has focused on architectural approach (e.g., SOAP-based web services vs. RESTful ones) or even how a specific approach (like REST) is best applied. Beyond all the blog-blather about APIs (this post included among the blather), there also is an increasing number of market metrics as to the type of APIs, as well as the particular APIs, that are gaining the most adoption.

Some of the metrics come from the API publishers themselves. For example, a key data point frequently cited with regard to Amazon web services (offered in both SOAP and RESTful configurations) is that 20 percent of the usage is SOAP, while 80 percent is REST. There also are a few independent sources of information about API usage. SOA analyst and born-again cloud-computing evangelist David Lithicum highlighted in one of his recent podcasts the website Programmableweb.com, which provides a directory of, and community feedback on, more than 1,000 APIs.

What Makes a Good API?

I won't try to recreate the aforementioned blog blather about what makes a good API, but if you want to be spoon-fed a good, high-level introduction on this topic there really are few better sources than the webcast embedded below (also available here) by Joshua Bloch, a senior software engineer and architect at Google. This is a high-level review of technical design principles. I have a follow-up regarding one of Bloch's early statements in the webcast about API's as "business assets," which I'll get to below the embed.

API's as Business Assets

To borrow (and bend) a phrase from renowned Internet expert, Senator Ted Stevens (fmr. R-Alaska), let me say that an API is neither "a big truck," nor a "series of tubes." Most businesses develop APIs for reasons such as opening sales and partner distribution channels, increasing the visibility of their products or services, or providing higher levels of control, configuration, or collaboration with users. My only mincing of words in terms of Bloch's introduction to quality APIs, is with regard to his statement about API's as "business assets." In the context in which he makes the statement, it makes sense. I don't worry about how a tech audience would interpret this remark. It is my experience that the business side of the house -- e.g., product managers and business strategists -- are more likely to misunderstand APIs as assets than technologists.

The subtle distinction here is that any API has little or no intrinsic business value. The business value associated with an API is derived only from adoption of the API and, of course, how well the API (or any API, for that matter) is suited to the desired business outcome or goal. An elegantly written API can be a company's crucial link to customers, partners, and business growth or (back to my Ted Stevens reference) a tube to nowhere (or would it be a "big truck"?).

My point here is not to diminish well-architected APIs. Actually, it is quite the opposite. My experience is that the business side of the house sometimes gets too preoccupied with the tangible API and control over it, whereas the focus should be on what business results are desired and how to best position the API to be adopted by all stakeholders. Techies like Bloch obviously realize this, despite me seizing on his description of APIs as "assets". It worries me less when techies use such a description than individuals to whom "assets" are regarded as things to accumulate, control, and conserve, which is almost the exact opposite of what is necessary for APIs to flourish and deliver business value.

In the next post, I'll look at the relation between standards and APIs.