Continuing the API Economy Business Drivers and Use Case Categories series our next use case category is Data and Analytics. I will focus on the methodology I use to identify API use cases so you can apply this to your specific business. As a reminder you can find industry examples for APIs across the use case categories linked here.
When Forrester surveyed 32 IBM API Connect customers on their primary reasons for choosing IBM API Connect, accessing data was the number one use case in the list.
What are companies doing with APIs to “Enhance access to data”? Let’s look at some scenarios to help identify the use cases.
As companies begin API initiatives, there is usually a need to supply some basic building blocks that many API projects will use. These tend to be data focused APIs providing a view of business assets such as:
- Customer information
- Account information
- Product/offering information
- And any other recognizable business asset related to your specific industry/business.
A good starting point is to make a list of these assets in your business. In some cases you may want multiple variations of these APIs, for example one that provides just basic information about the asset and another that provides more complete information.
While the approach of building APIs based on internal assets is not exactly consumer focused design, it does provide a base of APIs that consumers can see as a starting point and recognize the possibilities as to what can be obtained. Follow on APIs may cut the data in different ways, combine the data, and be more customized to what the consumer specifically needs.
Additional internal use cases
Most companies collect lots of data on their business transactions for various purposes. The usual scenario is that some part of the organization has a need to collect data for some reason: analytics to improve business sales, reporting, audit, regulatory, etc. The data is collected and made available to that group. End of project.
What companies are realizing is that the data they already have is valuable to other parts of the organization. They just need to allow access to this data to these other groups. Enter APIs! Because APIs can be created quickly, are easy to consume, and can provide the data needed tailored to new consuming audiences, APIs are a great fit to unlock the value contained in this data.
When thinking about data use cases in our workshops, we go through the following discussion:
- What data are you collecting today and what audiences are viewing this data now?
- Is there another audience in the enterprise that could benefit from accessing the data that you have already collected?
- Is there some regulatory, privacy, or security concern about the access of specific data?
Once these answers have been identified, contacting the potential consumers to obtain their more detailed requirements can help define a better API.
External use cases
Many scenarios also exist to share data with partners or public audiences. For partners think about what information they need to access to do business with you. On the supply side, they might need access to inventory levels to replenish supplies or products. On the sales side, they might need access to submit orders, check order status, product lists, product detail, etc.
You might make a subset of this information available to public consumers, for example to participate in a comparison App. Other information that you make available on your web site is also a candidate for a public API. This information is already being made available to the public, but it is in a more difficult form to obtain programmatically. By making the information available via API, you can reuse this API for your own web site, probably your mobile App too, and make it available externally to a public audience all with the same API.
Completing the external category, there is also the possibility to monetize access to your data. Of all
the talk on direct monetization (charging per use of an API), this is the type of API that seems to be most applicable to this model. For this to work there need to be a set of (obvious) factors that are in place:
- Your data must be valuable to a potential consumer
- You must have the rights to sell the data. Based on the type of data you might only be able to sell it in aggregate or with customer opt-in to be marketed to by your partners.
- The potential consumer of the data must be willing to pay you for it (if it can be obtained elsewhere for less money or free they will not pay you)
- The appropriate metric to charge for the interaction should be via API call. If the metric is something else (e.g. the value provided) then a different monetization model may be more applicable. APIs can still be used, but you would not be charging per API call.
The data category of APIs is number one in the Forrester report for a reason. These are the basic business recognizable assets that form the purpose for APIs. Yes, there is overlap between the data category and most of the other categories since data APIs might be used in mobile, social, partner, and public projects. But many businesses think of Data as a category in its own right for exactly this reason; a set of data APIs can be used for so many purposes. Next up in the Use Case Category series – “Other internal scenarios”.
To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the API Connect website. And you can also experience a trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter @Arglick to continue the discussion.