API Connect

Continuing the API Economy Business Drivers series this blog addresses the fourth business driver in the series - “Domains”.  Unlike the first three business drivers (Speed, Reach, and Innovation), Domains is most often an internally focused business driver.  I use the term “domain” to describe an area of the business that is separate from other areas of the business, often relatively independent, yet there is a need to share information across the domains or with the larger corporate entity.  There are two primary examples of Domain scenarios and this blog will cover both – “Lines of Business” and “Geography”.



Lines of Business

Often Lines of Business (LoB) need to or would benefit from sharing information across boundaries.  Note that this is a separate discussion than each line of business independently managing its own APIs for other purposes (i.e. speed, reach, and innovation) which is also common.   Many companies attempted to accomplish this cross-LoB sharing using Services while implementing SOA (Service Oriented Architecture).  Some companies were successful in this endeavor, others not as much.  There were several challenges in sharing Services across LoBs:

• Costs – who is going to pay and how much? While one LoB may have built the service for their own purpose, there may be a limit to how much they want to share this capability without some kind of charge back accounting.  If the additional capacity required by other LoB access requires additional costs then there is often a need to share the financial burden for the operation and maintenance of the shared service.  APIs can track this and feed into the accounting systems for each LoBs usage.


• Rate Limits – another solution to the prior issue is to rate limit how much additional LoBs can use. Again, this is a core principle implemented through APIs.


• Effort – On boarding additional LoBs can be difficult. Often Services perform many functions and Web Service interfaces may not be simple to use.  Security must also be established to allow for the sharing.  Through a self-service portal and consumer oriented APIs providing only what the other LoB needs, the sharing can be much easier – for both LoBs.


• Security / Legal / Audit – In some cases there are legal requirements as to what information can be shared across LoBs.  For example in healthcare protection of personal / private information may not be sharable, while some information can be shared.  APIs provide a secure mechanism to allow for a specific subset of information to be shared in a secure and audit-able way.

Companies who have implemented Services to have a single view of an asset (customer, account, order, etc.) may find that adding APIs to access these Services facilitates the goal of sharing the information across the enterprise.

 

If your company has not implemented SOA, don’t panic.  It is not a requirement to get started.  Many companies who have not implemented SOA start with an API (consumer oriented) view and drive this directly to the back end systems.  You may have more work if your assets are spread across many systems than someone who has already implemented Services, but it is not a requirement to build all the necessary Services first.

 

Geography

Geographic separation of computing has been a requirement of many companies for a long time for reasons such as disaster recovery.



Additional reasons for geographic distribution of resources includes latency, data residency requirements, or due to historical reasons from mergers and acquisitions and skills.  In addition the trend to move to the cloud is creating a geographically dispersed IT infrastructure.

 

There are many mechanisms to connect multiple geographies together, and I am not suggesting that APIs are the only mechanism or necessarily the best mechanism in all cases.  But, looking at some of the values that APIs bring such as Security, Rate limits, Audit, etc. these may be valuable considerations as you think about how to integrate across geographic locations.  Often API usage to bridge geographies may be in conjunction with another mechanism as a front end to secure and audit the transfer of information.

 

Domains as a business driver tends to be more exciting to IT organizations than business people as it solves many of the IT concerns involved in sharing information across the enterprise.  For that reason, it is often one of the early drivers in IT driven API initiatives.

 

This blog completes my list of business drivers mentioned in the series opening blog.  In my experiences I’ve been able to group most initiative drivers into these four categories.  What other business drivers are you seeing?  Next up we will start with the Use case categories delving into how to identify use cases in each area.  The first in the series is “Mobile”.

 

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.