We're good with things like API hosting, console features, etc. However, compared to Azure API, IBM API Connect lacks some things offered by the other platform.

I wish it covered the entire API lifecycle, including governance and management, more comprehensively.

It's based on a little bit dated architecture. A lot of evolution has happened after that. It's an evolving field. Kong is a Kubernetes-based platform. Kong runs on Kubernetes, but all the other ones are in microservices. So, there's a lot of improvement that can be done.

It would be nice to have a SaaS solution that can be deployed into the cloud.

Understanding the architecture, deployment criteria, and communication methods of the installation can be time-consuming. The learning curve is noticeable, especially for new engineers.

There are two disadvantages to the solution. Firstly, the pricing model, when compared to other open sources, is high. Secondly, the availability of resources in the market, specifically the developers available in the market, is not so much. So, the aforementioned areas need to be considered for improvement.

The only disadvantage I can see is that it requires heavy hardware support, which can be considered quite expensive.

In terms of new functionality, I think the analytics can be improved in V10. The analytics feature was better in the older version, 2.18. But in V10, it's not as flexible. When exporting analytics as KSP or JSON, it's not well formatted. They can work on enhancing the analytics part. Additionally, they can focus on reducing the hardware cost.

The implementation process could benefit from improvements, as it may take some time to become accustomed to the deployment.

I am currently investigating the weaknesses of the solution, specifically in its on-premise infrastructure. One of the main concerns is its performance, as we have noticed some cases of resource consumption that may be related to our setup. We have concerns regarding the handling of asynchronous APIs and events in the architecture, particularly in the financial sector, where this is becoming more common. While this is well-addressed in MuleSoft, we are uncertain about how IBM API Connect handles this use case, as it does not appear to be addressed in the available documentation.

Technically, I haven't faced any issues or areas for improvement in IBM API Connect. There wasn't any concern that the customer asked that we couldn't resolve or achieve. I'll need to check with the technical team if there was any issue with the solution, but from the top of my head, I haven't faced anything that the customer requested or anything that needs enhancement in IBM API Connect.

The implementation of IBM API Connect is complex, as it's an enterprise solution with many components that require more than one person. It's not a single product that you work on, and this is an area for improvement, but normally, it's good.

Having a more structured model for IBM API Connect support is also room for improvement that would help customers better.

Having more integration and compatibility with different platforms is what I'm expecting in the next release of IBM API Connect.

The issues with this solution are mainly around support. Recently, people were discovering that WSO2 is commercializing it, because initially it was just open source. Right now, because they are commercializing it, the intro licenses are as costly as IBM. People say: "IBM is tried and tested", so it's people who know this who'll go the IBM API Connect route. Other people who just want to try out a more scalable solution, on the other hand, will go the open source route. Others will either just do the cloud version, because everything is less maintenance, while other people prefer doing everything themselves, e.g. in-house, from scratch.

IBM API Connect should offer more versatility to its users, because they only give you a specific level of the versatility, and this is something IBM should heavily invest on.

Regarding IBM API Connect, I have to think about what needs improvement in the future because there are a lot of products that have recently come into the market. The analytics part of the solution is an area with certain shortcomings where improvements are required.

The product's setup phase and its setup for the users in different environments, along with DevOps integration, are areas of concern where there is a need for improvement.

The product should be made available on a hybrid cloud.

There is room for improvement regarding the connectivity of the DevOps.

Improving the documentation would be beneficial as it currently presents navigation challenges. Incorporating a step-by-step guide could facilitate the integration or migration of various systems, including databases. The existing documentation only comprises plain text, hence incorporating more interactive instructions could enhance its usefulness.

Documentation for the CLI is not very complete. Also, the support could be improved, and we have had several problems with backing up and restoring the product.

The administration of the user interface and the technical documentation are areas of concern in the solution where improvements are required. The solution's technical documentation should be a little bit easier to understand, and it is a traditional problem with all IBM products. The technical documentation is a bit too difficult to understand, and it is also not easy to read.

We've had some issues upgrading to the latest version of the solution.

The documentation could be improved. When we download a fix that was expected to be seamless to install, it wasn't. In the past, it was easy just to go to any product and download the documentation. If you had the license, you download the product, install it, look at the documentation. Only for specific cases would you have to reach out to support. Now it is like we know that, for these products, we're going to have to call or engage at some point with support. It's painful right now. It's not a smooth installation.

A hybrid cloud enablement would be very useful. We tried to stand up a gateway in IKS and we were told by support that that was not possible. Yet, the technical people, the designers of the solution, started saying, no, you can actually do it. However, they never said is supported, so I was never sure where the solution stands on hybrid clouds. 

The answers that sometimes are provided are not very comforting. If it isn't a full commitment it isn't going to work.

They need to make it a product that can be downloadable and installable and workable without having to engage with them directly.

I think that some features that would be kind of cool are around the whole idea of a subscriber being able to subscribe to a plan. Not only should that plan include the number of calls per month or per week or whatever but also, I want to subscribe to a plan with an SLA, which gets into response time of an API call. If the response time in the plan that you subscribe is like 200 milliseconds with a 99.9% guaranteed delivery, then I should be able to subscribe to that plan and then be able to go into it and actually see how close I am to adhering to that.

Internally, this makes for some very interesting conversations right around going from application to application, issuing a connection and they're saying, "Hey, well, we're going to make this many calls a month and this is what we need the response time to be." You could literally say, "Well, we're hitting the SLA." Or, "We're not hitting the SLA." Externally, I think you have the same sort of commitments and when you're negotiating contracts, especially on the larger business partner connection, with the business-to-business connection conversation as well.

The developer portal could be easier to customize - as it's Drupal-based, I have to hire a Drupal developer to do it for me. I feel there should be a drag-and-drop or UI-based configuration to customize the developer portal. In the next release, I would like some support for file uploads and MQ integration.

The documentation needs to be a bit better. It's very sequential, however, I don't understand what options to choose for certain tasks. I need to read all of the documentation to find what I need. It's easier to look at recommendations or to watch Youtube videos that show specific examples. 

There needs to be more in the toolkit to complement the product. We could have more features, for example, for queries to the platform. 

The integration of cloud-based services is where we're looking for improvement in this platform.

The installation process could use improvement. I hope that in the next release, the installation process is easier. 

There are certain areas that need improvement. The first one is the design time setup. It has a lot of customizable fields, but we need certain standard fields to be added, such as what all of the consuming systems are. This needs to be very clearly articulated during the design time.

The second, which was a very big issue for me for adoption, is that they don't give any out-of-the-box solutions for knowing how many users have logged on during the design time and who has access to the portal for how much time. There is no capability right now to tell me the usage details and user rights.

As for additional features, design time user analytics would be great to have in the next release.

The platform’s integration with the payment gateway needs enhancement. The setup process and support services could be improved.

The product can be improved in the following  areas:

1.  The monetization because it doesn't include an online method to pay through a web system or with a credit card, where the analytics can be calculated.

2.  The integration of an API gateway that implements the sidecar pattern, which can be deployed in cloud applications, and expose the microservices directly in each pod, this  can be more decentralized components.

All of these areas can be improved. 

We are evaluating the current capabilities. We have other products such as the IBM WSRR and we are trying to see how it fits with the IBM API Connect. So, we are just trying to evaluate it right now.

It needs to improve so that we can be successful in the company, as well grow the API footprints in the company.

Improvements depend on your perspective and what you need the API to do. I think it has room for improvement because, for example, there's nothing to show that other teams might be dumping the same thing and you have no way of knowing if it's redundant. I feel that sometimes different versions of the same thing are put in there. Although there may be slight differences like including some extra fields, at the end of the day, you're almost dumping the same API again into API Connect. At some point the product should be able to tell you that there is already a similar API there and whether you're dumping an API that's almost identical to what is there.

It is still a very new product. We're still finding our feet on the latest version of it because it gives you the capability to move into the cloud. We have not yet taken that leap into cloud because of the uncertainty of what the moving parts are, and that's why we'll have to wait and see. I would like to see more stability, however, and I do believe the newer version will offer that.

A lot of the features require improvement, such as better integration with the other suites of the product and a more secured way to put it on the cloud. Another useful feature needed is to make API development more easier and simpler for development, especially on the management of other artifacts, like the client IDs and other stuff.

IBM API Connect could improve the security of the application and the integration.

One issue we have with this solution is its complexity. In addition, it doesn't handle large volumes of traffic very well. 

Additional features probably will be easier to develop. Right now the UI is using quadruples. On the policy, they are using SSLT, but I would like them to convert that SSLT to use scripting language instead.

The monetization of the API could be improved. The pricing for the consumer is also very important to improve this solution. Nowadays, we are sending information to other tool in order to process out of API Connect. They could improve this internal service in order to have the balance for the consumer's API for different companies, external to our company.

Installation is weak. We (three people) ran into so many problems that I would, as an engineering manager, give this back to the development team. 

Too many secrets (even if they are set by default, we had problems).

The big footprint of pods, a complex network of them. This should be simplified.

To me, the product looks over-engineered. On the other hand, documentation needs more examples, this is "under-engineered".

They need to provide debugging facility for service implementations and policies (see gravitee.io for an example)

In fact, we have had a discussion with IBM and it's agreed upon that they would give us the features that we have asked for, just in three months. We have asked IBM for scalability and for some other features that we wanted. We had a dialogue with them and in the end, they have agreed to provide us with features related to API setup and security. They agreed to give it to us in three months, so we are happy.

One thing about API Connect that could be improved is the security schemes. There are so many security schemes, and from a product perspective, IBM could improve the user experience of the configuration security scheme. It does what it is supposed to do, but it could be easier to configure. The junior developers sometimes find it a bit confusing to configure even though they understand the concept.

And another thing is that I don't know the security policies that we have. For instance, we have a service account, which is needed to connect to some other services. So in those cases, I find it a bit hard to tweak things in the API gateway. And one could argue that it is not the right thing to do with the API gateway. It has a different place to be, which could be why they haven't put it there. But sometimes, you have to tweak around that, and I find it a little bit hard to do that. So if they could accommodate that in there, it would be better for some people.

The automation and the simplicity could be improved.

They could also have more frequent additions.

I would like to see the simplicity improved to make it very easy to deploy and to make it very easy for the regular developer, not an API special developer.

I would like the developers to be able to develop APIs and to make them more accessible.

I would also like to have a DevOps built-in process that is very fast and easy.

The monitoring suite should be ready-made and not have to tailor-make my home.

I would like to see more caching and monitoring features implemented in future releases. It also needs to be a more customizable and flexible product.

I would like greater stability and greater ability to actually administer the product without needing to go to technical support. It's very proprietary and support has secret passwords that they use to get into certain functions.

IBM has limited the capability for executing typical admin commands and only provide a small list of proprietary commands. Without a secret command line password, clients are limited to what they can view and administer – even in a read-only mode.

The solution would be better if it had cloud functionalities.

It would be very helpful if it supported Azure and/or AWS marketplaces. Right now, if I want to set up something in Azure, I need to set up a VM from scratch instead of just being able to have it be supported and integrated.

They seem to have left out a feature for microservices and also a certification module for OIDC. So it would be a good idea for the authentication module to have OIDC certification.

Mostly, I would like to see more tools that are DevOps-friendly. We would have more capability to interact with the catalog and inventories, so a more DevOps-friendly solution is needed.

Automation for our Domino applications could be improved.

IBM is also a bit pricey. On top of that, they have bugs that need to be fixed.

IBM has improved this product significantly in last 2 years but it is still not stable and require further improvements. There are several issues administering the product. Features like , taking manual back up is still not available through GUI. The API manager cmdline is only accessible using one Admin account.

IBM recently added a feature to do autoback up in recent API connect firmware releases but its not very user friendly.Also the exported backup can not be unzipped and is not readable.

IBM info-center help documentation also needs improvement. Competitive product like Apigee provide out of the box policies to run Javascript, JAVA and better/flexible logging policies.

Apigee cloud provides various test tools where APIs performance can be tested from different regions in the world. As of now, as per my understanding IBM doesn't have similar test assist tools in Bluemix cloud .

Troubleshooting any issue is very difficult as it runs on Datapower so Datapower know how is required. Also you need to log on to multiple VMs/devices including Datapower to troubleshoot if errors are not properly handled.

IBM definitely needs to improve their customer support process for their new products as it demands more attention from customers because of large number of defects, long learning curve and lack of documentation.

Based on my meetings at this conference, I'm satisfied with their roadmap, where they're going. Possible improvement is mainly around having more of the cloud oriented architecture bringing stability in adding new capabilities around security.

API Connect's analytics subsystem could be improved to make it easier to render content from the analytics system and offload it to an external database.

It lacks the ability for billing and metering the API usage to invoicing in v3, however, v4 does have this. Automation of deployments is needed.

It should be cheaper.

Debugging could be improved, the solution doesn't really give a lot of debugging, and I'd also like to see an improvement in the analysis. 

The initial setup and installation could be easier. The price could also be better. I would like to see monetization of support, a monetization billing engine, and monetization within the product in the next release.

Like any typical IBM infrastructure setup, you need to learn to set it up yourself. It's not one of those simple zip files or an archive unzip and you're up and running in some few minutes. Knowledge to set it up is key. 

A more user-friendly portal could be helpful. Something you won't really get lost in. For example, other APIs make it so easy to do a couple of things from the portal, not at the management portal itself. Maybe if IBM can improve on that, it would be most helpful.

• Production traffic monitoring features can be better.
• A few advanced API managementfeatures such as monetization and portal syndication are not yet available in the product, but are included in the product road map for the near future.
• API hosting needs a separate product (for example, DataPower) or Micro Gateway (a node js component). However, in a few cases, this can be seen as a better overall solution.
• Frequent product design changes were observed during the early stages of this product evolution; however, currently this product is very stable.
• A few minor quality issues were observed during the early stages of this product evolution; however, currently this product is very stable.

We have no suggestions so far.

There is room for improvement in the reporting and monetization. With monetization, I want to be able to provide my own pricing and platform.

I would like them to add hooks into the API. E.g., it should be able to check credit, then limit access to people who don't have credit anymore.

They need to have more training for people. 

The developmental process is not quite user-friendly.

IBM should improve the customization of the API Connect.

The price could be reduced, it's expensive.

It would be helpful to have access monitoring.

The initial setup is complex.

Business applications could be exposed to users.

We use it for existing IIB services. We call on multiple back ends from the same service where the record layouts are different. It's difficult to describe and use them in the product.

IBM API Connect could be improved with better monetization and customization capabilities. I work for a Saudi Arabian client and we use Stripe as our payment gateway, but Stripe doesn't have a gateway in Saudi. This means that our monetization capabilities are limited. 

We are also not happy with the portal experience. The API developer portal isn't attractive. We want something eye-catching, but this isn't easy to do because the customization possibilities are so limited. 

Our main pain points are in these two areas: creating a better developer portal and improving stability in terms of synchronization and monetization. 

Components, like caching, should be implemented as policies, not requiring dependency on an external solution. Apigee provides caching as a policy.

Integration with DataPower as its API Gateway. Due to bugs in integration, we have to look for workaround on fixing and using DataPower as gateway. 

One place that I think the product could improve is that it could be lighter on computing resources and cheaper. We did not expect to have to add additional services for data processing.  

I would like to see support for non-Java based services. We struggle a bit to be able to deploy and connect our .NET services because of things like data types. We had to map a couple of things. For one solution provider, we had to move them to .NET Core before we could use it properly. I would like to see more agnostic tool service platforms rather than moving it more towards Java or open source.

It still does not support open API 3. Another problem is the designer. I want the whole solution to be on the cloud. For the installation, I have to install locally. There are many improvements it needs if I want to implement a MockServer or sandbox. In the future, I hope it will be more intuitive for building a MockServer.

In the next version, I don't know if they've already been included it or not, but the designer and all the tools should be on the cloud. I don't want any external installation or local installation. The old designer should be less complex and more simple or intuitive for you to search as well.

The solution could improve security and performance.

Integration with Exchange Server. Also if it could be easier to configure or direct the DataPower policies that would help. I'd like to see a combo box to choose which processing rule to apply.

In terms of what needs improvement, some of the product documentation could be better.

Extracting the data could be improved.

My team members sometimes find it difficult to get something out of this solution.

Stability.