Continuing the API Economy Business Drivers and Use Case Categories series
this blog addresses the first use case category in the series - “Mobile”. A while ago I provided industry examples for APIs across the use case categories and you can find these linked from “API Use Cases for Every (?) Industry
”. Now I would like to share the methodology I use so you can apply this to your specific business.
Mobile is an extremely popular use case area for APIs, one that I see in almost every client I visit. And, it is often the first use case that businesses consider. There are several good reasons for this:
- Mobile is typically an initiative in the company already. Most companies have or plan to have a mobile App, and sometimes several targeted at various audiences (customer, employee, partner, etc.). In order for the Mobile App to be useful it needs to access data from the existing Systems of Record (SoR).
- Mobile developers are internal to the company. They either work for the company or are hired as contractors to build the mobile App. This means that APIs exposed to this audience are not exposed to developers outside the company (the Mobile App is, but not the APIs). At the beginning of an API initiative your API skills may not be as good as they will be once you have more experience. Keeping the early projects targeted at internal developer audiences allows for growth in your API skill set.
- Mobile developers are good at developing Mobile Apps, not as good at understanding complicated SoR. Providing an easy to consume API allows the Mobile App developer to be more productive.
- Speed – the Business driver we mentioned several weeks ago is the business driver for Mobile. Back end SoR systems cannot be changed frequently at the request of every new feature to be added to the mobile App, yet Mobile Apps may be changed on a very frequent basis. Allowing for each area to manage its own rate of change can be enabled via APIs. The Mobile use case area is the quintessence of the Speed business driver.
As with all the use case categories we should be thinking about the consumer perspective for any APIs we identify. In this case, the consumer is the Mobile App Developer. And, the key question to ask is: “what do they want?” To answer this question, think about any of the mobile Apps that you have on your phone today and the type of information these Apps provide. I think about the information that is provided in three ways: Generic information
Generic information is information a mobile App developer will put on the App that does not need to
know who the specific person is that is using the App. All App users would receive the same information. What kind of generic information would be valuable to put on your mobile App? Sample answers include:
Customer specific information / transactions
- Offering or Product catalog
- Information about the individual products/offerings: Product description, detail, picture, usage information, interest rates, historical data about the offering
- Offering comparison/assistant/selector
- Location information and Store Hours
As you might guess, customer specific information needs to know who the person is that is using the App
because we will be providing unique information to that person. Often this type of information needs higher levels of security. The App user must be authenticated and we must ensure that they are authorized to access the information. In some cases this may be their own personal information, but in other cases it may be a store manager acting on behalf of a client or a doctor acting on behalf of a patient. What kind of user specific information would be valuable to put on your mobile App? Sample answers include:
- Ordering or other transactions (e.g. transfer funds),
- Transaction status
- Shipping status
- Account management / Profile Management
- Account balance
- Order history
- Rewards points
- Recommendations (based on history, social, cognitive, or other)
This category deals with the integration of API information (as listed above) with some characteristic of the mobile device to provide value added benefit to the customer. Most mobile devices have several features that can be of value including the camera, GPS coordinates, access to the calendar, etc. Sample scenarios that fit in this category include:
- Using the camera to provide input to a transaction (deposit a check, take a picture of an accident for an insurance claim).
- Using the GPS coordinates to tailor information provided to the customer (find the nearest ATM, find the nearest restaurant, determine the weather at the user’s location)
- Access to the calendar for appointment scheduling
Mobile is an extremely popular use case area for APIs. In some companies, it is the only use case area identified as they begin their API journey. And, with mobile alone there is sometimes sufficient justification for an API initiative. But, don’t stop looking there! There are many advantages in the other use case areas as well. So, we will continue exploring how your business can take advantage of even more API use case categories. Next up in the Use Case Category series – “Social
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 discus#APIConnect#APIeconomy#APIEconomy#APImanagement#APIscience#APIstrategy#api_strategy#APIConnect#apimgt#apis#BusinessStrategy#experienceAPIs#FirstLook#GettingStarted#ibm#ibmapimgt#MarketTrends#Mobile#MobileApps