Organizations Must Provide Core Competence Through APIs (Axiom #4)

This is a joint post by Guest Author Craig Burton who writes at http://www.craigburton.com/ (craigburton) and 3scale’s Steven Willmott (njyx on twitter). The original axiom approach was dreamt up by Craig and we’ve iterated together since.

The Five Axioms of the API Economy

This blog post is the fourth in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first three Axiom posted (also see an intro to the series in the first Axiom). The five axioms we’re covering are as follows, in order:

1. Everything and everyone will be API enabled.
2. APIs are core to every cloud, social and mobile computing strategy.
3. APIs are an economic imperative.
4. Organizations must provide their core competence through APIs.
5. Organizations must consume core competences of others through APIs.

Axiom #4 addresses the issue of what should an organization choose to API-enable first and why.

Axiom #4: Organizations Must Provide Core Competence through APIs

The fourth axiom contains two core elements. When an Organization chooses to provide APIs:

• Those APIs should provide substantial value to their target audience.
• Those APIs should cover the Organization’s core competency.

In other words, an organization should provide APIs that some other individuals or organizations (customers, partners or the world at large) can consume and find useful. These APIs should generally be related to the organizations core business – and not a small side detail.

While these are separate, it’s easiest to understand them together. As already stated in the previous axiom, APIs have the power to generate significant economic value but:

• This value is only unlocked if a particular API set has a user-base. These users may be customers, employees, third party partners or the world at large – but without a user base an API is a wasted investment.
• An API is only as valuable as the data or functionality to which it provides access. So if an organization delivers a particular core competence (e.g. shipping, book retail, flight reservations, car hire), it stands to reason that the most valuable APIs this organization could provide link to and drive volume to exactly these core competencies.

Figure 1 illustrates the relationship between providing value to the target audience and using the provider’s core competence when designing and delivering an API suite. Obviously the provider should go for the “Sweet Spot” and develop APIs that focus on the provider’s core competence and deliver high value to the target audience. Anything less will meet with undesirable results.

In a theoretical example, a car hire firm may consider two APIs: 1) a data API providing historical trend analysis on US driving patterns, 2) transaction capability to book hire cars from the company’s fleet.
Both of these APIs are interesting and potentially valuable to someone (and both are worth considering). However, if the organization needs to choose between the two projects the second is clearly more valuable both to itself and its customers, partners. This is because:

• Transactions on the API drive the hire company’s core business.
• Transactions on the API help partners/customer carry out the key business with the organization in a new way.
• The company can safely say it is likely to continue support for the API if it succeeds since it will be contributing to core business metrics.

For the second API however, while this could certainly be valuable, it represents a deviation from core business. The car hire company would likely not be able to back the API with as much resource. Further, the API would need a new, separate business model. Though this could certainly be welcome if revenues were significant, they would likely need to be very significant compared to the company’s core business. Worse, if the API gets significant traction, costs could rise – potentially forcing a shut down. In other words, this second API is a much more fragile proposition both for the provider and potential users of the API.

In order to reinforce this point consider some examples of companies who operate APIs that directly drive their core business:

• The Walgreens API: subscription filling and photo printing
• Nike+: social network enabled sports clothing
• Twitter: read and write tweets
• Getty Images API: stock photo search in real time

In each of these cases, APIs form a channel directly onto the company’s core business and if successful will drive more business (which would likely grow over time). This channel delivers a very clear advantage over their competitors since potential partners and customers now have increasing reasons to partner with Walgreen’s, Nike, Twitter and Getty Images specifically.

It could even be argued that over time, an API could become the single most important business channel for many companies, since mobile, partners, and product integrations could all tie into a single channel.

Interestingly, it has taken a while to learn this lesson. Many of the early APIs that were created by large organizations were offshoots or experiments that were deliberately not related to the organization’s core business. In other words, organizations wanted to explore the impact of APIs but not affect their core businesses – this approach often leads to failure of the API program since:

Summary

Becoming an API provider is driven by one key realization: ensuring an organization’s core competence is available in the simplest form possible for others to integrate into their own systems such that they can become valuable suppliers, customers and partners.

Also providers should enable API access to core competence and preserve value to the target audience. Focus on the “Sweet Spot.”

Note: This is not intended to be an argument that every organization should have a fully public open developer program. In many cases that goal wouldn’t meet business objectives nor would it provide value. Instead the axiom states that becoming a provider to some kind of audience – typically a subset or superset of an organization’s existing customer base, or a new one they wish to address – is the important focus. A fully public open API is simply the mechanism to reach a particular type of customer base.

Up next is Axiom #5: Organizations must consume core competencies of others through APIs.