(Template) IBM APIc RFP
(Template) IBM APIc RFP
These are suggested RFP criteria to consider when selecting an API management vendor
Jump to…
Section A. Vendor Experience
Section B. Deployment, Architecture & Administration
Section C. API/Microservices Creation & Deployment
Section D. API Security, Traffic Management & Mediation (API Gateway)
Section E. API Management & Analytics
Section F. API Socialization (Developer Portal)
Section G. Security
Section H. Training and Support
Section I. Industry Experience
A2 How long has your corporation been selling and supporting your
APIm product?
A3 Does your corporation have global reach? How many offices do
you have around the world?
A4 How many customers do you have worldwide?
A10 What is your corporation total R&D budget and APIM-specific R&D
budget?
A11 Please describe how your organization has innovated or led in
domain areas. Please provide examples of each
A12 How many customers use your API offering - please breakdown by
industry
A13 Please describe the roadmap for your API & Integration Offerings
A15 Please describe how your offering integrates with ESB style or
other integration technologies using open standards and
automation
A16 Does your organization provide complementing integration
technologies that fit into the API management offering?
Return to Top
Section B. Deployment, Architecture & Administration
Req. id Requirement
B1 Do you offer a SaaS and on-premise versions of your APIm
offering?
B5 How many actual data centers around the world does your SaaS
offering run on?
B6 Does your SaaS and on-premise APIm solution support multiple
languages, e.g. English, Spanish, Chinese, etc.?
B7 Does your solution provide the same functionality and user
experience across different deployment options, e.g. SaaS multi-
tenant, SaaS single-tenant, on-premise, etc.? If not, please explain
what functionality is not offered on one vs. the other
C5 What languages does your solution support for the creation and
running of microservices, e.g. Java, Node.js, etc.?
C14 Please describe the markup languages that are used for API
development and how they are edited
C15 Is role based accessed enforced on developers?
C17 Does your API tooling allow the developer to model data?
C22 Can a developer work with XML & JSON as part of an API build?
C23 What are the primary languages that an API developer needs to
know in order to build an API?
C24 Can a developer expose a REST API from a SOAP web service?
C30 What level of error handling can an API developer add to an API
definition?
C31 Can a developer provide additional documentation such as
descriptions, contact info and terms of service?
C32 Can developers control the visibility of an API when it is published?
C33 Does your development tools use any open source products or
packages?
C34 Does your development tooling require licensing? If so how?
C36 How can your development artifacts be plugged into testing tools?
C37 Does your developer tooling enable auto generation of APIs on top
of back end systems or databases?
C38 Does your developer tooling make use of a widely used framework
or package in order to build APIs?
Return to Top
Section D. API Security, Traffic Management & Mediation (API Gateway)
Req. id Requirement
D1 Does the solution provide a secure, purpose-built gateway? Please
explain
D8 Can your API Gateway be used outside the context of your APIm
solution? Can your API Gateway be used separately from your
APIm solution?
D9 Does your API Gateway support XML, SOAP, WS-* related
standards natively?
D10 What other types of workload does your API Gateway support
beside SOAP and REST?
D11 How does your API Gateway support Node.js? Please explain
D12 What kind of rate limiting and quota enforcement features are
provided by your API Gateway?
D13 Does your API Gateway have any built-in capabilities for doing self-
balancing across a cluster of gateways and intelligent load
balancing to backend API provider layer?
D14 What security protocols and standards does your API Gateway
support?
D15 Does your API Gateway provide built-in support for schema
validation?
D16 Does your API Gateway provide built-in support for message digital
signatures & encryption?
D17 Does your API Gateway provide built-in security token translation?
D18 Can your API Gateway generate and validate JWT?
D20 Does your API Gateway support a FIPS 140-2 Level 3 certified
Hardware Security Module (HSM)? Does it support a networked
HSM?
D21 Does your API Gateway natively support other transport or
messaging protocols besides HTTP, e.g. MQ?
D22 Does your API Gateway support wire-speed, native JSON and XML
processing?
D23 Does your API Gateway support transport protocol bridging, e.g.
from HTTP/SOAP to MQ?
D24 Does your API Gateway support JSON to XML, XML to JSON and
Any2Any message transformation without any coding or
extension?
D25 Can your API Gateway convert between SOAP and REST without
writing code or providing extensions?
D31 Please describe the upgrade process for your gateway including
the impact to production runtime
D32 What level of operating system patching is required in order to
keep the gateway secure?
D33 Please provide a list of customers that use your gateway offering
D34 What operating system does your gateway sit on?
D39 Can your gateway redact fields in message payloads on input and
output?
D40 What level of error handling is available on the gateway?
D42 Does your gateway support POST, GET, DELETE, HEAD, PATCH &
OPTIONS?
D43 Can your gateway control, manage and shape API traffic? Please
describe the policies that can be applied
Return to Top
Section E. API Management & Analytics
Req. id Requirement
E1 What REST API Description Languages does your solution support?
And what REST API Description Language do you support internally
in your runtime?
E2 Please describe your support for Open API, i.e. Swagger. Does your
corporation belong to the "Open APIs Initiative", i.e.
www.openapis.org?
E3 Do you support the creation of REST and SOAP APIs?
E10 Does your solution support out-of-the-box policies for traffic quota
and throttling?
E11 Does your APIm solution include API analytics? If so, please
describe what API metrics are captured for analytics
E17 Can APIs be extended from their original endpoints to include new
functionality or data?
E18 Please describe how different environments such as Dev, Test,
Staging, Production can be deployed keep APIs in isolation from
each other
E19 Please describe how your API manager communicates with the
other components of your solution, such as the API Gateway,
Developer Portal, etc.
E20 Please describe how developer communities are managed?
E21 Please describe the role based access for management of the APIs
E22 Please describe the API build chain and how this can be automated
E23 Please describe how templates from other API definitions can be
used to create new APIs sharing common functions and operations
E29 Can the same APIs be deployed to both internal users and external
users but behave differently based on context?
E30 Can APIs be grouped in a way that allows them to be consumable
by specific audiences?
E35 Can trends of usage be analyzed over time using the tooling?
E40 Are there maps available in the dashboards for detailing geo-
location of API calls?
E41 Can API call performance be reported in the tooling?
Return to Top
Section F. API Socialization (Developer Portal)
Req. id Requirement
F1 Does your Developer Portal include built-in social capabilities, such
as Forums, Blogs, API ranking, API comments, etc.?
F25 Please describe the upgrade process for your Developer Portal and
the impact it has on production runtime
Return to Top
Section G. Security
Req. id Requirement
G1 Does your APIm solution include security capabilities to manage
Users, Roles, TLS Profiles, and User Registries? Please explain
G11 Does your API Gateway support FIPS 140-2 Level 3 and Common
Criteria EAL4?
G20 Please describe how granular your system access can be defined
G21 Please provide the level of control and visibility users can be
granted
G22 Please list all recent vunerabilities that your offering had to be
patched on to become secure e.g. heartbleed, openSSL,
ShellShock, Data Loss, Drown
G23 Please highlight other security features that come with your
offering that would be of benefit to us
G24 Please provide a list of all security accreditations for your offering
G25 Does the offering support HTTP/S?
G29 Please describe how the interation between developers and the
published APIs are secured
G30 Please describe how you ensure platform security on your cloud
offering
G31 Does your offering supply any OAuth testing tools?
Return to Top
Section H. Training and Support
Req. id Requirement
H1 Please describe the support model your organization provides
Requirement Description
We would like to know your corporation trajectory in the industry
Requirement Description
We would like to know if your APIm solution is available in SaaS
and/or on-premise
Requirement Description
We would like to know if your solution supports the concept of
models to support the automatic creation of REST APIs
We would like to know the different ways your solution allows the
modeling of data
We would like to know the different ways your solution allows for
schema validation
We would like to know all API security-related policies your
solution
We would like to understand your solution capabilities to create
and develop policy flows
We would like to know the differences between your cloud and
on-premise developer experience
We would like to know if your solution supports XML and JSON for
API development
We would like to know what language(s) your solution supports
for API development
We would like to know if your solution is capable of exposing a
backend SOAP web service as a REST API
We would like to know if your solution is capable of exposing a
backend REST API as a SOAP web service
We would like to know if your IDE allows for deployment to either
cloud and/or on-premise environments
We would like to understand the ways your solution can consume
APIs already exposed by other systems
We would like to understand your solution capabilities to create
and develop policy flows
We would like to understand the granularity of policy application
of your solution
We would like to understand your error handling capabilities, e.g.
error handling policies
We would like to know what other documentation your tooling
allows a developer to specify for APIs
We would like to understand your solution API publication
capabilities
We would like to know your dependency on open source software
n (API Gateway)
Requirement Description
We would like to understand your API Gateway internal design to
understand how it can perform, scale and protect against
vulnerabilities . Does it use non-blocking, even-driven I/O
architecture? Is it protected against Java vulnerabilities? Does it
provided high-speed and native processing of JSON and XML
payloads? Is your API Gateway optimized to its underlying
hardware? Does it come with an embedded operating system and
optimized application layer? Is its image signed and encrypted?
We would like to know if your API Gateway can handle XML, SOAP
related standards, including WS-*, natively
We would like to know the breadth of workloads supported by
your API Gateway supports
We would like to know the ways API traffic is reported by your API
Gateway
We would like to know if your API Gateway has built-in capabilities
to be segmented
We would like to know all the ways your API Gateway can cache
API responses
Requirement Description
We would like to know all the DLs your solution supports
We would like to know all of the pieces of data that your solution
collects for API analytics
We would like to know how your solution can publish an API from
an internal to an external endpoint
We would like to know all the ways your solution can discover APIs
We would like to know how policy flows are supported for APIs
Requirement Description
We would like to know what social capabilities your APIm solution
comes with
We would like to know what API test tools you provide in your
solution
We would like to learn about all plugins your solution offers for
your Developer portal
We would like to know if and how your Developer portal can be
extended by open source technologies
We would like to know if your Developer portal has a REST
interface and what functionality it covers
We would like to understand the upgrade process for your
Developer portal
Requirement Description
We would like to know the extent to which your solution supports
the management and administration of security-related items in
the platform
We would like to know how many and what the roles are that your
APIm solution supports out-of-the-box. Also, we would like to
know what activities each role is capability of carry out
We would like to know if your solution supports user registries
such as LDAP, SCIM, etc.
We would like to know your solution's management capabilities
for dev organizations, applications and subscriptions. In addition,
include your capabilities to do the same with dev organizations
from third-party cloud providers
We would like to know any other security features that you think
would be useful to us
We would like to know all security certifications of your solution
We would like to know whether or not your solution supports
HTTP/S
We would like to know the details about how policies are authored
We would like to know the details about how policies are enforced
in your solution
We would like to know all your security mediation capabilities
We would like to know how your solution secures the API calls app
developers make
We would like to know all the security certifications and
accreditations of your cloud offering
We would like to know whether or not your solution offers OAuth
testing tools
We would like to know if an API developer can create an OAuth
provider endpoint
Requirement Description
We would like to know about your support processes
Requirement Description
We would like to know how you envision APIs playing a part in
solutions in the industry
We would like to know that you understand the industry
dynamics, where the industry is headed, and can provide industry
solution perspectives as well as support industry ecosystem
opportunities.
Updated: February 27th, 2017
Rationale
We want to make sure the vendor is solid and will not be acquired
or disappear from the market in the long-term
We want to understand the experience of the vendor developing
and selling their APIm product
We want to make sure that the vendor will be able to support our
offices all around the world
We want to understand the vendor's market leadership worldwide
Rationale
We would like to adopt a hybrid cloud environment where some
of our development and deployments can run on-premise and
some on cloud. In addition, we may do dev and test on cloud
version of vendor's APIm solution and deploy production on-
premise
Rationale
We want to know if vendor uses an underlying technology for the
creation of REST APIs that speeds up application development
Rationale
We want to make sure the vendor's API Gateway design and
implementation enables it to be scalable and have high-
performance while being secure
Rationale
We would like to know what other DLs the vendor supports.
Swagger, the market de-facto standard for REST APIs is of special
interest to us
Swagger is widely used in the market more so than any other DL
and we would like to make sure vendor is committed to this
standard
These two standards are the most common and easiest to use for
API consumption
We would like to know OOTB integration points with other
products for API management that speed up development and
time-to-market
We want to know whether or not vendor supports message
mapping from their browser-based UI or from a fat client that
needs to be installed on a developer's desktop/laptop. Or both.
Message mapping capabiliites at the browser-based UI speeds up
development
We want to know all of the API metrics that the vendor's solution
collects to get insight into what kind of analyses we can do
We have many LoB units and may have the need to support all
these organizations under a single catalog in the vendor's APIm
solution
We want to ensure vendor's solution provides hybrid integration
capabilities
We want to a solution that can easily discover and bring APIs into
management
We want to ensure vendor's solution API policy application is easy
Rationale
Nowadays, social capabilities are heavily used by Internet users,
including App developers. Social tools are a great source of
information and provide a network of knowledge to users
We want to make sure the vendor is using a good underlying
platform for their Developers' portal solution. We also want to
make sure that vendor is not using a Beta or Alpha release of some
other open source project not heavily tested in the market
Rationale
We want to ensure that the vendor's solution offers out-of-the-box
security management and administration capabilities
A rich set of roles and Access Control List (ACL) capabilities will
secure and speed up the adoption of the vendor's APIm solution
Rationale
We want to ensure that vendor has a good support model in place
Rationale
We want to ensure that vendor has a view as to how APIs support
business solutions
We want to ensure that vendor can take us beyond initial use
cases
Response
Response
Response
Response
Response
Response
Response
Response
Response
Last update:
These are suggested RFP criteria to consider for Financial and Banking
Section B. Secutiry
A13 Please provide your view on how 2-factor authentication will work
for PSD2 & Open Banking
Section C. API Gateway
A14 Please provide a list of customers that use your gateway offering.
Those in financial services and banking would be higher priority
#VALUE!
16-Dec-16
l and Banking
Requirement Description
Rationale
Response