API Connect

Most businesses have organized themselves internally as multiple lines of business (LoBs).  Separating in this manner provides all sorts of business benefits, but often introduces questions in API initiatives about when and how to cross the LoB boundaries.



When it comes to managing APIs, there are several areas where LoBs need to be considered:

• Sharing information across LoBs


• Company-wide Organization and Roles supporting API initiatives


• Appropriately exposing APIs to consumers

 

I’ve already covered the first two of these, but will recap them here and then move on to the third item as the primary additional content for this blog.

 

Sharing Information Across LoBs

This topic was discussed in my Business drivers and Use case series in the blog that covered the business driver called “Domains”.  In this I discussed how many businesses want to enable each LoB to operate independently, but also need to or would benefit from sharing information across LoBs or to the larger corporate entity through APIs as a secured controlled interface.  APIs allow the individual LoBs to supply appropriate information access in an easy to consume manner to other LoBs while allowing for appropriate security and capacity management.  Implementing this cross-LoB sharing is often a business driver for APIs.

 

Company-wide Organization and Roles supporting API Initiatives

What are the roles and organizational structure to put in place across multiple business lines, to support API initiatives?  I covered this across two blogs, the first focused on Roles, and the second on Organizational Structure.  In the Roles blog, I introduced the Product Manager role which represents the business orientation required in defining APIs and bringing APIs to market as a product. This role is frequently staffed within the individual LoBs.  Business application developers who consume APIs may also be business oriented and report into LoBs.  Additional roles for API developer and Operations are IT oriented and potentially shared across LoBs.  In the organizational structure blog, I described a shared central IT infrastructure and support organization with the LoBs owning the business oriented roles.



 

Appropriately Exposing APIs to Consumers

This concern deals with the ease of access to APIs by targeted consumers.  The question is how to provide independent API management for the LoBs, yet behave like a single company to the outside world.  Does it make sense to expose your internal LoB organizational structure to the outside world?

 

Let me start by positioning API consumer audiences.  There almost certainly will be APIs that are targeted toward internal LoB consumers that are not appropriate for other LoBs or external audiences.  Any API Management solution needs the ability to support restricting visibility and access to these APIs for this intended audience.  There may also be a need to provide secure control of APIs targeted to other LoBs.  This may be for capacity, security, regulatory requirements, or simply because the other LoB has no need for these APIs.  This is the “Domains” driver I mentioned earlier.

 

The focus for this question is external consumer audiences - either partners or public API consumers.  How will your business expose APIs owned by individual LoBs to this external audience?  Should the audience see separate API portals that represent each LoB or should the business have a single portal where all the LoBs publish their APIs for consumption?

 

The answer as usual is, “It depends”.

 

What it depends upon is the API consumer.  What does the consumer want from your business?  If you would cause the consumer to logon to multiple portals to obtain all the necessary APIs because that is the way your business is organized, then this is not acceptable.  But, if the LoBs are completely unalike, and the target consumers for different LoBs are not the same person, then separation of the APIs by LoB may be acceptable.  For example, in a company that spans many industries such as General Electric, the APIs for aircraft engines, healthcare, and light bulbs probably have different audiences.  In this case if each LoB published their own APIs to separate portals (or restricted the API visibility within a single portal based on the audience), no consumer would care because everything they are interested in would be within their view.

 

This, however, is not typical.  Most businesses have more alignment across their LoBs.  For example, in Insurance even though there may be separate LoBs for homeowners, automobile, and life insurance, these are all insurance products and the target consumer may cross many of these LoBs.  We do not want to make this consumer look in 3 separate portals or logon to 3 separate places to find everything they need.



While we want to provide this single view for the consumer, we may still want to support each LoB driving their own API initiative, managing their own API product lifecycle, subscription approvals, and analytics data.  This is supported in IBM API Connect using “syndication”.  With syndication, you can partition your API catalogs into “Spaces”. Each Space is used by a different API provider development team (e.g. LoB) and has its own set of management capabilities relating specifically to the APIs that the associated team publishes to that Space, enabling each team to manage their APIs independently.  In this scenario when you stage or publish an API, you specify the Space within that catalog that you want to stage or publish to. However, potential API consumers that access the Developer Portal are unaware of the Space partitioning and see the APIs as a coordinated offering spanning the complete business.  For most businesses having this single face to the outside API world is preferable.

 

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.