API Connect

 View Only

What is the Recommended Organizational Structure for an API initiative?

By Alan Glickenhouse posted Thu May 25, 2017 05:37 PM

Last week I wrote a blog on the recommended roles for an API initiative.  But, where do these API roles fit in the organization?  This week I’d like to address Organizational structure.  Let’s be clear that there is not only one way to organize that is correct for every company.  What is best for one company may not be for another.  I will provide some guidelines and share some observed best practices to help you decide what is right for your enterprise.

There are several factors to consider when thinking about how an API initiative might be positioned in your company:

  1. Your perspective, business drivers, and goals for the API initiative

  2. Your API maturity level

  3. Your existing organizational structure

Are changes required to the Organization?  Probably.  There are some new roles to be staffed and there is significant benefit to putting a focal point in place to help drive this as a digital transformation and not just another IT project.


Perspective, Business Drivers, and Goals:

The most successful businesses using APIs are viewing their API initiative as a new channel to market.  Their goals are to empower the business to execute faster, reach new customers, and provide business innovation.  Companies with this perspective are incented to change the organization to drive this success.

Other companies are recognizing that there is a new ground swell around Business APIs.  They are beginning to learn about APIs, but have not yet developed a strategy or identified business use cases.  Companies in this situation are probably not ready to make major organizational changes.  So, working the API initiative into something that does not require significant organizational change is probably more likely – at least initially.


API Maturity Level:

IBM introduced an API Journey Map as a maturity model for the API Economy.  In this we recognized as companies begin their API journey the initiative tends to be led by IT.  However, as the initiative matures it becomes a partnership between the business and IT moving to a business led paradigm.  Where are you on your journey and do you have the backing to push the initiative to the next level?

Think about the early days of the web (if you are old enough to remember).  IT led the initiative deciding what the web page would look like.  What does your web site look like now?  I’m betting the business is driving this as a channel to market for your company and IT is in a supporting role.  This same transition will occur over time in the API Economy.


Existing organizational structure:

While APIs are about disrupting the market, most businesses want to minimize the disruption inside the company.  The existing organization will be considered as part of the API initiative and adjusted as the initiative matures.  How independent are the Lines of Business?  Is there a separate IT organization for each LoB or a centralized IT (or something in between)?  How well do the business and IT work together?


So, what should you do?

If you believe that APIs are a channel to market, you should begin to position the organization to execute on this channel.

IT owns the infrastructure and processes to enable the channel.  This includes establishing the API Management solution (e.g. IBM API Connect) either on the cloud, on premise, or hybrid.  The architecture and security teams ensure the implementation is integrated with the current enterprise solutions.  Processes such as lifecycle management are driven by IT.  As defined in last week’s blog IT performs the API Developer and Operations roles.  Often the API Developer roles are centralized and frequently are related to prior IT integration centers of competence.  If your company executes with a decentralized IT, then it is not critical to change this organization.

The Business owns the API Product manager roles as defined in last week’s blog.  This includes the initiative owner and the API product manager role.  APIs should be defined by business need, not by current IT infrastructure implementation.  Also, API marketing to drive and measure usage is a business role.  The API Economy is about revenue generation not IT cost reduction, so Business involvement is critical.  I have seen many companies either not staff this role or keep it contained in IT.  Both of these choices limit the success of your initiative.  For internal use cases (e.g. Mobile), the Business often owns the IT resources playing the App developer role.


Most companies have multiple Lines of Business (LoBs) that tend to operate independently.  IBM API Connect supports this decentralized approach through two techniques:

  1. “Provider Organizations” can be used in a multi-tenant API Connect implementation. Choose this approach if the LoBs are extremely independent.  (Think General Electric selling light bulbs and aircraft engines.)

  2. “Spaces” can be used within an organization to allow LoBs to work independently, but then make their APIs available together so they are viewed as one company. (Think CPG companies with many product lines, but a consistent audience).

See the API Connect Knowledge center for additional information on this topic.


As you are establishing your organization to support your API initiative, remember one of the primary goals for most API initiatives is to improve speed of execution for business initiatives.  Is your organization supporting this goal?  If not, change is probably required.


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.



1 comment



Fri August 19, 2022 08:18 AM

When there is an organization which has multiple Business units and some of the APIs could be common then what should be the approach from Provider organization.
Should we have Provider Organization for each Business Unit and then catalogs for segregating the environment(Having 2 API Management Instances for Non-Prod and Prod). If we go with this approach how to bring common set of APIs to one place.

Please provide your input on this.