IBM API Connect Reviews

The usual use cases for IBM API Connect that I worked with mostly involved three things: security, monitoring, and message control. The purpose was to address these areas, though there was one feature we did not use. IBM API Connect has the capability to monetize APIs, but I worked for an insurance company that did not want to monetize. They wanted to use it internally and control the information, so monetization was disabled.

After that, we focused on security, monitoring, and message control. For security, we added Active Directory integration so people could connect securely, and we enabled JWT to secure login, password, and token inside JWT.

Monitoring was important because when IBM API Connect is installed on Kubernetes and OpenShift, it includes ELK, which is Elasticsearch, Logstash, and Kibana. When we wanted to monitor something, set an alert, or check the logs, everything was included such as the number of calls, the number of succeeded requests, the number of failed requests, the number of requests with technical errors, the downtime, and the average message time for request response. Everything in monitoring was handled by ELK, and there was a small customization of Kibana dashboards, though it was really limited. The customization of Kibana inside the administration page of IBM API Connect was quite restricted.

Then we had control, which has many parts. The first part was that when we created an API, we had to create a contract using Swagger contract, OpenAPI 2, or OpenAPI 3. We were creating the Swagger and controlling that the message had the minimal requirement of data and structure, or it was rejected by IBM API Connect directly.

The second part was that when we had an API, we had to create what we call a plan, and inside the plan, we could add our customers. Any plan could have rules and policies. For example, we could say that accounting clients have a plan and inside this plan, they can only use GET requests to get information but cannot modify it. All the updates were forbidden.

We created the plans to control who is doing what. The last thing we were doing with these plans was implementing request limitations. In a big insurance company with many millions of clients, when requests come from anything online, batch, and so on, if we say a user coming from a certain server can only make 100 requests per minute, all the other requests get HTTP 529. This is managed by the plan and by the user. We could control and say that a batch from a certain server can only make 10,000 requests per day or 5,000 requests per hour or per minute. This is a rate limit based on the number of requests and the time range. IBM API Connect made this control quite easily, and we could see in the dashboard when someone made too many requests. For instance, if someone was only accepted for 500,000 requests per day but made one million requests, he increased his number of requests by twice and half of it was not allowed. All those things made us limit requests. We limit because we do not want to kill the servers in the backend on the other side. We made tests and stress tested the backend, and when the documentation said a backend can only handle 10,000 requests per day, we needed to be sure that every request coming to it was managed by IBM API Connect in front of it, and only it could handle the requests going to the backend on the other side.

The features or capabilities of IBM API Connect I have found the most valuable and useful are two things that are good, but one of the two is not easy. The first thing is that the development is in JavaScript. When I want to make custom development, I can get a request and handle it as I want. Because there is JavaScript, there are quite no limits. I can do whatever I want with the message, transform it, control, update, anything I want, really. IBM API Connect also has modules, so if I do not want to use JavaScript for custom development, I can use modules. They have modules for XML to JSON and JSON to XML conversion that I do not have to code because they are already included. IBM API Connect has something to put a flow from the request to the backend and from the backend to the response, similar to an ESB. In both directions when something has to go through, I can use it, which is great. So it is time to develop, but if I really do not find what I want into the modules, I can make custom development in JavaScript.

The second thing is that there is even a debugger, but the debugger is difficult to use. It is cool that there is a debugger, but not cool when I want to enable it because it is difficult. I need to use Postman. To debug an API, I need to call another API to enable the debug of this API first. Then when I make my call, I need to call another API to get the message and see all the steps. It is not having a debugger in Java where I can make step-by-step debugging or in any code language. It was not really easy because I need to test, enable debug, send the message test, recall another API, get the steps message in a text file and understand what is the problem and then resolve it. However, Gravitee API has a real debugger with step by step functionality.

I have used the analytics feature of IBM API Connect. The analytics is on the Kibana side through ELK, which is the Elasticsearch, Logstash, and Kibana part of the analytics.

The metrics I found most useful are different for different departments. For the business analyst and for the product owners and managers, they were checking how many requests succeeded and how many requests failed at the end of every month. We preferred to see only the bad requests. We would check if there were any requests refused because there were too many calls in the time range, how many 500 errors there were, and why those 500 errors occurred. Then we would go to the dashboard and check the message response to understand what was the problem. This was the more interesting part for us as architects and technical persons. Product owners, business analysts, and others wanted to see that we had 90 percent of success messages and 10 percent of failed messages and so on. We had different dashboards for different audiences.

There are areas of IBM API Connect that need to be improved. I want what Gravitee made, which is much better. Gravitee made many samples for different use cases. First of all, they made examples of use cases, codes, and what the module expects and what the module returns for multiple examples and use cases inside the development. I do not even have to go to the documentation website because everything is included inside the tool when I work on it. This is great, in fact. IBM API Connect should show examples.

One other thing is the support. The support of IBM is in India. Every time I want to ask something, they say they need logs, they want this, they want that. Gravitee API asks me to explain the problem without asking a thousand times as if it is a request for a green card in the USA. Then they really explain quickly.

IBM is a big company, so everything is standardized with the approach of "You do that, you do that, you request that. If you do not have that, you do not reply to the client." Clients want flexibility today, even if it is a huge company. A stressed client is a client that will want to change to other flexible solutions. When everything is fine, we do not care, but when there is stress and problems, that is when the customer of IBM evaluates the tool really. It is when there are problems. IBM makes a lot of efforts on sales and technical sales, and then that is it.

I have been working with IBM API Connect overall for around four years. There was version 8, version 9, version 10, and after they changed, it is version 2024 I think, 2025. IBM always changes names and so on. But I worked extensively with version 10.

IBM API Connect was very stable. We never had any issue of memory or anything. It was really stable.

The scalability of IBM API Connect is quite variable. When you have on-premise, it is very difficult. When you have Kubernetes or OpenShift, it is very easy. When you have Node.js, it is not quite impossible, I think, but it is quite difficult.

On-premise is very difficult because you need to put a proxy and so on. You need many things. When I mean on-premise, it is a physical machine where IBM API Connect is installed on one VM or physical machine only. If you want to increase scalability, you have to add another VM or another physical machine and install IBM API Connect and make them collaborate together as a cluster. This requires significant effort.

When you have Kubernetes on cloud or on-premise, scalability is easy. We had Kubernetes on-premise because we wanted performance. We had Kubernetes locally because we had to install Kubernetes ourselves, which was our responsibility. So we installed Kubernetes, or we could install OpenShift which is just a top level of Kubernetes in the end. But then inside, I would go to the sys admin of Kubernetes and ask if they could increase the replicas from four to eight, for instance. Everything would be done inside of it and the network would be handled, and the proxification of the URLs and DNS would be done internally. This is easy with containerization.

We quite suffered with Kubernetes initially. First of all, there were minimal requirements that can be found on the website regarding a certain version of operating system, memory, disk, and CPU. We made the initial setup, and when we tried to install, we had many errors. In the end, we asked for an expert of IBM to come help us. It took one week, and he helped us because IBM has information that I do not find in the documentation. It was frustrating that we almost could not install it by ourselves because some information I will never find because IBM keeps it. This is not fair. IBM is very aggressive in the legal part, in the selling part, and in anything.

I participated in the initial setup and deployment of IBM API Connect.

The role of IBM API Connect in accelerating time to market for customers is a difficult question. If you have an expert, it is a big added value to have IBM API Connect. But if you have people learning it, the documentation is not easy, which is typical of any documentation of IBM. It really depends on whether you have an expert or whether you have people learning. However, compared to Gravitee, I would choose Gravitee, unfortunately, for IBM.

I have utilized the automated API creation tools, but we did not prefer it. We used automated conversion for the API. We had old web services with WSDL in XML format, and they wanted them as an API with just sending JSON. So we provided the XSD and the WSDL to IBM API Connect, and it worked quite well. Then it transformed it to a Swagger. Then we took the Swagger and we could continue the CI/CD of this REST service. However, the automated generated API was not our preference. Either we went from WSDL or we created the Swagger by hand. We used Stoplight, which is a Swagger editor. We were working with the business analysts, and we were creating the Swaggers together. Either they provided us an XML or an Excel file with all the structure, or we were doing it all together without an Excel file and creating the Swaggers. When the Swagger was valid, then we installed it into IBM API Connect.

I have been working with Gravitee API, the French solution, while also providing feedback with PeerSpot. It is not the same. It is really not the same. There is Gravitee API, and that is it, because there was Kong but it has not been tested because it was too expensive, so they refused to test it. I installed Gravitee API and worked on it. I mean I installed it, and it is used in production.

I was also working with APIC, IBM API Connect, and App Connect also. I have not been using GraphQL because it is a new feature, really. But I had some questions on it.

My overall rating for IBM API Connect is 7 out of 10.

We use IBM API Connect for healthcare projects, not for telecom services.

The best features IBM API Connect offers in my experience are the middleware capabilities, as it can connect the front end.

You can be more secure using JWT tokens with IBM API Connect. We can optimize API access, which will be more secure. We can add some policies to provide extra security, protect your backend, validate the consumers, and analyze based on the traffic limit to throw things out.

IBM API Connect helps with security by using OAuth 2.0 and basic authentication.

User management to authenticate the user is an important feature worth mentioning.

IBM API Connect has positively impacted my organization, as customer experience is good. Based on the subscription, we can handle the subscription, and customers use the environment as a handler, making the mechanism easy.

Based on the implementation, you can see improvements in onboarding speed. If this is a direct application, you can validate with the user and get the response from the application. If you require multiple transactions, it takes time.

To improve IBM API Connect, based on customer experience, you could work on latency. You can increase scalability and availability. If you're connecting with any other cloud, it connects to the infrastructure which needs to be managed with the customers and cloud providers, so if you have a setup, we can handle it easily.

I have faced latency issues on the server, related to our management. If you need to stabilize your server based on peak traffic, you need to configure the scalability model. You need to know when traffic peaks, so use auto-scaling when traffic comes. If the application is not in use, the value should be zero, and it starts from zero. Based on customer experience, the value will increase, and when there is no customer servicing, the peak would be reduced, making the value remain zero. Following this approach, you should be able to optimize costs and satisfy customer experience.

I have been using IBM API Connect for four years.

In my experience, IBM API Connect is stable enough, but downtime depends on traffic and backend server configuration. If your backend server is down, you may experience downtime. If it is functioning well, you won't have a bad experience and your application becomes more reliable.

IBM API Connect's scalability is good, as you can handle it easily similar to how you manage cloud providers.

I haven't reached out to customer support yet; there is a separate team for that.

Neutral

I used Google Apigee middleware before switching to IBM API Connect.

My decision to move from Apigee to IBM API Connect depends on the project I worked on.

I have seen a return on investment from using IBM API Connect, as we created multiple plans based on customer usage. In those plans, we can reduce traffic, and based on the traffic, we can optimize the cost.

I have not worked on pricing, setup cost, or licensing for IBM API Connect; that part is handled by the architect.

I did not evaluate other options before choosing IBM API Connect, as I mostly worked with Apigee. It depends on the provider; IBM API Connect allows movement into on-prem architecture, while Apigee is primarily a cloud solution.

My advice for others looking into using IBM API Connect is that it's a good platform to learn from. You can create API proxies easily, implement features effortlessly, and maintain them without hassle. There is also a support team available. It's a bit similar to Apigee and stands out as a unique platform.

Regarding a business relationship with this vendor beyond being a customer, I believe my vendor subscribed to IBM API Connect, and I'm working in the healthcare domain, so that's the vendor basis I believe.

I don't have any additional thoughts about IBM API Connect before we wrap up; it's a good opportunity to learn.

On a scale of 1-10, I rate IBM API Connect a seven out of ten.

IBM API Connect has a designer and CLI features which can be used to completely automate the API. The way we use it is different. We really do not need an app dev team in order to create, design, and deploy an API. If a business analyst has a basic understanding of what the input and output payload is, they can directly create the API. We have automated the process. A business analyst fills out an entire Excel sheet with input and output payloads. That payload is fed to IBM API Connect commands and generates the YAML out of it, which is compliant with Open Standards 3.0.

IBM API Connect by default has all the features that are specific to CI/CD processes. IBM API Connect has a rich set of policy management features. We can achieve centralized control over API policies for governance and compliance. If a security team requests compliance features, we can fit IBM API Connect to address or secure whatever needs come out of the security team. All the enforcements can be done using IBM API Connect.

IBM API Connect is an API Gateway. It is purely for securing enterprise-wide APIs from the outside world. It best fits as an API Gateway in DMZ zones. It has a lot of features. It supports OAuth, third-party identity providers, and MFA as well. With the introduction of IBM API Connect V10, it also supports integration with multifactor authentication.

IBM API Connect has a designer and CLI features which can be used to completely automate the API. The implementation approach is different from typical processes. We do not need an app dev team in order to create, design, and deploy an API. If a business analyst has a basic understanding of what the input and output payload is, they can directly create the API. We have automated the process. A business analyst fills out an entire Excel sheet with input and output payloads. That payload is fed to IBM API Connect commands and generates the YAML out of it, which is compliant with Open Standards 3.0.

IBM API Connect by default has all the features that are specific to CI/CD processes. IBM API Connect provides policy management features. We can achieve centralized control over API policies for governance and compliance. Whatever a security team requests in terms of compliance features can be addressed through IBM API Connect to secure the necessary components. All the enforcements can be done using IBM API Connect.

When comparing IBM API Connect with DataPower Gateway, there are many features in DataPower Gateway that are not available in IBM API Connect. Some examples would be connectivity to MQ is not available in IBM API Connect. Custom code needs to be written in order to connect to MQ and exchange messages. This can be achieved, but it is a tedious task. Custom extensions need to be built in order to connect to MQ and exchange data. Additionally, there are enhancements needed when it comes to segregating APIs based on domain.

We did not go with the model of scaling based on licensing. We have a centralized pool for the entire middleware IBM middleware stack, which is quite close to 400 plus licenses. It is distributed among IBM MQ, IBM Ace, IBM DataPower, and IBM API Connect. As far as licensing is concerned, it is pretty flexible. It is not tied to a single product.

Support is extremely good, especially with Sev 1 issues. The research team is brought into calls whenever needed. The support team is strict on their SLAs.

Neutral

The overall review rating for this product is 9 out of 10.

Positive

My main use case for IBM API Connect is to connect APIs more quickly. A specific example of how I use IBM API Connect is that we have many APIs and IBM API Connect provides a one-stop solution.

IBM API Connect has positively impacted my organization because it provides better detailed analytics, which makes things easier for us. It simplifies processes by using AI to help automate tasks and work.

We are relatively new to IBM API Connect, so I do not have significant improvements to suggest at this time.

I have been using IBM API Connect for the last month.

I do not handle the pricing, setup cost, and licensing details.

The advice I give to others looking into using IBM API Connect is that it really depends on people's use case, so depending on the use case, it might or might not fit their solution. I gave this review a rating of 10.

I use the solution in my company as an API Gateway and API Manager. We use a few of our products for technical documentation and API Specification, as well as as an API Manager. The rate limiting comes with the tool. It has been a very good product that we have been using for the last few years.

The most significant feature that we have been using in the tool in our company is the API Manager because it works like a gateway for APIs, and I think that is the best part that we have been utilizing.

The only downside where improvements are needed is probably on the licensing side.

Scalability is an issue with IBM API Connect, making it an area where improvements are required.

I have been using IBM API Connect for two years. I am a customer of the tool.

Stability-wise, I rate the solution a nine out of ten.

My company didn't face any sort of major problems running the tool till now. There were some issues in the tool for which we were getting support from IBM, but other than that, the product is stable.

The tool doesn't scale horizontally. I don't think there is a Kubernetes engine implemented in it. You have to include more resources, specifically vertical resources, for it to scale, and that is a hard part to handle.

The tool is basically configured for API, so it receives millions of hits per day. It has thousands of users.

With IBM API Connect, a few people in my company manage it, and a few are its developers. The company itself has around 3,000 to 4,000 people.

The solution's technical support team is good. As I am in Pakistan, we usually get local support here. Engaging someone from IBM takes some time, but otherwise, the support is pretty good as well. I rate the technical support a seven and a half out of ten.

Neutral

I am unaware of the initial configuration since my infrastructure team was involved in it, and a person from IBM was also helping us.

The solution is deployed on an on-premises model. My company doesn't work with the cloud for security reasons and because of some confidential information.

It is a pretty expensive tool.

The tool is expensive if I consider how products like WSO2 are available in the market. You have pretty much many options in the open-source community, considering how IBM's pricing can be an issue. If you want to scale for more hits per month, although it's an SQL license, you need to buy it from IBM, and it becomes pretty expensive for me. The pricing is pretty high.

API lifecycle management capabilities have enhanced our company's operations, and they weren't hard to manage. When we procured the tool, we received some training from IBM. One was for administrators, and the other was for programmers. It was pretty easy to configure it. The only downside is that it requires a lot of physical resources, so we had to get a few servers to work with it.

The product is not only used in the government sector but also in the telco and banking sectors. It is one of the biggest products that is being used as an API Manager. The other products would be from Oracle or some other renowned vendors. I would obviously recommend IBM if you are going it for a large scale with APIs and if the number of hits is pretty much huge. I would definitely recommend the product to others if the pricing is not an issue.

In my company, we are not using AI with the tool, but it is probably one of the things that is being planned. Until now, AI has not been utilized in the tool.

In my company, we have not explored the tool for any other integrations. We just wanted to use it purely as an API Gateway-based product.

Considering the price factor, support, and stability, I rate the tool an eight out of ten.

We mainly use it for API orchestration, basic gateway features, and data features. We use it just for orchestration and gateway functionalities.

Our client has a vendor contract with IBM and uses various IBM products, including API Connect. So, it's more of a forced usage within the organization.

So, it fulfills the basic needs.

It acts as a central gateway for both external APIs and underlying systems. It's basically a central middleware for hosting APIs to the internet and consuming APIs from internal systems.

It provides central governance for any APIs going outside the network, ensuring security and a common contract for API definitions.

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.

I have been using IBM API Connect for the past six months due to a client engagement. 

We use the latest version. 

I would rate the stability an eight out of ten. It has good stability. 

While Azure API Management offers configurable scalability, IBM API Connect relies on Kubernetes clusters. This might seem manual and require defining cluster instances upfront, but it's completely customizable and not on-the-fly scaling.

It's completely custom-driven, not on-the-fly scaling, which some may consider cumbersome.

Overall, I would rate the scalability an eight out of ten.

Almost all applications we've been exposing lately go through this middleware, so it's used extensively. There are around sixty applications directly using it, but six Kubernetes clusters serve those applications.

It's heavily used for integration, including system-to-system integration and product integrations.

Our usage has been increasing year-on-year based on our needs.

The customer service and support. are good. They respond promptly to any issues requiring assistance, and they have an SLA for response times.

Positive

We have a partnership with IBM for some products, but for IBM API Connect, we're just end users.

I used Azure API and then Microgateway. We use IBM API Connect because the client is an existing user of API Connect for another client's project. Their organizational practices favored using the same solution, so we had to go with IBM API Connect.

I would rate my experience with the initial setup a seven out of ten, with ten being very easy to set up. 

It wasn't complex overall, but the initial API creation had some challenges regarding security implementation. After that, it was much easier. We followed the template, but sometimes the page would close unexpectedly.

We faced some initial setup issues. Initially, understanding and implementing the right way to achieve API-level security, etc., was a bit tricky.

The documentation is decent, and they offer some provider-based human support, so that's sufficient.

We have on-premises installations for some applications hosted in Kubernetes clusters, and the on-premises Kubernetes cluster can be hosted anywhere. It's a containerized cluster deployment.

IBM API Connect was already an existing middleware for the client, and we only expanded it for our new digital transformation project. So, the deployment process wasn't relevant to my experience.

Only two people manage it. They handle the entire API lifecycle, including hosting and management, across four different environments. They're DevOps engineers, playing both development and operations management roles.

There were two things: governance and security. This product helped greatly in both areas.

It is used across the entire organization, so the ROI is a hundred percent. Because if we couldn't have hosted an API gateway on some applications, that would be a failure. Now, any new application they build, any new product, can easily expose the appropriate API, making it worth the initial investment.

It can be quite expensive. It's okay for large-scale usage but quite expensive for smaller-scale implementations.

Overall, I would rate the pricing an eight out of ten, with ten being expensive. The pricing is fixed, not a floating model.

If it's for a large-scale API ecosystem, IBM API Connect is a good choice. It's manageable, reliable, and offers extensive features. 

Mainly understanding API gateway principles. If they grasp those, they can use this product. So, some background knowledge is advisable.

Overall, I would rate the solution an eight out of ten. 

We use the solution to monitor, process, and manage API services.

We use the product to enforce standards to check and align things with the application design. The tool has enhanced our digital transformation efforts. With the adoption of the cloud, we deploy a lot of APIs on Lambda. We also have APIs deployed on-premise. We use the front-end access of all the APIs on-premise and on the cloud.

The API lifecycle management has helped us to do the version controls and naming of the APIs. The product gathers data to measure API performance. Users monitor the utilization of each API and the response times. It helps manage the environment. The product facilitates development by allowing the developers to go to the portal and test the APIs.

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

I have been using the solution for many years.

The tool is very scalable.

There's a bit of a learning curve to the setup process. Once the support team gets familiar with it, it is just like any other product.

We started with DataPower ten years ago. Most of our APIs are SOAP APIs. When we started using RESTful APIs, we started using IBM API Connect. It took us a while to adopt API services. I will recommend the solution to people who need to manage their APIs. It's pretty good. It serves our purpose. Overall, I rate the product an eight or nine out of ten.

I use IBM API Connect to configure and manage the APIs. I also used the product for transformations. I used the product for some of its functionalities, like caching and rate limiting, especially for the backend system. Configuring the backend APIs and API proxies and opening them to external services were some of the activities I did with the product.

The most valuable features of the solution stem from the fact that it is very easy to use and is something that is easily configurable. The product actually provides a complete suite, consisting of the developer portal and management of the APIs, while giving access to a different set of users. The product also allows users to use API sandbox. Configuring the APIs with the backend systems is a valuable feature of the product. With IBM API Connect, I found everything to be very user-friendly, easy to use, and able to be developed quickly as well.

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.

I have been using IBM API Connect for four years.

It is a stable solution.

It is a scalable solution.

There are around 20,000 users of the solution for the project we are currently working on in our company.

I have experience with IBM API Connect.

Though I wasn't involved in the setup phase of the product, as it was taken care of by another team in our company, I feel that the product's setup process needs to be simplified.

The product's deployment has two parts. The first part of the deployment is about how you set it up, and the other part is to deploy your API for availability. If I talk about the part where the APIs are to be made available, then the deployment process doesn't take much time, and it is easy to make them available.

The solution is deployed on an on-premises model.

A team of 20 people who were on the API management side were required to take care of the deployment and maintenance of the product. Initially, a team of 20 people was required to take care of the product's deployment and maintenance, but it was brought down to 15 people later.

There was a need to purchase an upfront license or a one-time license or upfront license, but I cannot remember the details about it clearly.

I would recommend the product to others, considering that IBM API Connect is one of the leading products in the market, but the concern is that it should reach the level of other products in the market, like Apigee and MuleSoft. The competition of IBM API Connect is with the leaders in the market, and to compete with them, API Connect should be a hybrid cloud-enabled product, and it has to offer a single pack to its users. If I talk about IBM API Connect, I should not be forced to purchase IBM App Connect or the other suites offered by IBM. I should be able to purchase the API Connect license easily.

I rate the overall solution an eight out of ten.

We use it for API integration, particularly in conjunction with the One Link solution. One Link is a platform that comes into play during cross-channel communication within the banking sector. For instance, if a customer has an account with Bank A and wishes to withdraw funds from Bank B, it facilitates cross-selling communication between two distinct banks—Bank A and Bank B. Our primary focus is on enabling seamless transactions between different banks, and we also incorporate case and bundle links within our solution.

DataPower Gateway holds significant value for us as it serves as the cornerstone of our enterprise security controls. Even in the absence of published APIs, DataPower Gateway continues to maintain robust security measures. In the event of IBM API Connect experiencing downtime, users can still access APIs through DataPower Gateway, thereby minimizing downtime and ensuring continued service availability for users.

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

We have been working with it for ten years.

I would rate its stability capabilities ten out of ten.

It is highly scalable. On a scale from one to ten, I would rate it between nine and ten.

When there's an open ticket with severity one, the IBM team consistently provides timely support. We are highly content with the support we receive from IBM. I would rate it nine out of ten.

Positive

The initial setup is relatively straightforward.

The initial installation phase may pose challenges as it requires some time to grasp the intricacies. The learning curve is significant, especially for people who don't have experience with it. While the installation may not be easy initially, users can acquire proficiency once they have a thorough understanding of the system. When deploying a new environment, the entire setup typically takes approximately one to two days. Assigning two individuals to manage the deployment process is more than sufficient. For ongoing maintenance of the solution, a single person is capable of handling all the necessary tasks efficiently.

Overall, I would rate it ten out of ten.