API Management, Vendor Selection Process Best Practices.


The API Management vendors and products have recently evolved and grown and currently we have a large set of features and capabilities are offered by those multiple vendors. Also, those vendors can provide those features and capabilities using different approaches and techniques, which one to choose?

Throughout the years, working with customers in that space, I find many struggle with the vendor selection process, sometimes spending more time and effort that is significantly more than the way it should be. Fumbling and tangling with requirements and going in circles while working with multiple vendors.

Here are some high-level best practices that can help driving towards more efficient and effective vendor selection process.

Identify the business use cases

Identifying the business use cases is paramount to the API management initiative success, you need to highlight the business workflows and how the API management will benefit the business, how this is important to the vendor selection process though?

At the first glance, for someone didn’t go through the API management journey before, those two are unrelated, however when you go through the process few times you will realize that, the business case will determine many aspects related to the solution architecture and accordingly will help with identifying the requirements.

For instance, if you have a mobile focused business use case, where the business is looking for revenue generation opportunities through quickly introducing an E-Commerce Mobile platform, you would look for a vendor that can provide mobile enablement features.

The business use cases and the data flow will come handy throughout the process, including solutions architecture, vendor interaction and the Pilot or the PoC efforts, more on that below.

Identify the initial set of business and technical Requirements

The requirements identification is a long living process, dynamic in nature, and it will grow and change based on the discovery phase findings and what you learn from studying the API management products and through the interactions with the API vendors, you might discover new features or capabilities that you would consider as missed requirements, such as analytics, many wouldn’t realize the value of the API usage trends until they see it, or the functional team see it.

The requirements usually encompass the following areas,

  • Security and access control, which would cover, defending against DDOS attacks, throttling, quota management, authorization and authentications and access tokens management, mediation and transformation capabilities such as converting from SOAP to Rest or the other way around. Also, the same capabilities can support functional requirements such as defining access tiers with certain traffic limits, for instance, creating gold and bronze access tiers with separate financial structures.
  • Developer services, and that would cover API documentation, developer on-boarding and service life cycle management.
  • Analytics, where both the provider and the consumer can benefit from API usage trends and information, such as product consumption trends, which time of the year has the peak sales or the peak access from a certain geographic within certain time of the year or popular APIs and a lot more.
  • Additional facilities and features, such as mobile enablement, big data and predictive analytics, the ability to use legacy systems connectors and more.
  • The business use cases will give you another dimension where the priorities and the requirements can differ; for instance the business cases can vary from Product based APIs, B2B, mobile, distributed development or development partnership, IoT or other business use cases.

It’s important to identify as much requirements as you can before you start engaging the vendors, this way, you can enlist the vendor efforts in helping solving your own challenges. When the vendors gain good understanding of your business problems and fathom your requirements they can provide creative and innovative solutions using their products.

Test-drive the products

The industry analysts’ reports can give a good view into the vendor space, which ones are leaders, visionaries or followers.

Most of the API management vendors offer the opportunity to evaluate their products. Start signing up for webinars and sign up to use the products; the liking of the products depends on many factors, including the IT culture. For example; some would consider the UI/UX usability factor as an important one, some wouldn’t put much weight. Some would prefer a UI wizard approach, others would like to work with raw xml or scripts.

It’s important to test drive the API Management products and build your list of questions that you can run by the vendor when you start the vendor interaction.

Engage the vendors

Engage the vendors and schedule the technical demos back to back if you can; the vendor selection process has a momentum and it’s an advantage to have the technical demos back to back, this way the team can build a vivid and mental comparison which helps with identifying differentiators or a perceived shortcomings among those vendors and vendors’ products.

Update your requirements list based on what you have learned

The products’ features and what you learn during the vendor interaction is very valuable and can give you a lot of hints and introduce new requirements, update your requirements list to include the valuable items you learned from the vendors’ interactions.

Build a vendor scoring sheet

Convert your requirements sheet to a vendor selection scoring sheet by giving each requirement a certain weight according to your priorities, then start scoring the vendors based on your weighted requirements.

Identify Differentiators

By now, the vendor selection team should have learned enough to identify specific differentiators that relate the most to your requirements and your priorities, those differentiators can really vary from very sophisticated security requirements to the cost of acquiring or operating the solutions.

Create the Pilot

You should never make a decision on such a vital and central facility without creating a PoC or a Pilot, however, I prefer and recommend a Pilot to our customers whenever is possible, the reason is the elimination of the time, money and effort required to move the PoC to production, another approach is to run a PoC with the short selected vendors and move to a Pilot with the selected vendor.

Hire the SME

This should come first, early at the process, think of this as going on a trip, sailing through uncharted territories with no guide, it is a very high-risk approach, however the SME should have the following qualities:

  • Someone acquired the vendor selection process experience and worked the long list of vendors, currently we have at least five vendors who are on the leaders’ scope.
  • Hire an impartial and unbiased firm that is not in a partnership with a specific vendor and can navigate and interact with the vendors freely without any contractual or legal constraints.


Those are my personal views and not representing the people I worked with, the companies I worked for, or my/our past and present customers in any shape or form. Any resemblance to real life use cases or situations is accidental and not intentional in any way, shape or form.

Hope this is helping some and again I understand other’s experience and views could be completely different than mine and I completely respect that.