IBM Integration Bus Reviews

My primary use case of this solution is for establishing an enterprise service between the orchestrated transactions of two different channels. This is the main purpose of this product.

There is a concept behind the project of this technology, the ESP technology, it is just the layer because of the bus between front systems and back systems, So if I want to change anything in the back system, no need to change in the front system, only this layer. So what do is, we make the integration of the system much, much easier and faster. So there is only  one layer to control the integration of the communication.

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

The product is very stable. 

The scalability actually depends upon the number of users, channels and transactions per second. Horizontal it is hard to add more, but vertical is very easy.

Tech support is very good, but it takes time to resolve any issue.

I have prior experience with Oracle. The work bus and the the word map is totally different from Oracle.  In Oracle you're doing the job management most of the time, in IBM product, their version, it's much easier. You just try to sync with it and that's all. IBM is an easier product to use.

I also have prior experience with Microsoft, but that was in 2008. At that time, there were issues with integration

It is very straightforward. It is very user-friendly integration.

It is important to consider:

• API control
• Firewall security

I have no comment on pricing.

IBM recently changed the name of this solution to IBM API-Connect. With the new name, they have added two new features, such as connecting to the cloud. 

The solution is deployed on-premises.

The message queue feature is very valuable.

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.

We have been using this solution for approximately four years and are currently using the first version.

The solution is stable.

The solution is scalable, and there are currently many people using the solution in our organization. We have plans to increase the usage of the feature.

It is quite expensive and can be lowered.

I rate the solution an eight out of ten.

In general, we are using IBM Integration Bus for integration purposes only because we have multiple applications to integrate.

I have found IBM Integration Bus is very useful because it can integrate multiple backend applications.

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

I have been using IBM Integration Bus for approximately six years.

We have not had any issue with the stability of the solution. However, there are times when we have policies in place and after the installation, the data wizard does not work.

The technical from IBM has been very good.

The installation was straightforward.

IBM Integration Bus itself is prices fair but App-Connect is a bit expensive which we use in conjunction with it.

I have evaluated MuleSoft.

I would recommend this solution to developers.

I rate IBM Integration Bus a seven out of ten.

The IBM Integration Bus is a very strong, very easy-to-use product. 

We prefer it due to the fact that we can get support from IBM when we need to, as opposed to using open-source tools that do not have support.

Sometimes companies have systems from IBM, Oracle, HP, et cetera. IIB is a good candidate to enable all heterogeneous systems to exchange data smoothly without any effort.

The product is a user-customized tool so that you can adjust it to your specific needs pretty well with little trouble. 

The initial setup is easy.

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. 

I've been working with IBM products for 30 years or so. This particular IBM solution, however, I've dealt with for the last four years. That said, I have a lot of IBM experience. 

The solution is very stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

The product is upgradable. There is the potential to scale. 

In the Middle East, the customers are looking for a company that can take over anything and handles everything if there are issues. The support is very reliable and helpful. They are responsive and knowledgeable and we are very happy with their capabilities. 

I'm also familiar with Apache Kafka. Kafka is much faster. The performance is much greater than IIB. IIB is not as fast as Kafka.

For myself, the initial setup was very easy due to the fact that I have worked with IBM for many years and I'm quite comfortable with the brand.

That said, the IBM environment is fairly complicated. It is much easier than other options, even so, and technical support is quite helpful if users run into issues. 

I am not a partner for IBM. That said, IBM has used me for consultation issues and training sources. I used to be a partner, maybe six years ago.

I'd rate the solution at an eight out of ten.

• WebSphere MQ Connectivity: MQInput node and MQOutput node
• Load Management: We can configure more than one instance of an application
• High Availability (multi-instance broker)
• ESQ
• Microsoft .NET Support/.NETCompute node: This has helped us to reuse our existing .NET code
• Web Standards connectivity: HTTPInput node and HTTPReply node

• We have improved our productivity
• We can easily and quickly create and integrate applications
• With the help of built-in nodes, we are no longer required to create our own code for HTTPInput node, HTTPReply node, FileInput node, FileOutPut node, etc.
• Built-in parsers are helping us in rapid development
• Development is mostly just drag and drop, e.g., MQ integration
• Deployment is much easier now

• 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.

We have been using this product for four years.

Stability is mostly fine. However, integration with Oracle is not good. Sometimes the Oracle Wire Protocol ODBC driver creates problems, especially if database links are used in SPs. We have to restart our service to resume connectivity.

Scalability is mostly fine. However, in the IBM integration toolkit, there should be something like “Solution Folder in Visual Studio” to keep related applications and integration services together.

Previously, we were using Microsoft Biztalk Server for middleware and integrations. Because of the obsolete version of Biztalk and the end of the support agreement with Microsoft, we decided to switch to some new technologies with advanced features where we can implement SOA services. Hence we decided to go with IIB.

It was a challenging task because we were moving to a new technology, especially from Microsoft to IBM. With the help of IBM technical sales staff, online help, and some trial and error, we now have a good implementation of IIB.

As a member of the technical implementation team, I’m not involved in pricing and licensing considerations.

While evaluating IIB, we also evaluated Oracle Service Bus (OSB) and the latest version of Microsoft Biztalk Server.

I would recommend implementing this with proper planning such as:

• Create and implement IIB in a High Availability (HA) environment
• Create all required integration servers (execution groups) and assign them with HTTP/HTTPS ports explicitly
• Configure SSL from the start
• Use proper naming conventions for integration nodes, integration servers, and queue managers.

My primary use case of IBM Integration Bus is for designing and developing solutions. We use App Connect Enterprise as a micro ESB and, in cases where we need rapid development, as a microservices platform as well. I'm currently dealing with an on-premises version, but it's deployed on an internal cloud. 

One of the most valuable features is how seamless and easy to use this solution is. This is a fantastic solution and a very measured product. 

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. 

I have been working in IBM for almost 17 years now. 

This solution is stable. It's a fantastic solution and a very measured product. We only need one person to maintain the DevOps pipeline, but we do have a team of 10 developers to deliver the work.

IBM's technical support is fantastic. Their support process is very good. 

This solution is cloud-based. We are using it in a container image, so the one time CI/CD setup is there, in the pipeline setup, and after that the process is very seamless. We just check in our code, and then the pipeline creates an image of it and deploys it onto our private cloud platform. So it's very seamless and there's no hassle involved. 

Initially, we needed about three people for deployment: one for administrative activities, one with DevOps knowledge, and one developer. 

We implemented through an in-house team. I work as an architect, but we have a DevOps team that takes care of maintaining the pipelines and as-needed administration activities. 

I generally do not get involved in the licensing or pricing because I'm a hardcore technical guy, but I'm aware of the fact that IBM is highly expensive, so not everybody can afford it. All the products are licensed. 

I have heard of MuleSoft, a platform that provides a solution for API management, ESB, everything. When it comes to ESB, they have a package or facility feature for unit testing as well, called MUnit or something. From an ESB development point of view, this is the complete package. I was lacking these features in App Connect, but I heard that the latest version includes things like unit testing, automation features, all those things. I also heard that they added AI—I'm not sure where, but IBM is pretty big on that, as well as on adding more and more features in that area. 

I rate this solution a nine out of ten. This is a very measured tool and IBM has been doing a splendid job with this particular platform. Earlier, it was only possible to have an on-premises installation, but now that it's compatible with the cloud, it's a very seamless and fantastic tool. Especially with the current release, I really like this product. 

In terms of advice I would give to those considering implementation, I would say that there could be a problem with integration. Nothing to do with the tools, but from a resourcing point of view. I've seen that a lot of people with Java expertise can face problems when being introduced to this technology without proper training. When a Java developer gets into this particular technology and starts developing stuff, they may be unaware of certain best practices, certain standards, certain conventions that should be used. In my team, when we hire new resources, Java is an advantage for us and a person with Java knowledge is highly welcome, but when we look at their knowledge in the technology itself, there may be issues. This platform is complex and only a person with the right knowledge will be able to deliver. So my suggestion to those who are considering implementation: while resourcing, ensure that you've got the right knowledge on the architect side as well as the developer side. 

Our prime use case of Integration Bus is for message enrichment and message transformations. 

The solution offers good performance and it's stable. The message enrichment and message transformations are great features and the solution also has great security.

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.

I've been using this solution for five years. 

The solution is stable. 

The solution can be scaled horizontally and vertically.

The initial setup is straightforward and took a maximum of two hours. Our technical team had eight people dealing with the end-to-end deployment. 

I recommend this solution, it's an industry standard product.

I rate this solution eight out of 10. 

The primary use case for the solution is infrastructure optimization. Most times the client wants to optimize their integration infrastructure and they want to simplify it. When they feel home-grown solutions are not scaling well for them in terms of complexity, in terms of speed to market, they look to this solution. Projects take long and they break down all the time. That's when the clients start thinking Integration Bus. It's a solution that offloads all the integrations of their system.

The solution offers pretty good pricing.

The technical support is great.

The solution is stable and can scale relatively easily.

The user interface is easy to navigate.

The performance is decent.

The solution offers good dashboards.

The management and monitoring on offer are very good.

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.

We've been using the solution in the company for less than a year.

We've been pleased with the solution's reliability. It's stable. It doesn't crash or freeze. I don't recall facing any bugs or glitches. It just works well all the time.

The solution scales quite well. If a company needs to expand it out, they can do so easily.

Technical support has been good. They're responsive and knowledgeable. We've been satisfied with their support. It's been great.

The implementation is straightforward. It's not complex. What takes a long time, however, is implementing the workflows or projects. That's where the efforts is. In terms of implementation, the implementation is straightforward. However, building the integration of workflows can be a bit tricky. 

You have to pick the right project as the first project, due to the fact that you're introducing a new product inside an organization. The first project is important in terms of setting the stage for understanding the underlying functionality. It shouldn't be too complex. At the same time, it should be impactful enough that you get management support going forward. It should be a project that is big enough whereby you can see the impact of the Integration Bus. 

The pricing is pretty good. What they charge isn't unreasonable.

We're IBM partner-resellers.

The reason we've implemented the solution is driven more by our clients' demands. The clients want IBM Integration Bus, or they already have some investment in IBM Integration Bus. We want to build capability in it to support the clients. We don't have a level of experience with the solution.

My personal advice to others is to start small so that you give yourself a good preliminary base that's not too overwhelming. Most clients want to do everything with this solution, which is fine. However, it's always better to start small with a departmental project, as opposed to an enterprise-wide kind of thing. It is better to start small and tackle a practical project and get used to everything before going really big.

I'd rate the solution nine out of ten.