Demystifying API Economies for the Non-Technical Reader - Part 1

One of the new terms making the rounds is the “API Economy”. What does that mean? Is it relevant to your company? If yes, what should your reaction be? This note delves into these topics from a business / functional person’s perspective. As the topic requires some explanation, the note is split into 2 parts. The first part explains the concepts in non-technical language and how to decide if it makes sense for you. The second part looks at how to go about the process if an API economy makes sense for you. On to part 1.

Background: The world of IT over the last few years has been characterized by the automation of core functions like finance, production, marketing, sales, service, logistics and HR using packages like ERP, SCM, CRM and HCM. “Old world” companies turned implementations of such packages into complex multi-year projects as they customized the packages considerably to suit their needs. The competitive advantage of such companies stemmed from their IP, branding, manpower, preferential access to resources / markets etc. IT in the main was seen merely as an enabler of these sources of competitive advantage and not as a creator of competitive advantage in itself.

So far, so good. However with the advent of newbies in many industries who are catering to a digital native (read younger) audience, this well understood world has been upturned.

A key reason has been the newbies’ ability to rapidly introduce digital innovations like say Uber offering to do last mile package pick up and drop using an app to match demand for last mile package delivery / pick up to routing of cabs in real time or say a PayTM (In India) offering innovative mobile wallet based services cutting into banks’ territories. The newbies have recognized 3 vital points.

One, IT’s role has turned to driving business innovation and creating value for customers thereby making IT front and center to competitive advantage.. IT therefore is no longer just a tool to automate existing processes.

Two, IT can only drive innovation if it is agile and unencumbered by the slow pace of change inherent in legacies like ERP. All the more so because unlike say a major car design breakthrough, most IT innovations can be copied rapidly.  To ensure IT agility, they have to adopt a 2 pace IT strategy to cater to slower to change core processes and rapidly changing innovations (please see below)

2 Pace IT

The concept of splitting IT architecture into 2 parts, one focused on running standard vanilla (read without customization) business applications like ERP and the other part focused on using emerging technologies to drive innovation and competitive advantage is not entirely new. For years companies have done just that but not always called it by an elegant name. Now with more emphasis on such bifurcation in a fast paced digital world, a formal naming was inevitable. However such naming is not the preserve of any governing body so different people have come up with their own names and in some cases 3 paces in place of 2 (the innovation layer further being split further into 2 paces) and so on. So in this paper we merely refer to a generic 2 pace IT rather than use any particular terminology. Though the concept is not new, most companies have been patchy in implementing it, resulting in a lot of customized core applications which slow down innovation drastically. Why? Usually it is because such a model requires longer term thinking which does not sit well with demanding users asking for urgent changes to legacy systems. What you should look at as a CXO is to get an analysis done of the major customizations that have slowed you down to date and decide which ones to keep, which ones can be discarded in favor of vanilla functionality and which ones can be extracted from the core into an innovation layer. Such an exercise must precede or at least run in parallel to any major digital transformation.

Three, innovations often fail and it is tough to pick the right ones upfront. So the new world IT has to permit quick experimentation with low entry and exit costs which can either rapidly scale (if they succeed) or be rapidly dumped (fast fail is the current buzzword for the same) with minimal disruption to the rest of the business.

Concomitantly, a customer experience (CX) revolution is happening that will affect most industries. A simple example. You may be planning an evening out with the family and may book a movie ticket or a sports event ticket using a service aggregator’s site (like GoTickets.com, TiqIQ.com, bookmyshow.com), which allows you to check which theaters are showing the movie you want and book the show of your choice . Till recently, if you needed a cab to get to the mall where the theater or stadium is located, you booked the cab separately using maybe Uber. If you took your own car, you got to the mall or stadium and drove around searching for a parking spot. If you wanted to have dinner later, you called a restaurant in advance to reserve. If you wanted to coordinate this trip with some friends you went to FB maybe and posted the details. Now with customers demanding ease of use, the aggregator’s web site would show you pop ups suggesting booking cabs / nearby restaurants / parking spots etc., so that you can complete your plan in one go, make a single consolidated payment and maybe post your plan to FB directly from the aggregator’s site to inform your friends of the plan. The term aggregator therefore is self explanatory.

From this example we see broadly how this new world operates. One, the coming together of agile IT and the CX revolution makes it a lot easier to enhance CX by partnering with companies in related areas through the use of IT. Two, both established companies (like a theater chain or stadium in this case) as well as newbies (like Uber) can partner and play in this new world.

One play is to become part of someone else’s ecosystem. In this case, the theater / stadium (old world companies) became a part of an aggregator’s ecosystem. The cab company (Uber in this case) did just the same.

An alternate play is, a company with clout (be it old world or newbie) can create and drive an ecosystem themselves like an established bank running a realty ecosystem (an example we will dwell more on later) or a relative newbie like a bookmyshow.com. Good news for established companies is that both these plays can apply to them.

In the IT world, one of the underlying technologies used by aggregators and ecosystem partners to create aggregated services is called an API (Application Programming Interface). Please see below to understand the term better. 

What are APIs?

A simple analogy to an ATM would help. An ATM offers a subset of the services that a bank offers from its branches. The ATM is analogous to an API. To use the ATM you provide some input like your card and type in a PIN. The output from the ATM comes as screen messages / print outs / cash / etc. There is therefore a well defined set of inputs (card and PIN) and depending on which facility you opted for, the output is also well defined. This well defined interface (inputs and outputs) is called an API or Application Programming Interface in IT lingo. In the movie example, to book a ticket and say a cab you have to provide specific inputs like movie name, which show, your name, address, phone number, card details etc.. The aggregator’s web site returns specific outputs like an eTicket and a cab booking reference. APIs simplify creation of this bundle of services because the aggregator’s web designer need not know any details of how the cab company’s application works. All she needs to know is which API does what and the input/output formats used. This also simplifies enhancing underlying applications without changing how the API is used by aggregators. For example, the cab company may refine their cab scheduling rules but the aggregator’s web designer is not affected as she will use the cab API exactly as before but get better services in the process.

The ecosystem driven by the aggregator comprising the theaters, stadiums, mall parking lots, restaurants, cab companies, payment systems etc., is what is called an API economy or API ecosystem.

An added advantage, especially for smaller companies is that using API’s, they can become part of digital yellow pages that can be used by aggregators anywhere in the world and therefore by end customers anywhere in the world too (more on Digital Yellow Pages below).

Digital Yellow Pages

In the movie example, the aggregator had a central theme i.e, taking a simple movie ticket buying transaction and expanding it into a larger entertainment experience. However, Digital yellow pages or service catalogs are a different type of aggregator. In the movie example, chances are the aggregator reached out to malls and the theaters and restaurants therein and pitched the idea of an ecosystem and tied up contracts with them. In this case, their being co-located in the mall creates a natural ecosystem. For the restaurant owner wanting to monetize the footfalls in the theater, such a tie up makes great sense. However, the same restaurant may also want to allow bookings from other ecosystems. For example, they may want to be a part of any food ordering website. They cant possibly reach out to all these sites, popular food blogs etc, to tie up contracts. In such cases, the restaurant can register its booking API with another aggregator who is more like a yellow pages. A popular food blog or whoever else can simply add that API to their site and route readers to a pop up on the screen with the restaurant’s booking API and get a referral fee. The beauty of this model is that the restaurant manager and the blogger don’t have to know each other or formally tie up a contract. The API on receiving a reader’s click can automatically initiate a referral fee payment electronically to the blogger’s account. The restaurant gets a referral, the blogger his referral fee and the reader, a booking at the restaurant. A win win for them all. The focus of this note however is more on companies creating their own ecosystems so we wont dwell further on yellow pages.

Does the API economy Make Sense For You? 

As with all new technologies, there are some early adopter industries and some who will wait and watch. Also within any industry, some players will adopt APIs faster and some slower. Knowing if an API economy makes sense for your company depends on a number of factors listed below.

Is your industry already seeing digitally savvy disruptors? While the pace of disruption varies by industry, we are seeing that no industry has been left untouched, even ones that were not seen as particularly “IT savvy” in the past like paper or public sector. Brainstorming sessions with your key people and selected external vendors / consultants can help you assess the extent of disruption in your industry and where your company stands in terms of adoption.

To be an aggregator creating a new value chain or to be a disaggregator entering others’ ecosystems or both? If the answer to the earlier question is yes, you need to decide which of these approaches will suit you better. To be an aggregator, you need to have a strong brand, reach and market share in your core services while at the same time having a reasonable idea of the how customer buying behavior and expectations are changing in your industry. As a disaggregator, you have to select which of your products / services to disaggregate, which ecosystems to join etc. Many companies may choose to do both. The example on home loans in Part 2 (“How Do you Go About It”) will illustrate this point.

When do we start? Many disruptors can easily move across geographies as Uber for example has shown but that may not be possible in other industries like online travel where relations with local hotels, airlines, tour operators etc., have to be built from scratch. So depending on the nature of your industry, getting the building blocks in place may take time or could be done quite rapidly. Again, brainstorming with a combination of internal leaders and external agents can help identify the right pace and priorities for you.

Who should be in your ecosystem? This is an evolving answer. Online travel for example started with just airlines and hotels but added rail, cabs, tour operators etc, over time as the business expanded and so did customer expectations. You may want to consider a separate team that is tasked with assessing the adoption of your APIs, identifying what to enhance, what to drop as well as what new APIs to add. A related question is if the APIs should be paid for or free (please see below).

  To pay or not to pay?

That depends on the nature of services provided by the API and the bargaining strength of the players involved. For example in the movie example, the cab company would agree to pay the aggregator a fee for each time people booking a ticket also book a cab. The payment could be flat or as a percentage of the transaction value depending on the nature of the transaction. In this case the theater gets money from the cab company. A reverse example may be where a credit rating agency may provide an API that can be called from various financial companies’ loan origination systems, who will pay a flat fee for each use of the credit check API. On the other hand, there may be some services that are free. For example, an auto magazine’s web site would want to provide comparisons of price and features to readers to give them better choice. Car companies would want to be part of the site’s comparisons as they won’t want to be ignored by readers. In this case, the car companies are likely to provide a free API that takes as input a model, color and location and provides a detailed feature list with on road price as output. The magazine’s site would take similar data from other car makers in the same car category the user is browsing and provide a comparison for the reader. The API in this case is free but a win win for all – the online magazine, the auto company and of course the reader.

Where should you set up your ecosystem? You have a choice to set up the entire IT system for the same yourself and court various providers to join your ecosystem. However what we see increasingly is that companies prefer a public cloud for such deployment as you want to be able to create and roll out a new service quickly and junk it equally quickly if it fails or scale it quickly if it succeeds. You want to do this without security concerns and get access to the latest technology all the time without having to do complex upgrades or hiring expensive system administrators etc. All this is just a lot simpler on a public cloud. 

This was not an exhaustive list of questions but the key ones to get you started on the journey. Once you have answered these questions, you know if the API economy makes sense for your company or not. If yes, the answers will also lead you to a high level prioritized road map.

To summarize part 1, we looked at the factors driving change towards a digital world and what part API's and the API economy play in the same and how to decide if it makes sense for you. In part 2, we will look at how you go about the process should you decide that an API economy makes sense for you.