What APIs should your business provide? How do you identify good API candidates? Previously we discussed API Economy Drivers and some of the high level use cases that are driving the adoption of APIs. In this post we will drill down on these use cases to help identify questions to ask that can be used to identify good API candidates.  

 

Let’s start by looking at what other businesses are doing. There are some common characteristics for many APIs that can lead us to a good place to start to look for API candidates for your business.

 

Here are brief descriptions and some examples:

  • Providing un-customized data – this is data that is not specific to an end user, i.e. no matter who the consumer is for the API they would get the same result. Examples of this type of API might be current mortgage rates, store locations, stock quotes, or product descriptions.
  • Providing customized data – this is data that is specific to the consumer.       Examples here might include account balances, personal health information, appointment schedule, or a consumer’s insurance card.
  • Transactions – as opposed to read-only information, we may also want transactions that make updates to the systems of record. Examples here might include scheduling an appointment, asking a question, sending a photo for an insurance claim or depositing a check, and of course placing an order.
  • Social Business – this might include interacting with others, viewing social comments or product reviews, posting comments, or providing ratings.
  • Device integration – here we are talking about collecting data from devices or wearables and acting on this data. This could be from meters, sensors, RFID, Fitbits, scales, appliances, automobiles, etc.

The vast majority of currently available APIs are for internal use by Mobile app developers within the company. However, the expectation is that usage of APIs by people outside the company will grow creating the API Economy we have previously discussed. Let’s take a look at some of the use cases that would lead to creating APIs for these and other use cases.

Mobile internal development – the new User Interface is the mobile phone (and tablet). Without getting into the details of the technical differences between this
Mobile-App
interface and the prior interfaces that have been in existence for some time, one key driver for API creation is providing equivalent business function on the mobile device. Then follow this up by extending the function to the take advantage of some characteristics of the mobile device (e.g. phone capabilities such as the camera and the fact that the device moves with you) is the next logical step. Businesses are looking to provide freedom to innovate to their mobile developers and allow them to create and iterate quickly on their mobile apps. APIs are often created to enable this rapid dynamic environment for the mobile developer while protecting the back end service providers from churn. We want to provide simple to consume interfaces for the mobile developer shielding them from back end system complexities. In looking for APIs to create for your mobile developers some questions to ask yourself are:

  • What data/transactions are exposed via the business’ current browser interface?       Should these be common / implemented with the mobile device interface?
  • Is there data that is generic to any consumer that would be useful to expose?       (e.g. business locations, rates)
  • What data will your current customers want to access that is specific to their account? (e.g. account balances, order status)
  • Are there data/transactions that would benefit from a characteristic or capability of the mobile app? For example, something that might take advantage of knowing your location (e.g. nearest ATM) or something that could use the camera function (take a picture for an insurance claim)?


partner

Partnering – After exposing APIs internally the next largest segment in the current API Economy is to provide APIs for your known business partners. Historically, partner on-boarding and integration has been a laborious process. Is there a possibility to ease this through APIs?

  • Would self registration for partners be an option (with potential for approval)?
  • What data / transactions do you share between yourself and your partners? (e.g. inventory levels, order status, reporting)

Public APIs – The excitement and buzz around APIs is driven by the opportunity to expand beyond the existing enterprise walls and partner ecosystem. While this is not
PublicvsPrivate
the majority of currently available APIs, it is worth investigating and understanding the benefits that will follow from making an API public. So, what APIs might make sense to make available publicly?

  • If there is a comparison app for your business vs. your competitors would you want to be listed as an option? What information would you need to make available?
  • What other industry apps might be able to use your products or services and thus drive business to you? (e.g. a car purchase might drive the need for a bank loan)
  • If someone outside your company were to send business to you, what information and transactions would they need to be able to execute on this? (e.g. product catalog and descriptions, order, order status, etc.)
  • How might your data or transactions be combined with APIs not created by your company? Think Mash-ups. What data do you have that might be related to location (i.e. combined with a map API)?


I Like
Social / Big Data Analytics
– There is tremendous value to the business to capture and act on Social data and interactions. Many Social interactions are occurring using APIs and data from these systems can be captured by consuming APIs in your apps or enterprise systems and driving actions. Questions to ask in this area:

  • How do your systems interact with social media? Can you spot trends in social media related to your business and raise alerts or take action?
  • Can you gain insight on your brand and your competition via social media?
  • Can you do real time analytics combining current customer status/behavior and history?

Device Integration / Wearables – Mobile evolution is not just about phones. The Internet of Things (IoT) will generate far more connected devices than there are phones and tablets. For some businesses integration with devices is obvious (e.g. automobiles, health monitors, pipeline sensors, electric meters, etc.). For other industries the relationship may not be so obvious or may be coming in the future (e.g. refrigerators helping create shopping lists). 
051413_Force_popUpBanner_grey_o
One thing we do know is that the current User Interface technology of the day will eventually move forward to a new technology just as client server moved to the browser that now has moved to mobile. Perhaps the next one will be wearables? Maybe it will be something else? We don’t know for sure, so creating an API to the business function allows for quicker adoption of a new UI no matter what technology it is based on. What should we look for in this area?

  • What business functions would you want to bring forward to the next UI technology (after mobile/tablets)?
  • Does your business already deal with devices (e.g. cars, appliances, sensors/meters)? What scenarios can apply to the device (e.g. needs repair / supplies, needs to send status info, interaction between device and systems of record)?
  • What devices are related to your industry that could benefit your business if connected? (e.g. refrigerators for shopping, climate sensitive distribution mechanisms, vehicle tracking, security systems)
  • Do you have manufacturing and logistics events that could be used to drive actions and insights?

Data Assets – Almost all businesses have large amounts of data collected on customers, buying patterns, regional differences, etc. While this provides business
Gold bars
advantages to your business it may also be of value to other businesses not in your industry. Monetize your data! Insight is the new ‘gold’. New revenue opportunities can be achieved by selling API access to this insight.

  • Look at the data you are collecting for your own analytics. What market segmentation does this provide?
  • Can your data be used to segment potential buyers for other industries (e.g. expensive car buyers leads to insurance sales and higher wealth customers who might be interested in other luxury items)?

Over the next several weeks we will drill down on these questions for specific industries one by one providing common APIs for mobile development, existing examples of public APIs, and a look toward what might be done with APIs in that industry as we move forward into the API Economy.

What industries do you want to see discussed? Let me know.   Connect with me through comments here or via twitter @Arglick to continue the discussion.  You can also read my earlier blogs.

9 comments on"Identifying Good Candidates for APIs"

  1. […] my last blog post we discussed how to identify good candidates for APIs.   This week we will apply the techniques to Banking. This is still generic and not specific to […]

  2. […] few weeks ago I discussed how to identify good candidates for APIs.   This week we will apply the techniques to Insurance. This is still generic and not specific to […]

  3. […] a look at Retail and the API Economy, once again using the structure I introduced a few weeks ago (here).   This is still generic and not specific to any single Retail company. My hope is that these […]

  4. […] at Healthcare and the API Economy, once again using the structure I introduced a few weeks ago (here).   This is still generic and not specific to any single Healthcare Payer. My hope is that these […]

  5. […] or using government data. Once again I’ll use the structure I introduced a few weeks ago (here).   Government is a broad topic with federal, state, and local agencies and each country […]

  6. […] again I’ll use the structure I introduced a few weeks ago (here).   T&T industry covers the obvious area: airlines/airports, hospitality, rental cars, travel […]

  7. […] as the platform for innovation. Once again I’ll use the structure I introduced a few weeks ago (here).   This is not intended to be comprehensive, just some possibilities to whet the […]

  8. […] Once again I’ll use the structure I introduced a few weeks ago (here). […]

  9. […] So, let’s explore how APIs are used in the Media and Entertainment industry. Once again I’ll use the structure I introduced a few weeks ago (here). […]

Join The Discussion

Your email address will not be published. Required fields are marked *