How to select an API Management platform for your business — part II
Let’s grow the API Platform adoption within the business
Introduction
In part I of this tutorial series, we discussed the business needs of an API Management platform and how to get started with a simple API gateway that exposes the business functionalities as protected APIs. In this second part of the tutorial, we will discuss the aspects of growing the API Management adoption within the organization and what features are essential for that growth so that you can select the best possible API Management vendor for your solution.
How to make your APIs popular?
Now you have opened up a certain limited set of functionalities and data (as information) to the users (both internal and external) over APIs and people start using it. Given below are a couple of examples where organizations have used APIs to improve their business processes with gateway functionality.
- An Insurance organization exposed a set of APIs to insurance brokers to register new deals as well as generate quotations for customers. This saved a lot of time and effort for brokers as well as for the organization.
- A manufacturing organization exposed a set of APIs to resellers to check the availability of certain products in the manufacturing lines and make their decisions on orders and pickup based on availability. It helped resellers to plan their sales, orders, and transport arrangements.
In both of the above cases, APIs helped an organization to improve their interaction with the partners who play a pivotal role in the entire sales process.
The next step of reaching out and growing your business is to expose certain functionalities to end-users or customers. There are different approaches to reach out to new customers. One simple method is to develop a mobile application and publish that in mobile app stores like google play store and apple app store. But that requires you to carry out a whole set of new marketing efforts to make that application popular. Some organizations with big brands may be able to do that. But not possible for many organizations.
That is where the concept of an API marketplace comes into play. Instead of you alone trying to make use of the APIs through a mobile or web application, you can expose the APIs to a whole set of other businesses and application developers to build value on top of those. To do that, you need to have a place where these 3rd parties can come and discover your APIs and interact with your internal API publishers. An API Store or a Developer Portal does just that. Let’s see how it interacts with the overall architecture.
As depicted in the above figure, the developer portal allows external developers to make use of the APIs and build better experiences that are integrated with their current applications. As an example, if you are an insurance organization, now car sale companies can use your APIs and build an integrated experience for car buyers to get the insurance directly from their car selling application. Isn’t it amazing?
Let’s try to understand the basic functionality of a developer portal to get started. Here are some of the fundamental features of a developer portal.
- Provides a catalog of APIs where users can search and browse easily
- Provides a comprehensive representation of the API and its usage using relevant documentation
- Provides a mechanism to test the API functionality (optional)
In addition to the capabilities mentioned above, there are certain advanced features you would see in existing API management products that will increase the overall efficiency of the interaction with the external developers. Some of those features include
- Ratings, reviews, and comments capability for each API
- Ability to share the APIs through social media
- Analytics on API usage
- Fine-grained API security configurations
- API monetization
You should consider these advanced features based on your need.
How to expand your API strategy within the organization?
So far so good. Now you have exposed your business functionality to partners first and then to a whole new set of users who will eventually become your customers. Don’t get frustrated with the conversion rates from those external sources at the beginning. As an example, you will see that only 0.1% of users coming through these external applications are actually becoming customers at the beginning of this effort. But this relative number will become huge when your absolute figures grow into large numbers.
Let’s think about a scenario where you have multiple departments (or BUs) within your organization and most of these other departments are not directly interacting with the customers. There is a good chance that the IT departments of that BUs will not see the value of an API platform from the outset. You can consider those as partners and explain to them the advantages of both partners and the business experienced during the early stages of the API adoption. You can onboard other BUs in a phased manner.
Let’s assume that the accounting department of your organization is ready to onboard into the API platform and they wanted to not only become a consumer of the APIs but also to host their own APIs for internal usage. The simplest way to support their requirement is to take the API requirements from the accounting department and develop the APIs and release that to the API platform under the supervision of the main team who is managing the API platform. This is good to start with. But this approach creates a lot of bottlenecks in the process and agile development practices and delivery practices cannot be followed by this approach.
That is where the concept of API Federation comes into play. Instead of having a central team who is managing the entire platform, you should be able to federate the API platform according to the needs of different departments or BUs. The platform should be capable of providing the required independence and agility to other BUs to develop and maintain their own set of APIs and security policies. This does not necessarily mean that you should have a separate deployment of an API platform for each department. Rather, you can share the same API platform across multiple departments using a concept like “multi-tenancy”. That provides flexibility while keeping the cost factor low and makes it easy for other departments to adopt the API platform without worrying about huge cost increases.
As depicted in the above figure, there is a new set of APIs deployed into the API gateway which is specific to internal business units (or departments). These APIs were developed by the developers of the respective BUs and deployed into the gateway so that only the departmental users can view those APIs in the developer portal as well as execute those APIs in the gateway. These are some of the crucial features of an API platform if you are going down this route.
This requires specific role-based or group-based access control capabilities at the gateway level as well as similar visibility controls at the developer portal level. Most of the existing API management vendors support this requirement through the “multi-tenancy” feature.
That’s all for the Part II of this tutorial series on selecting an API Management Platform for your business. Part III of the series will talk about making the platform future-proof and taking the final decision by considering both technical and non-technical aspects.
