BT

A Business Perspective on APIs

| Posted by Matt McLarty Follow 0 Followers on Nov 18, 2014. Estimated reading time: 13 minutes |

Designing, implementing, and maintaining APIs for the Web is more than a challenge; for many companies, it is an imperative. This series takes the reader on a journey from determining the business case for APIs to a design methodology, meeting implementation challenges, and taking the long view on maintaining public APIs on the Web over time. Along the way there are interviews with influential individuals and even a suggested reading list on APIs and related topics.

This InfoQ article is part of the series “Web APIs From Start to Finish”. You can subscribe to receive notifications via RSS.

 

APIs are at the heart of every major information technology trend today. Mobile devices, cloud computing, the Internet of Things, Big Data and social networks all rely on web-based interfaces to connect their distributed components and deliver innovative and disruptive solutions to every industry in global business. Smart grid technology is transforming the energy industry. Connected Car solutions are viewed as a key differentiator in the automotive industry. Amazon is disrupting every industry it touches. In all of these cases, APIs are both catalysts and enablers.

Because of this business impact, there has been much written about the “business of APIs”. On the open web, there is a distinct business model for using APIs as an external channel for innovation and revenue. This is documented comprehensively by Kin Lane on his API Evangelist site, and summarized elegantly by Mehdi Medjaoui in this recent post. However, this open API model represents the tip of the iceberg when it comes to API adoption across the technology spectrum. In fact, the majority of web APIs are hidden within the solutions they enable. In this sense, the business of APIs is just business itself.

This article will examine APIs comprehensively from a business perspective, whether or not they are open and overtly monetized. I will cover the importance of tying your APIs back to your business value, look at the type of data that should be used, and study the API success stories of Amazon and Twilio. I hope that these lessons will help you build useful and usable APIs.

Measuring API Business Value

The general business value of APIs can be measured. It all starts with data. For many companies and organizations, the data they collect is viewed as a liability. Servers and storage are expensive. However, in today's increasingly digitized world, it is obvious that data can also be a precious asset. Data provides insights on clients that can be turned into differentiating business opportunities and new revenue streams. The “Big Data” craze seeks to sort out the digital confusion through high value analytics. The imminent Internet of Things (IoT) explosion will bring an exponential increase in data, making it even more critical for companies to be on the right side of the data ledger.

The degree to which a company’s data is an asset as opposed to a liability is driven by three things: its accessibility, accuracy and applicability. Any web API provides accessibility to some data to some degree. Valuable APIs provide access to accurate data that applies to their core business. This enables companies to achieve an iterative approach I call “Data-Enabled Disruption”, which I will explain below. Furthermore, these three data attributes provide a methodology for determining which data and services should be exposed through APIs, and how those APIs are implemented:

Data Applicability

  • Will this data help drive my key business goals?
  • Does this data differentiate my business?
  • Will I commoditize this data if I expose it externally?

Data Accuracy

  • How current is the data being provided?
  • Is the data coming from an authoritative source?
  • Is data being accessed by the right end users for the right purpose?

Data Accessibility

  • Which data is available for programmatic consumption?
  • What are the different ways can this data be accessed?
  • How easy is it for developers to build apps that use this data?
  • Can the data access scale to meet the client needs?

Examining this methodology from the perspective of APIs, these three data attributes can be consolidated into two attributes of APIs:

  1. “Useful APIs” provide accurate and applicable data
  2. “Usable APIs” provide accessible data

Obviously, the most valuable APIs are both useful and usable. However, in order to define these API attributes further, let’s examine each one individually.

Useful APIs

A common mistake people make when developing APIs is to assume that all data is useful. There is a widely propagated myth that if you open up your data, magical developers will appear and spread pixie dust on it that increases your revenue, creates innovative ideas, and opens up new business channels. APIs and Open Data are not enough on their own. This “medium is the message” thinking was responsible for many of the failed SOA initiatives that occurred in enterprise integration over the last decade. I recall one very large enterprise that was embarking on a $50M+ SOA and private cloud initiative. They were baffled when I asked what services they would be exposing to which clients. All they cared about was building the infrastructure. Needless to say, the initiative failed.

The good news is that the desired revenue and innovation benefits can be achieved if the right data is exposed through the right APIs. Google Maps leveraged Google’s dominant web presence to deliver an API-based service that filled a market gap. The service was so useful that Google was able to monetize it at a premium. Through its API, Google Maps was embedded in the original iOS platform, and the initial poor reception for Apple’s replacement only emphasized its value. Social Networks—led by Facebook and Twitter—are a medium whose growth and success are inexorably linked to their use of APIs in order facilitate web linking and mobile adoption. Useful APIs have even impacted federal election campaigns.

The Amazon API Story

As I stated off the top, the potential for business success through APIs runs much deeper inside organizations than is apparent from the world of open APIs. This potential was exploited heavily at Amazon, a company whose API origins were internal. Amazon’s enduring API-enabled success is arguably unmatched in any industry. Amazon provides a number of lessons through its use of APIs that can help other organizations achieve business success with their API programs.

The first and most obvious lesson from Amazon is how to position APIs as building blocks for product and solution offerings. Brad Stone spends a chapter in his book on how fundamental APIs are to the technological landscape at Amazon. Kin Lane summarizes nicely how adamant Jeff Bezos was and is in ensuring interfaces at Amazon provide programmable access. According to these reports and others, product managers must identify the lowest common denominators of business value in their offering proposals. These “primitives” are then used by the technical teams to create APIs that expose this business value to other developers who create the remainder of the solution. The logic behind this as that these increments of business value can be used and combined easily for future offering development. This is how Amazon Web Services was able to be delivered and enhanced so rapidly: Amazon had API-enabled their infrastructure services in order to optimize the process of expanding their capacity. AWS came about by turning those internal functions into an external product. As you can see, Amazon goes a step further than just ensuring the APIs they provide include useful data. They invert this principle, and instead ensure that every quantum of data employed in a solution sits behind an API.

The second API lesson from Amazon is how to use an API-based approach to collect, analyze, improve and distribute valuable data. Jeff Bezos had an epiphany about Amazon’s core value proposition in the early online bookselling days: “We don’t make money when we sell things. We make money when we help customers make purchase decisions.” He aligned the execution of the company with this insight, and this led to strategic moves such as personalization and the broadening of channels. In fact, it is clear from the above-stated value proposition that data—applicable, accurate and accessible data to guide customer decisions—was more vital to Amazon’s success than books or any other goods that they might sell. At Amazon, APIs are the conduit for the continual accumulation and improvement of data. This cyclical process fuelled Amazon’s growth. I call this 360 degree cycle “Data-Enabled Disruption (DED)”, and summarize it as follows:

As a result of DED, many of Amazon’s former competitors are now dead. By utilizing APIs at all points of the data life cycle, Amazon is able to continuously improve the accuracy, applicability and accessibility of their data.

The final API lesson from Amazon is derived from the disciplined way the company is able to balance its tactical delivery with its strategic positioning. This was evident from the start, when Jeff Bezos recognized the potential of the World Wide Web and had a vision to create “the everything store”. Knowing that he needed to start small, Bezos analyzed the market and identified online book retailing as a ripe entry point with an optimized supply chain. This paradoxical approach—ensuring timely execution while maintaining religious devotion to the future vision—is now a tenet of Amazon’s culture, where solutions must add value both in what they deliver and what they enable. An API-based delivery approach supports this principle, since APIs power new applications and services while facilitating future use cases. This iterative methodology has fuelled the company’s relentless expansion ever since (depicted below).

(Click on the image to enlarge it)

Each of these services has an associated external API, but each one is also built on the API scaffolding provided by earlier offerings. As companies look to grow their business vertically and horizontally, they can utilize the Amazon approach that is predicated on useful APIs: continually collect and harvest applicable data, use APIs as the common access points to that data, deliver only what is needed in the short term with the long term firmly in mind, then expand from a position of strength.

Usable APIs and the Importance of API Design

As remarkable as Amazon’s success has been, and as fundamental as their APIs have been to that success, their external APIs are not generally regarded as the most well-designed and easy-to-use. Still, with the explosive growth of APIs and the increasing acceptance of their necessity, API usability is a key differentiator for companies that want to dominate their industries or even startups who just want to establish their innovative service.

Mobile devices and the consumerization of IT are creating a generational paradigm shift in enterprise application development. Previously, there has been dumb terminal-mainframe, then client-server, and most recently the distributed topology of the web. I have talked previously about what I call “the shedding of tiers”, moving away from the n-tiered web model to an API-centered topology in support of mobile and cloud. This shift also includes a move away from Java Enterprise Edition to JavaScript and its derivatives as the languages of choice. All of this means that there is a new wave of developers who will increasingly be the ones building new enterprise solutions. These developers are conditioned to seek out APIs for functions that they require. Companies can anticipate this shift and cater to this new generation of developers by emphasizing the usability of their APIs.

Consider the telecommunications industry. For years, the big carriers have competed vengefully against each other while simultaneously trying to deliver value-added services that go beyond network delivery. This is an industry that has experienced incredible disruption over the last fifteen years, with the advent of VOIP, convergence of business and operator services, and the revolution in mobile device services. In each of these disruptions, APIs played a role. In spite of their dominant position in traditional telco services, the big carriers struggled to take advantage. They had even more difficulty when they tried to collaborate on initiatives like Parlay X and OneAPI, as summarized in this article by Alan Quayle. So if the big guys weren’t exploiting these opportunities, who was?

Twilio was founded in 2007 with the goal of providing easy-to-use voice and text contact services, all deployed in the cloud. They demonstrated a platform mentality from the outset, and recognized that their API would be their number one business channel. SMS and VOIP services are certainly useful, but in order to compete with the big carriers, they needed to deliver more than a set of commoditized telco services.

Twilio’s key insight was to recognize that the initial client of their service was not the end user of the app calling the API, but in fact the developers creating the apps themselves. They knew that the highest growth segment of apps being developed was in mobile, and so they came up with a set of metrics to measure how well they were serving this client group. In addition to measuring traditional end user statistics like end-to-end API call response times, they measured the time it would take for a new developer to register for their API and set aggressive targets. This focus improved their usability and gave them a clear differentiator against the big telcos. When it came time for app developers to choose which SMS or VOIP provider their app would use, this rapid, carrier-agnostic service stood well above its competitors. By providing a useful API, Twilio could justify charging for this service and making money on every API call. By providing a usable API, they drove up these volumes and along with it their revenues.

Industries beyond telecommunications are ripe for data-enabled disruption too. Consider Ingenie, the insurance startup who found an opportunity in the way actuarial-based pricing punishes the 16-25 year old demographic. They collect individual driver data through a proprietary smart device in the car, then use this to offer insurance discounts to this group. Useful and usable APIs allowed them to use data-enabled disruption and “Twilio” the insurance industry.

Useful and Usable API Lessons

To recap, there are a number of steps you can take to ensure the success of your API program:

  • Align your APIs with your business strategy
  • Do this by including accessible, accurate and applicable data in your APIs
  • Make sure your APIs are both useful and usable
  • Like Amazon, establish a disciplined culture of iterative Data-Enabled Disruption
  • Like Twilio, create a phenomenal API developer experience to differentiate your business versus larger competitors

Follow these lessons, and you will set a course for business success that is bolstered by your APIs. You are the best judge of what will make your APIs useful to your clients. Make sure to read the other articles in this series, and you will learn some great tips on how to make those APIs usable.

About the Author

Matt McLarty (@mattmclartybc) is Vice President of the API Academy from CA Technologies. The API Academy helps companies thrive in the digital economy by providing expert guidance on strategy, architecture and design for APIs.

 

 

Designing, implementing, and maintaining APIs for the Web is more than a challenge; for many companies, it is an imperative. This series takes the reader on a journey from determining the business case for APIs to a design methodology, meeting implementation challenges, and taking the long view on maintaining public APIs on the Web over time. Along the way there are interviews with influential individuals and even a suggested reading list on APIs and related topics.

This InfoQ article is part of the series “Web APIs From Start to Finish”. You can subscribe to receive notifications via RSS.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

A Business Perspective on APIs by John Willson

A great article - insightful and timely with current direction paths of intermediate to large enterprises or agile development teams. Enjoyed the perspective. john

Re: A Business Perspective on APIs by Matt McLarty

Thanks John! I'm grateful you read it. We're all in this together. Matt

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT