Organizations Must Consume Core Competences of Others Through APIs (Axiom #5)

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 fifth in a series of blog posts outlining the axioms of the API economy – and covers the fifth and last axiom. However, it won’t be the last post in the series – once we’ve covered all the axioms, we’ll proceed and talk about their consequences also.

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 #5: Organizations Must Consume Core Competences of others through APIs

The fifth and final axiom is the converse of the fourth axiom. Just as there is value in exposing APIs for others to consume, there is value in consuming the APIs of others. So much value in fact it is very likely a critical failure not to do so. Examples of this have already been given with Axiom #2 – for social, cloud and mobile (the former two in particular), the amount of functionality now available via API to simple use “out of the box” is staggering.

More specifically – the effort required to rebuild the features of many PAAS, IAAS, SAAS systems to the same level of functionality and consistency is beyond the capacity of all but the largest companies. Replication of some services is furthermore impossible – while it is feasible to write code for a microblogging service, Twitter is Twitter since it commands a global audience, not because of the functionality it provides.
The richness of functionality now available “by API” extends into multiple different realms:

• Data: impressive data catalogues of many types – many unique.

• Communications: SMS, Telephony, Instant Messaging, Video, Email.

• Processing: IAAS, PAAS platforms or specialized services like Aniomoto.

• Transactions: Payment APIs, Subscription Billing and others.

With such a rich set of tools available, developing systems has become significantly easier than it was 5-10 years ago. While choices need to be made both between providers and which elements should be developed in-house it is clear that many of these systems have the possibility to be of very significant value to an organization.

Any work an organization does that this is not focused on its core competence is arguably overhead. In other words, if comparable competitors were to use external APIs to achieve some important but non-core / non-differentiating functionality and this worked at least as well as an in-house build, this competitor would have freed up time to move further ahead on their core product. The opportunity cost of in-house builds of non-differentiating services is great.

It is therefore an imperative for organizations to:

• Identify what their own core competence / differentiation is and ensure that the majority of effort is targeted towards this.

• Where possible consume APIs of others to bring in functionality that is non-core in in this way.

There is a final, subtle angle to this axiom – it suggests consuming the core competences of others, not any competence. This means that if an API is chosen for use, it should ideally be something which is clearly and obviously linked to the core business of the organization providing it. This ensures that:

• The provider is likely to remain committed to the API.

• They derive value (economic or otherwise) from third party use of the API and hence should continue to support it.

These are all very strong indicators that the API will be maintained and improved over time. They also means that in many cases (though not all) there are likely competing companies providing similar APIs – providing a switching path in the case of failures on the part of the chosen provider.

If an API is a secondary, side business for an API Provider or does not seem to be core, this may be a higher risk integration – generally assurances from the API Provider should be sought.

Summary

Axiom #5 makes it clear that any API strategy not only includes the publishing of APIs for other constituencies to participate with but for organizations to plan on integrating the core competencies of their constituencies into their applications services and infrastructure. Make sure your organization understands the dual nature of API publishing an API consuming.

The Five Axioms are statements about the current state of APIs and where we may be headed. In themselves they already provide some insights into how organizations should consider acting – but this is where we’re headed next. Next week we’ll dive into what the consequences of these axioms might be for organizations and individuals.