The solution's integration with Cloud Pak components could be better. Also, it needs improvement in terms of microservices.

I can't say that there is any improvement I’m looking for. I’m new and haven’t connected with all features. For all drawbacks that were in the old version, I think they have been solved. 

The scalability needs improvement.

We decided to move away from IBM Integration Bus for IT technical refreshments.

The solution needs instruction or guidance. While you're building, without referring back to training, you should get more guidance from the solution towards the next step. From an analyst's perspective, where you get stuck is not the system. If a team has been trained on the solution and they get stuck, it's because they don't know the next thing to do. When you get stuck, the solution should tell you, "You need to do XYZ to not be stuck." The solution should have fulfillment guidance.

The monolithic architecture is an issue.  Due to the fact that it's a built on monolithic architecture, the solution is not very lightweight. It's not highly productive, so, in that sense, it's not so user friendly.

The solution needs to be a little bit more business-friendly in its API management capability.

The solution needs to improve its security and its proactive notification of security issues.

The expiry of the passwords, certificates, and things like that need to be powered by alerts so that it's more obvious that it's something we need to update (before everything actually expires).

It provides all the features that are required for day-to-day work. So far, I haven't seen any major issues that impact our work. I have been told that IBM App Connect Enterprise, which is the next version of IIB, is really good. It is better than IIB, and it gives you more coverage in terms of application integration.

IBM Integration Bus doesn’t provide some features that MuleSoft provides. These features should be added to the solution.

The product does not provide API management. We have to use a separate tool called API Connect for our needs. It would be good if IBM could combine these tools.

The price could be better. It would also be better if they simplified the code.

The product has been well managed and continually improved throughout the time I have used it. 

There is very little that can be improved. It already contains adapters for MS-Dynamics and other enterprise packages and supports many protocols and transmission structures. 

The next versions are moving toward container use. It would be a shame to make the product highly complex just to support one pattern of deployment. It is my hope that IBM continues to focus on practical functionality that is simple and cost-effective.

There are experiences we have on the application, such as latency issues. There are no inherent components for you to throttle and measure the velocity of transactions. For that, you have to get a separate application and set up more robust rules. Then, you can handle API throttling and a number of business logic and rules. You need to implement DataPower, in order to have this. It should have been integrated into a single application rather than having to deal with various applications and components. It would be nice if everything could be packaged under one solution.

Today, the IBM business rule engine, the DataPower is outside the Enterprise Service Bus. It's sold as a different feature or application. If it could be integrated, then it's able to handle a lot more of what we are doing now rather than just have a stateless ESB that you can't do much on, and a set of normal business rules.

If you have the business rule engine that can help us measure velocity, throttle, monetization, et cetera, within the ESB, it would be better than it is now. There won't be any need for one to start looking out for any possible change in the near future.

The initial setup is a bit complex. 

This is a very expensive product.

The Toolkit itself is based on Eclipse and Java, and it does not respond sometimes. When we are working on the Toolkit using or working on our PCs or remote desktop the program has issues with performance. The performance needs to be enhanced. More labs for developers who want to learn about this technology for trial. They may provide a trial version of App Connect or Toolkit to try it for themselves.

IBM Integration Bus can improve JSON Schema validations. We don't have any kind of nodes that can support that kind of validation. If we want to containerize it by means of the docker's containers in the clouds, we are not able to manage it very well.

In a future update, IBM Integration Bus could add better API management. It only supports Swagger at this time.

We have to stop the integration server to start the debugging process. The debugging mechanism of other products is better than that of IBM.

The cloud deployment of the IBM Integration Bus should be made easier.

Performance can be an issue sometimes. The tool occasionally crashes due to memory-related problems. We've reported these issues to IBM, and they are actively working on improving the tooling experience.

It would be great to see better memory management to avoid these crashes.

IBM Integration Bus isn't particularly user-friendly and has a big learning curve. In the next release, IBM Integration Bus should support microservice architecture.

It would be beneficial for it to function more as an iPaaS, with the runtime available in the cloud, potentially on platforms like AWS, Azure, or Google Cloud. This approach enables broader accessibility, allowing more users to leverage the service.

The configuration could be improved. If you build an option in the toolkit, such as a health configuration, we should load the command and configure it. We should then just run checks, and the configuration should be completed.

The integration is difficult to manage.

Migrating to this solution is complex and it would be helpful if they had a way to convert existing integrations.

The solution’s pricing could be improved.

IBM Integration Bus could improve by having a more lightweight installation. Additionally, automation could improve.

The password settings need improvement. 

IBM Integration Bus needs to be more compatible with stable connectors for specific domains. For instance, it has two protocols: ISO 8583, a legacy protocol, and ISO 2022, which works on XML for the finance sector. Similarly, they should add connectors to banking applications and other specific industries.

Sometimes migration takes too long.

Its documentation is currently lacking. We have different environments where we use our configuration services, but we are not able to find documentation about how to deploy the local code to the server and how to set it up on a server level. I would like more documents from IBM that explain which variables should be in your machine while building a project, and when you deploy the code into the server, what should be their values. There are some variable values. I could not find such documentation. While working on a project, I developed the code on a local machine, and while deploying the code to our test environment, I made a couple of mistakes. We had to change some values at the server level, but we couldn't find any documentation regarding this, which made the task difficult.

Everyone is moving to the cloud. There is Bluemix from IBM. There should be more connectors that can connect with cloud systems.

They need to come up with Integration Platform as a Service (iPaaS). It should also have a feature for integrating with those applications that are on the cloud.

This solution would benefit from improvements to the configuration interface. It is hard to understand, and one small change can have a huge impact. For example, if you say Yes instead of No in one of the configuration settings, or Transactional instead of Non-transactional, then the whole meaning changes and it is difficult to track down the problem. This is the reason that many of our projects are progressing slowly. We just don't know what is going to happen with different parameter settings. It makes it very difficult to be creative.

The only other difficult part is that IBM adds its own meta-data, in addition to the normal, generic XML data, into the tree. It's hard for us to understand how to navigate the tree and pick what we want or figure out where our own application data lies, because of the additional IBM specific data. We understand that they do things this way in order to reduce the programming, but it's more of a learning curve.

Currently, we have some custom solutions for logs; it would be nice if these solutions could be provided out of the box.

The solution doesn't have a standard testing framework that can be used for integration performance and other tests. 

The user interface could be improved in a future release.

1. My biggest concern is its MQ dependency, which are still not 100% independent. E.g., in the case of aggregation flows, IIB needs a complete overhaul for aggregation implementation to achieve orchestration implementation.
2. Development toolkit (based on Eclipse) should be improved in terms of responsiveness.
3. It lacks unit testing framework similar to JUnit for Java or MUnit for Mule ESB.
4. IIB run time and installation still need to shed more weight and become lightweight for to become full Docker applications.

In terms of improvement, the UI should be more user-friendly.

We would like to separate the services into different containers, and we don't have this ability right now on IBM Integration Bus. We are currently doing this as an organization, and IBM is setting up the OpenShift.

The version of the technology and current knowledge is a bit outdated. There is also no DevOps, and the process of deploying that is the downside. Regarding additional features, we would like better integration with external solutions like Apache Kafka.

Some of the runtime properties need to be improved because if you want to load certificates as sales security, you have to restart the server. There are also some bugs with file transfer protocol.

IBM Integration Bus could be easier to manage, but this is true of all vendors. It doesn't always do what it says on the box. In terms of new features, we have a roadmap, and it's looking quite comprehensive. However, we may not necessarily need everything they're putting out. I know that's probably driven by global demand. 

Surely something that can be improved is session management. Sometimes sessions hang. Practically every day we hear about session congestion and this kind of thing. Troubleshooting the issue has become a long-standing problem. Where the true problem lies is a challenge for our support team.  

The session management issue may be a bigger problem for us because our support team is not so highly trained. Also, sometimes our developers are not able to dig down to locate the actual problem. To resolve the issue when it occurs, we have to at least restart the server. It is not really solving the problem, it just relieves the symptoms. These session management problems are the basic issues we are having, but otherwise, our services have become better after bringing in the Integration Bus.  

One thing I would like to have added to Integration Bus is a plugin — or some other software, — to enable testing the performance of our services from the application hosted on the IBM service. I think that the users of the system should be able to get something like that and somehow do performance testing on their own. Currently, I have used some studio or some plugin to find these results. Another option is using services that are available that I have also tried. If IBM could provide this same type of testing capability in its application, that that would be great. It would enable us to report to our business on the facts about how much we have improved from the earlier architecture.  

The interface could be more user-friendly.

This product uses the PVU (Processor Value Unit) license model from IBM, and it is something that should be improved. It requires you to install monitoring software that ensures you are only using the number of CPUs that you have paid for. This license monitoring tool is very complicated. 

The tracing and debugging features are not up to date with more modern technology available.

I do not think there are any improvement areas because it depends on what exactly the use case for this ESB is. Some organizations are having a lot of integration and they will choose a regular ESB. While others will choose the security purpose route, making an extra layer. It depends from organization to organization, to determine how this solution can be improved from their specific use cases. Otherwise, I think that there are not any relevant improvement areas to give.

It needs improvement in terms of technical support as well as in terms of integration of data mining. I am not convinced about many things in this solution, such as the conversion of the DFDL or copybook file, which is the conversion from a text file to XML. It is very complex.

They should also provide more information about this solution in the IBM Knowledge Center. I can get a lot of information from the IBM Knowledge Center about DataStage, but I don't get that much information about IBM Integration Bus. There is hardly any information even on the internet and various channels such as YouTube. They can provide good step-by-step documentation based on a company's requirements. It would be really helpful.

My company is mainly looking for data mining and communicating with multiple servers. IBM Integration Bus is good for communicating with multiple servers, but it needs improvement for XML conversion and data mining. We have a lot of old systems that use XML.

I like the IBM Integration Bus and I hope that it will change in micro-service architecture. My understanding is that it will change to be less connected, and less depends on the operating system or the hardware resources.

I would like to be able to run and install this solution on different platforms and using containers and using modern micro-service and cloud environments.

The product could be improved by including more resources on SQL and improving the simplicity of the resources available. Additionally, the price can be reduced.

IBM Integration Bus could have better REST API, which could be more powerful,  and this accounts for why we are looking for alternative solutions concerning this and open banking. 

The initial setup was complex. 

Technical support is below what I would consider to be very good. It's good, but not too much or very much so.

The solution is complex and there is a need for more resources and greatly improved quality. 

There are a few issues; the memory footprint needs to be improved. Memory replacements for on-prem should be minimized. Nowadays, if an application takes 4GB of RAM, that should be the minimum. Having this solution on-prem, is taking more memory and that memory footprint should be minimized.

We have come across many customer complaints about the excessive time it takes for IBM to provide customer and technical support. 

One drawback that I have found is that there are issues with using the Java connector. I was running out of heap space.

IBM does not support orchestration, which is how they designed it, and other BPM tools in the market support orchestration. IIB wasn't designed for short and small transitions which are preferred to be stateless. If they merged the BPM capability into this product, then it would be a better solution.

The solution could improve by having built-in implementation and secure monitoring without the need for API Connect.

I would like to be able to build an Integration Bus cluster that is active-active.

Documentation is not easy to understand.

There should be inclusion of more and more adapters that make this product more usable.

The solution itself is quite expensive for smaller companies because of a complex architecture setup if you just start. Easier and a more plug and playable solution which make an MVP easier in being able to show the value faster to the customer.

• ESQL: ESQL requires some more functions e.g., encryption/decryption/hashing. Currently, we have to use .NET or Java.
• WebSphere MQ: This needs a web-based remote monitoring and administration panel.
• Oracle Wire Protocol ODBC Driver: This needs to be compatible with different versions of Oracle, at least Oracle 10G and above versions.
• A centralized log monitoring console is required where we can monitor all traffic (in/out) of the broker node.

The resources about IBM are hard to find, and it is not enough material. Finding people who know this product is problematic.

While it is very user-friendly there is another open-source tool in the market you can use instead of it.

The integration could be better, especially when it comes to integrating with older systems or solutions. 

The solution needs to simplify its documentation, such as the user and operation manuals, to make them even easier to understand. 

It would be better with more API management features. 

More Micro-service and container based support. IBM is already working on it on Version 11, but it still needs improvement. 

Also IIB have cloud version ,it is doesn't have all features of the On premise version , and needs more improvement . 

There are a couple of things I want improved, but I think they have already touched upon all those things in the most recent version. I'm not using the most recent version—I use a version older than the most recent—but I'm sure that if I looked into and explored it, I would see more support on the CI/CD and more support for unit testing automation. I've read that they released all these things in the new version of App Connect. Once I explore the new version of this tool, I'll probably have a better idea of suggested improvements. 

An issue which should be addressed concerns the difficulty of the product connecting to SAP.  In contrast, Mule has developed many connectors so that it can interact with multiple points. This allows us to write our own Java programming for, say, better database connectivity.

As the databases have different versions, we have different connectors for opening them. 

With Mule Force, we will write our own connector.  

While we do have different types of storage capacity, including that of hardware, RAM and transactions per minute, this is an area that should be addressed. There needs to be more storage capacity for logins and database file storage. Transactions per minute is a point that will need to be hammered out by senior management in its SLA. 

IBM could improve its connectivity. 

The solution needs to be better integrated with the cloud version of the solution.

The solution is constrained by the environment - whether it's on-premises or the cloud. The cloud seems to be more adaptable.

IBM doesn't really have a very strong community surrounding the product. Most of its direct competitors are open source solutions, and those have an excellent and well-developed community around the tech to help users navigate the ins and outs of the product. IBM is lacking in this area. If they had more of a community, more people would know about the product. They should push to create a developer community around it and make the products more accessible to developers.

I've heard some clients are asking for autoscaling capabilities. It could improve DevOps. They might have something similar in other products, however, if they could introduce it within this product at some small level, it would make many clients happy.

I would like for them to make the training much easier. Once you work with a sphere of people that can integrate the solution, then it's stable. But just to educate people, it's not that easy to do. It's not easy content to teach people.

Licensing is too high. It is quite expensive. We don't have a lot of clients who apply for it because they cannot justify the price. They know it's a good product but it just is too expensive for them. So we have to send them to products that are cheaper. 

Technical support is something that should be better.

Lowering the price would be an improvement.

The deployment should be easier.

Its licensing or subscription model should be improved for more flexible adoption. There should also be more ease of use.