Continuing the API Economy Business Drivers and Use Case Categories series our next use case category is Partners.  Let me define what I mean by partners, since my definition is probably a larger group than you might expect.  By “partners” I am referring to other companies that are known and approved by you, who you hope will consume your APIs.  This can be partners in the traditional sense as in supply chain or sell-side partners.  But it could also be large customers of your business that wish to tightly integrate with your services – for example commercial banks and their large clients.  The common aspect is that you will make selected APIs available to this pre-approved audience so they can use these APIs directly in their applications.


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.

 

Partners are already accessing my services

Whenever I bring up partners as a use case for APIs inevitably someone says that they already have partners accessing their systems.  This is clearly true.  However, the argument is much like in the 1990s saying you don’t need a web site because customers can already buy things in your store.  There are different modes for partner interaction and capabilities such as EDI or file transfer that are batch or bulk oriented and these are not disappearing any time soon.  Even partners who are accessing your systems through exposed SOA Services or MQ interfaces might continue to do so (although these may benefit from an API controls for security and rate limiting).  I’ve expanded upon this positioning in an earlier blog that I wrote – here.

 

The Multiplication Factor

Without APIs, bringing on a partner is very time consuming for both you and your partner.  After you agree to become partners at a business level the technical work begins.  Exposing interfaces that your partner needs, setting up appropriate visibility into your data, setting up security, testing, and then teaching the partner to use the interface and further testing.  The effort can take weeks or months and at the end of this you have 1 new partner.

 


With APIs, we plan for the type of partners we will on board and create and test the necessary APIs that they will use in advance.  Once our companies agree to become partners the new partner is given access to the developer portal.  After minor security set up to allow access to the portal our work is finished.  The partner accesses the portal and through self-service consumes the APIs they need.  This allows partners to be brought on far faster.  With this low touch approach to partner on boarding we multiply our reach.

 

Identifying Use Cases

Specific use cases vary by industry and the type of partner or large customer that is targeted.  Some of the things to look for in identifying APIs include:

  • Do you have a B2B portal? If so, many companies you work with might prefer if you exposed the
    information and transactions via API.  By using your API, they can embed the call directly in their applications rather than have a person re-key information from their systems into your portal, obtain results and type the retrieved information back into their systems.  Note these same APIs can potentially be used by your B2B portal as well.
  • Do you expose existing services to your partners (in the more manual mode described earlier)? Looking at these as potentially reusable APIs is a good starting point.  While existing partners may continue to use the same interface, on boarding new ones in a more self-service manner would be helpful.  Also, you might create an API with the exact same interface as the Service for the existing partners.  This allows the interface to remain the same causing little rework, but enhances your security and analytics around the usage of the service.
  • If you are using batch or bulk communication with partners via EDI or files we will not replace this with APIs. However, there may also be some smaller, real time scenarios that may be required for these partners and would be better served via an API.
  • Thinking about having partners in a larger quantity where establishing EDI with each one is not feasible, is there an alternative through APIs that could be used for smaller partners?
  • Are there new types of partners that you could benefit from bringing on board? See my discussion on the “business next door”, and if so what type of information or transactions would they require?
  • Client integration through APIs should be extremely attractive to both you and your client. In the case of the client, the manual efforts are replaced with automation.  In your case the client becomes very “sticky”.  Once they imbed your APIs, it is much more difficult to switch to another company.  So, what APIs would be necessary for your clients to invoke from their applications?

 


Partner API scenarios are the exciting!!!  The multiplication benefit of having tens or hundreds of partners all accessing your APIs can drive tremendous additional revenue.  This is what we mean when we say “API Economy” where companies form an ecosystem to provide better services for the consumer and increased business for all involved.  Next up in the Use Case Category series – “Public”.

 

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.

Join The Discussion

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