API Connect

Continuing the API Economy Business Drivers and Use Case Categories series our next use case category is “Other Internal Scenarios”.  Clearly my creative juices were not flowing when I came up with the title for this category!  But, rather than drag this out over many more weeks, I am going to group several additional internal scenarios into this single blog creating a pot pourri of scenarios that we see being implemented by companies targeting developers inside the company.



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.

 

Regulatory Requirements and Industry Standards

Early last year I wrote a blog on Industry Standards and Regulatory Requirements which outlines some of the nearer term regulatory/industry requirements and where this is going.  I won’t restate all of this here, because this blog is focused on how to identify the APIs for this scenario.  One might think that API identification is easy for this scenario because the regulation or industry standard defines the APIs required.  To some extent this is true.  However, knowing what API needs to be created and meeting the necessary requirements for security, privacy, and making this work in your specific enterprise architecture takes this effort to another level.  Add in the need to meet specific deadlines for deployment and the late date agreements on finalizing the API definitions and this can be quite a challenge!

Also, important to note that this area is not always internal.  Often regulatory requirements (e.g. PSD2) and industry standards (e.g. HL7) deal with the industry ecosystem and are intended to help multiple participants in the ecosystem work together.  So, this is a bridge use case category to some of our upcoming scenarios dealing with sharing APIs outside the company as well.

My advice for this category is to obtain assistance from IBM.  IBM has skills and assets aligned to the industry / regulatory API requirement and can share this experience with you.  Trying to reinvent the wheel when IBM has done this elsewhere will be far costlier.  For further information please consult our IBM Cloud Professional Services, API Practice at wwintegr@us.ibm.com.

 

Audit and Security

While less business oriented than many of the other use case categories, the architecture and characteristics of APIs as a point of control to access assets provides a valuable place to execute on audit and security needs.  By establishing APIs as “the” mechanism to access assets and not allowing alternatives, audit and security functions can be centralized at the API layer.  Some companies are implementing internal application to application managed APIs in addition to the normal context of “business APIs” that are being exposed for business level development needs.

 

Things to consider when identifying this type of API are:

• What audit or security requirements exist for access of data and transactions?


• What if any current mechanisms are in place and will the APIs be a replacement for this or enhancement for new access only?


• Is there value in knowing the level of usage or limiting the access to specific business assets?


• What audience needs to access the audit information and how will this be accomplished?


• Is the http protocol acceptable for audit or is more stringent transactionality required?


• Is there a requirement for chargeback or show back accounting?

Be careful to use APIs appropriately.  Not every program to program call needs to go through a managed API.

 

Domains

A few weeks ago, I covered the API Economy business driver called “domains”.  Assuming this is a business driver for you, then internal use cases related to this are required.  As with all the other use cases the recommendation is to begin with the consumer perspective.  Here is a list of questions to consider when defining APIs for sharing across domains:

• What information does the consumer organization want/need that you have?


• Is any of this information private or regulated?


• Is there a need to audit or secure the information as it flows between organizations or geographies?


• What levels of usage does the consuming organization require, can the systems of record as deployed handle this, and will there be internal chargebacks for this level (or higher levels) of usage?

Once these questions are answered the API developer can determine the sources for the necessary information and any customization efforts that might be required to meet these needs.

 

While this hodgepodge of internal scenarios jumped around a bit, the collection does have one thing in common - these are very common scenarios.  Because of the absolute necessity of meeting regulatory or industry standards, or the internal focus of Domains, Audit, and Security, these scenarios are frequently some of the earlier projects taken on when API initiatives are started.  Next up in the Use Case Category series – “Partner”.

 

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.