Logs, Links, Life and Lexicon

API Economy

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating 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.

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating 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.

Axiom 4 Graphic

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.

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

The Five Axioms of the API Economy

This blog post is the third in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first and second 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 #3 addresses what kind of impact APIs are likely to have. Seen from the outside, APIs may often look like un-important add-ons, but there is a strong and clear argument that economic value is at the core of APIs.

Axiom #3: API’s are an Economic Imperative

As is clear from the first two Axioms, APIs provide significant value in a wide range of scenarios: making new types of products and services possible, reducing integration costs or speeding up existing processes. However, It may still appear that the majority of the beneficiaries of APIs are likely to be primarily digital or technology companies like large social media companies or media organizations. It is also difficult to see past the technical nature of APIs to their business value since much of the current debate around APIs is inherently about implementation details, technical architecture and so on.

However, APIs are, at their core, not a technical device. Instead, they are a means of delivering or providing access to a service or a product. In other words, the precise technology involved may vary but the essential nature of an API is to provide access to something of value. This in turn means that APIs intrinsically provide economic value. For example:

  • Twitter’s API provides the availability to send a tweet and have this visible to the whole of Twitter’s user base: clear value.
  • Salesforce’s API provides the ability to synchronize customer data with third party tools – making those tools and Salesforce itself more useful: clear value.
  • The City of New York’s 311 API provides the means to report problems to the city managers so they can be addressed: clear value.
  • Twilio’s Telephony API allows the sending of an SMS to any phone number in the world in one line of code: clear value.
  • United States Postal Service (USPS) API. The U.S. Postal Service provides a suite of USPS Web Tools that customers may integrate into their own websites to validate or find mailing addresses, track and confirm mail delivery, calculate shipping rates, and create domestic or international shipping labels: clear value.

Interestingly, only in the case of one of these APIs is the actual API invocation charged for (Twilio charges per SMS sent), yet they all still provide value – often to the provider of the API as well as the user.

For digital native companies such as Netflix, this value is already very clear: Netflix API has evolved tremendously since it’s launch and provides the key meta-data and navigation flow that underpins Netflix players deployed on over 1000 different types of devices. Without the API Netflix players would not be able to nimbly navigate the Video content Netflix delivers or deliver a custom experience on each device. But beyond inherently digital businesses, many more large organizations are deriving clear value from APIs:

  • General Motors: GM via onStar provides a rich set of APIs to control the systems in some of its vehicles. The APIs provide both in-vehicle and remote information and control – enabling third parties to provide new applications and experiences to GM customers.
  • Walgreens: The Walgreens API Program enables partners large and small to integrate and both print photos and file prescriptions – important and valuable services for both the developers writing the apps and for Walgreens itself.
  • Johnson Controls: JCIs Panoptix division amongst others employs APIs to provide access to data and control systems from its in-building installations. This in turn creates a marketplace for new applications compatible with their systems.

To complete the Axiom however, we also need to discuss whether or not APIs are an economic imperative. This is equivalent to asking –

“Yes, but how important is this additional value? Can I live without it? How do I compare it to other valuable initiatives I have going (opportunity cost)?”

While not every industry sector and every player in every sector is in the same situation and hence, the answer to this question may vary. However, there are several reasons to believe that for most organizations there is a clear imperative to deploy APIs:

  • The value created is likely to have direct impact (being able to do new things) and indirect structural impact (making the organization more agile in the future).
  • The value of APIs is often on the top and bottom line: on the revenue side – APIs enable new products and services or drive more volume for existing products/services, on the cost side – integration costs often drop dramatically when API-driven.
  • Many API strategies enable creation of a partner or customer ecosystem – reinforcing the value of products/services with third party additions. This type of effect is often strongly biased to the first few movers in a space – enabling them to grow proportionally faster than their competitors.

There are industry sectors where no significant players make significant use of APIs, the economic case is clear – once one or more players come out with offerings, they will force transformation amongst all the remaining players.

What is without doubt is that APIs are already starting to have a significant top and bottom line effect on a business. It has already become an imperative to leverage their power– just as cloud, social and mobile have become imperatives in almost every sector.

Summary

Proper use of APIs provide clear value. It is economically imperative that organizations integrate well-designed API strategies into their planning and development processes. These actions will provide value to any organizations top and bottom line economic values.

Axiom #4 will be coming next.

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

The Five Axioms of the API Economy

This blog post is the second in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first Axiom posted here (also see an intro to the series). 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 #2  focuses on the fact that APIs are an integral part of what are arguably the three major forces currently transforming the Web and IT  – The Computing Trifecta—Mobile, Social and Cloud Computing. These transformations have been underway for a while but they are combining increasingly strongly and the effects are still getting deeper.

Axiom #2: APIs are core to every cloud, social and mobile computing strategy

Early Web systems were single destinations acting as self-contained silos within which a browsing user could act – consuming information, uploading data or authorizing transactions. Many current systems still function this way. However, while this metaphor functioned credibly for a “human powered” Web, it provides no support for the software-to-software interactions that that are increasingly occurring between devices and web services.

As web interactions become more automated, higher velocity and more fragmented (many smaller transactions like sending a tweet – versus large ones  like downloading and browsing an entire web page) software-to-software interactions are a clear requirement for success. Humans in the loop simply cannot effectively keep up with the velocity and accuracy required. Nowhere is this better exemplified than the implementation of what are commonly the three largest Information technology challenges faced by organizations today: cloud computing, social and mobile.

APIs in the computing trifecta — cloud, social and mobile computing

“Cloud Computing” is a term used so much that its meaning can often be obscured or misunderstood. It is generally accepted that cloud computing be thought of as a stack of services classes. The three classes of services are Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure as a Service (IaaS).

Figure 1 illustrates the idea of Cloud Computing being a stack of service classes.

Cloud

Figure 1—Cloud Computing Service Classes                                    Source: Burtonian

Here is how we view these services classes.

  • SaaS—applications designed for end users, delivered over the web.
  • PaaS—tools and services designed to make coding and deploying SaaS applications quick and efficient.
  • IaaS—hardware and software that powers it all—servers, storage, networks, and operating systems.

While for illustration purposes, a diagram showing clear cut differences between these classes is useful, in reality the lines between these service classes  is getting blurry and will continue to do so in the future. However, the distinction is still useful in understanding how cloud computing and its services classes relate to APIs. In their earliest incarnations, SaaS variants of cloud started with hosted email, blogging and other tools but quickly progressed to key enterprise applications such as CRMs, HR, accounting and other functions. Many of the earliest SaaS apps began life as a browser based alternative to desktop software – and hence human interaction with the application through the browser was their key use.

Modern SaaS apps have evolved way beyond this and providing the means for software integration with a SaaS app for customers and/or partners is table stakes in almost every sector. Further, for PaaS and IaaS layers, the means to integrate with the platform/infrastructure via APIs is in many cases the key driving factor in adoption decisions:

  • SaaS: APIs are crucial for adoption since they enable customers of the service to carry out bulk operations, integrate tightly with other SaaS applications and internal processes, as well as providing an extra level of comfort with respect to platform lock-in. Almost every major SaaS offering is now deploying at least customer facing APIs to permit easy integration. Many also have or plan to have partner ecosystem APIs enabling third parties to develop add-ons and modules that benefit their customers.
  • PaaS: Platforms provide compute, storage, messaging and other services and essentially act as hosted APIs onto which developers can layer their code. APIs for PaaS essentially fall into two categories – those available to the code effectively running on the provided PaaS servers themselves, and those available to push-pull data into and out of the service. This access may be for other parts of the application that are not hosted on the PaaS, mobile applications calling the PaaS or for bulk control, management or monitoring operations.
  • IaaS: Last but not least, as with PaaS services, APIs play a key role in remote access to the infrastructure being provided. In this case most IaaS providers are providing raw compute power, storage and networking as a resource – so application development for code which is to run on the IaaS is often directly using the operating system primitives available (Linux, Windows etc.) rather than some higher level, more abstract API as they do in the PaaS. However the external APIs for bulk operations, control, management, monitoring remain critical.

In each of these cases, while it is still technically possible to use a cloud hosted service in a way in which everything about the application is hosted within that single cloud service and requires no external integration, this mode of operation is insufficient for almost all significant use cases. Trends in the market also shows a strong correlation between the strength of a cloud service provider’s APIs and their relative success in the market.

Social and APIs

Social media has clearly had an enormous impact on both consumer Internet usage and enterprise applications. Facebook now counts more than 1.2 billion users, Twitter 230M, Instagram 15M and popular messaging app Whatsapp was just acquired by Facebook for $19B. On the enterprise side, social integration with mainstream networks as well as “social” features to enterprise products are all now table stakes for most organizations. Diverse examples of enterprise social products include:

  • In-enterprise social network products such as Salesforce Chatter, Yammer and others
  • Code collaboration products such as Github and Altlassian’s Bitbucket
  • Collaboration tools including wikis and task managers

Social logins such as Facebook Connect, Twitter Auth, Google Login and Github Auth are being used with increasing frequency to manage work related identities for enterprise SaaS products, media access and almost everywhere that a user login-in is required. A third dimension of social surrounds the gigantic amounts of data that are produced by social media applications. Companies such as GNIP (now part of Twitter) and DataSift have sprung up to process the real-time streams produced by large social networks. Other companies such as Marketwired’s Sysomos, Radian6 (now part of Salesforce), and Klout (now part of Lithium) analyze these data flows and provide value added aggregate information on top.

As user behavior continues to reinforce the growth and importance of social media and the value of enterprise social increases, companies and individuals are compelled to include social integration options in their own workflows and products. Such an integration or addition requires the use of APIs – either by integrating APIs provided by third parties or (in the case of products with a social dimension) providing a new API. At their core, social systems provide a range of key functions:

  • Messaging and notifications
  • Media sharing
  • Collaboration
  • Search and monitoring
  • Data aggregation

Each of these functions can be a means in itself (a discrete task carried out by an individual) or part of a large workflow:

  • Tweeting out the result of a process, or arrival of a new piece of content or an opinion or comment
  • Pushing out a Facebook post when an Instagram photo is published
  • Updating a Github work ticket when a software integration test passes
  • Regularly search on the same set of keywords for mentions of a company’s brand
  • Tracking statistics of certain behaviors across different social networks

As a social strategy evolves, it invariably requires processes to be established and made replicable. Hence APIs become central as these small individual actions are strung together into a larger flow. In other words, the bite-sized nature of many of these interactions make them key components in larger processes. In a similar way, any new product with its own social features (e.g. a new code collaboration tool) will quickly run into the need for integration with existing other tools in the workflows which are already established. As a result, an API becomes an indispensable part of the product. Conversely shipping a product with pre-existing integrations to the APIs of other tools in the workflow is a major added value for a product.

Mobile Computing and APIs

For the final category, it goes without saying that mobile is a huge driver of API adoption. However, it may not be 100 percent clear as to why this is so for an individual company – after all, it is rare that an organization sets out to build an API if their focus is putting an application in a user’s hands. However, APIs are at the heart of such projects since they provide the server-side synchronization point with which applications communicate.

Going back to 2008 and the launch of the iPhone with the first generation of apps, and even further back to early feature phones Blackberry and  Palm Pilot, the vast majority of apps were software that ran in a self-contained manner on the mobile device. In other words the app’s value was solely in the software executing on the device.

Through 2009, and to this day, a continuing transformation has taken place in that almost all meaningful apps are composed not only of software executing on the device, but also server-side services that provide support services. Everything from backup to live data or ecommerce transactions functions this way. This server connection requires an API to receive and respond to traffic. With the rise of Android and the proliferation of the number of device types that can run mobile apps, there are often many versions of a mobile app that are available at any one time – all of which need to be able to access server-side components.

A modern mobile strategy is therefore increasingly like the one shown in Figure 2, with an API-driven core and a wide variety of different clients calling the API.

Platform

Figure 2—API Driven Platforms Power Broad Mobile Strategies Source: 3scale

These trends in APIs are likely to be at the heart of many of the major strategic IT initiatives most companies have planned. This is becoming increasingly true as the number of end devices, operating systems and frameworks a given company wants to deliver mobile functionality to also increases, and so the value of an API increases rapidly if it can be shared by different clients.

Summary

As with the first axiom, the truth of this axiom may seem obvious – but this is part of the point. APIs are often “in the picture” of transformative strategies in mobile, social and cloud, but rarely mentioned. Every organization is evolving strategies to deal with the Trifecta—cloud, social and mobile computing— and these come in varying shapes and sizes. However, it is critical they they be viewed from a perspective of being API-centric, since APIs are a key glue which make each of them stick.

Axiom #3 will be up next.

Archive
October 2014
M T W T F S S
     
 12345
6789101112
13141516171819
20212223242526
2728293031