Are you positioned for success with your API initiative? What roles are required to drive a successful API initiative? How do these roles relate to existing roles in the company? A long time ago (September 2014) I wrote a blog on
Organization and Governance of API Initiatives. Looking back on this now, I am still happy with the recommendations I made at that time. Now it is time to drill a little deeper and add some additional thoughts. If you have not yet read the prior blog I suggest you read that one first.
In the original blog I identified three roles for an API initiative – API Product Manager, API Developer, and Operations. Are there really only three roles required? No. The three roles were a good way to summarize the categories of roles required. However, in all likelihood there will be multiple people in each role taking on some of the duties covered in the larger role category. This will certainly be the case as your API initiative grows. In the IBM API Connect product we
identify many roles which allows for the control of permissions at a more fine grained level. However, it is also possible that a single person may fill multiple of these roles.
Looking at the three categories (plus one more), let’s break this down further:
API Business/Product Manager – Most of the time in discussing this role I am focused on the person/people who identify business needs to be addressed by an API, work with the developer role to specify the API, set the terms and conditions for accessing the API (rate limits/security/monetization), and market (communicate) the API to the intended audience. They also, of course, care about the success of their APIs. So, they are viewing analytics about their APIs to see what is working and which ones might need some additional effort.
There is a second key role under this category which is the API initiative/strategy leader. This role is working at a higher level than the API product manager, driving the entire API initiative for the company. They will be looking more strategically at the overall business goals, driving organizational change and governance, determining the strategy, and measuring the overall success of the initiative. For this role leadership and communication skills are critical.
API Developer – The focus of this role is the technical implementation of the API. While thinking of this as one role, there are often
several skills that are required and this may lead to several personnel being assigned with each specific skill. There is an API interface developer who deals with the Open API standards (Swagger, REST/JSON) and/or SOAP/XML. There may also be experts in integration to connect to internal and external resources including SOA related assets such as Web Services, databases, packaged applications (e.g. SAP), cloud applications (e.g. SalesForce), or other cloud APIs (e.g. Google Maps). And, there also may be Microservice coders who introduce new or changed business logic in languages such as Node.JS, Java, Swift, or others.
Also in this category are the architecture and security roles who are defining the plan for the environments and how the API implementation will fit into the existing architecture and security framework.
Operations – The operations role handles environment and organization operations and ongoing support for the execution of the API Connect product. The role is concerned about scalability, availability, performance, etc. As such establishing the environments and monitoring them is a key task.
Another role in this category deals with the DevOps aspects of the API lifecycle. This role may handle promoting APIs into production and the approval process for API consumers (see the next role).
App Developer – In the original blog I did not cover this role. It was implied that someone would actually use the APIs that were created.
However, more focus is required on just who this might be since their needs are what should drive the API creation. Saying that the developer is an internal developer is not sufficient. In the
Forrester Total Economic Impact study, Forrester consulting queried customers across four types of internal projects: Mobile, Social, Data, and “other” (which includes regulatory requirements, standards, audit, and more). Each of these audiences has different requirements and therefore needs separate focus from an API Product Manager. More than likely these API consumers are different people from different internal organizations.
External audience App Developers also need focus. Depending on your industry you may have supply side and sell side partners who would have different needs from your APIs. And, public APIs need special marketing to reach an audience with which you have no prior relationship.
The actual number of people in these roles will vary. Early in the initiative a person may wear many hats. Certainly early on individuals may execute multiple roles within a category and perhaps even across category boundaries. But as the initiative grows and becomes more engrained in how the company executes, the number of personnel participating will increase and individual people will not be crossing the category boundaries. It is best to think of each of the roles as a team of people, not just one individual. This way when establishing the governance and processes you will account for many people interacting to drive the success of the API initiative.
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.