IBM Integration Bus Reviews

We are using IBM Integration Bus as a messaging solution for our customers. They have legacy systems. Some are MQ systems, file-based systems, app-based systems, and ERP systems. We place it in the middle of integrations. One system sends messages or communicates to another system written by us.

I am into microservices using Java Spring Boot, but if we are using legacy systems, IBM Integration Bus is very good for them. They have their own computational logic called EC12, their own proprietary language. You can do any kind of complex logic and can implement other ESVs that I have seen.

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.

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

IBM Integration Bus sometimes hangs but the IBM App Connect Enterprise successor version is a lot better.

IBM Integration Bus scalability depends. The scalable of the on-premise version is difficult to scale. For example, if you're using the file processing that can be locked on the files and there is an increase in the number of threads there is some limit. The cloud version is not the same, by using a container, we can scale up to any extreme level. That kind of scalable is not there in the on-premise version.

We have 10 to 15 people using the solution.

I never interacted with IBM for technical support. However, my clients have and they have had a good experience.

I have not worked with other solutions similar to IBM Integration Bus.

The initial setup of IBM Integration Bus version 7 was complex, but the 10 and 11 versions were not difficult. We are using IBM App Connect Enterprise, the successor version of the IBM Integration Bus. IBM Integration Bus no longer exists, but the installation was quite easy. This is a single-step installation. The installation can take approximately 15 to 20 minutes.

The price of the IBM Integration Bus is expensive. If you compare the price to the cloud version you can purchase what you need but the on-premise version price is flat.

We evaluated other solutions.

In the modern integrations in the EPAs world, IBM Integration Bus is not well fitted, because if we have legacy systems, it is fine, but if you want to manage the EPA, govern the EPA to allow people to choose the different platforms, such as the cloud platform, Mule CloudHub I would not recommend it. For the legacy integrations, I can recommend this solution.

I rate IBM Integration Bus an eight out of ten.

We use external integration with other entities and solutions outside of the enterprise.

The system's stability is the most valuable feature. Developing the integration is simple.

Recently, there was a lot of instability when selecting the solution they needed for testing. They said that the last one was the one that they enrolled. It's good, and it has good features. Nevertheless, I haven't tried to get it.

I have been using IBM Integration Bus for ten years. 

The solution has been working since 2014. 

The scalability is a ten out of ten. Other competitors need to fix their solutions.

The solution's stability is ready to meet any business requirements you need. You can scale downtime, and you can have a container license that you can use with the product for free. This provides an advantage because with competitors, you would need to buy a container license.

They used to have traditional deployment nodes. Now it should be considered, but the customer needs to pay for the platform's cluster. With IBM, you have the Veritas and OpenShift licenses for three Autologics Veritas. 

The setup depends on the environment because this solution can fail when being fused. So it depends on the implementation. 

The containerization and the mobility of the setup for the personalization is implemented on top of the chip's head which comes for free with the product. Most of the middleware comes with a containerization option and deployment portal.

It needs more time to implement and set up the clusters for the data feature. When you implement it, it gives you host availability to expand and add more resources without the system interaction. There are two days of extra optimization for the cluster and it is very responsive. It gives you more scalability when the system is integrated. 

The price is reasonable considering the features we receive.

IBM Bus can't compete with other competitors. For Bus, you are banking on an enterprise solution. This is a lot of small and open-source software. 

I rate the overall solution a nine out of ten. 

The most valuable features of the IBM Integration Bus are the flexibility to easily integrate with other solutions, such as SAP or any other vendors.

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

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

IBM Integration Bus is stable. We have a lot of infrastructure running on it, and it has worked well. We have many application integrations that we used it for, and we did not have that many issues.

The scalability of the IBM Integration Bus is good because it can scale within the application. The whole application installation has some scalability, not only the server. It's easy to scale.

We have approximately 20 developers using this solution and we do not plan to increase the usage.

I have used the support from IBM and they have a ticket priority system. For example, they assign priority to the ticket, such as P1, P2, and P3. P1 is the highest priority and P3 is the lowest. When we are assigned a P1 priority we have someone contact us directly from IBM.

I rate the support from IBM Integration Bus four out of five.

IBM Integration Bus's initial setup is straightforward. They made it really simple to install everything. The process only took a few minutes.

We did the implementation of the IBM Integration Bus in-house. We have two people for the maintenance and support of the solution.

IBM Integration Bus solution is expensive and this is one of the reasons we are looking for an alternative, such as MuleSoft.

There are some additional pieces of software we need to purchase to do certain kinds of integrations, this should be included and we should not have to pay extra.

My advice to others is this is a great solution if you can afford it.

I rate IBM Integration Bus an eight out of ten.

We are currently looking at other vendors, such as MuleSoft, to see what their offerings are.

We use IBM Integration Bus for application integration. For example, when application A needs to communicate with application B, if Application A is sending the message data in XML format but application B understands the data in JSON format, there needs to be a tool that helps to transform the message data and route the data from one endpoint to another. In such a use case, we use IBM Integration Bus.

I'm working on version 10.0.0.12 of IIB, but we will be migrating the project that I'm currently working on to IBM App Connect Enterprise. It will most probably happen in the summer of this year.

It is deployed on-premises. After the migration to IBM App Connect Enterprise, we're planning to migrate to the cloud from on-premises.

In our project, we are using IBM Integration Bus for doing the payments. We have developed some applications in IBM Integration Bus that help with payment transactions from one client to another.

We can have multiple endpoints, and we can integrate different applications from different platforms. In a large-scale enterprise setup, it becomes so easy to establish communication between applications. You can connect an application to other applications, other legacy applications, and databases. You can also connect with those applications that are in the cloud.  You can connect with other well-known applications, such as Salesforce, SAP, and Workday, by using IBM Integration Bus.

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.

I have been working with this solution for seven years.

It is stable.

You can scale the product depending upon the flux of data into your application.

It depends upon the issue we are working on. I would rate them a four out of five.

Its initial setup was not that tough or challenging. We could easily do the setup without any challenges.

Usually, we have the support team of a project. The support team takes care of such installations.

Its maintenance is easy. It doesn't take a lot of effort to maintain the product. The Infra team usually does some patching of the environment, but we haven't seen any outage of our application that impacts the business in real-time.

It is a really good product to use if there are lots of applications that need to be integrated in your enterprise. It is a very good solution for enterprise application integration and exposing your product's features to the external client through APIs. 

I have worked with other tools related to IIB, such as API Gateway and API configuration tools, in the past. They do provide a very good solution for your business if you are planning to expose your business assets by creating APIs. You can develop an API in IIB and configure it in API Connect. You can have that gateway on top of the solution. This is another feature you can leverage using IIB.

Based on my experience with this product, I would rate it an eight out of 10. This reduction of two points doesn't mean that it is not as good as other products.

We use IBM Integration Bus for document conversions.

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

I have been using IBM Integration Bus for ten years.

IBM Integration Bus is a stable solution.

I rate IBM Integration Bus a nine out of ten for stability.

IBM Integration Bus is a scalable solution.

I rate IBM Integration Bus an eight or nine out of ten for scalability.

I rate the solution’s technical support an eight or nine out of ten.

Overall, I rate IBM Integration Bus a nine out of ten.

We primarily use the solution for integrations of traffic between internal applications, communications, and transactions between various internal applications. We also use it for integration with various external parties.

Before we implemented IBM to integrate with other external parties, we had buckets of applications to build, and maintenance was difficult, as was support. On top of that, integration wasn't well controlled and managed. Right now, post-implementation of IBM ESB, we have a better structure. We have better teams in development and response to customers. We have an application that is centrally managed and monitored. We have better SOA experience in our development process.

The feature we find most useful is the ease of development.

It provides a variable within our application it can easily be used across various applications. 

ESQ is very robust and easy to learn. That's the language the solution is based on. 

The solution can scale.

The stability is mostly pretty good.

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.

We've been using the solution for more than five years at this point. 

There is some latency and slowness in the application. At times, we have to restart the server, and there are some errors we can't handle. We send those to IBM. It's relatively stable, however, periodically, we have problems, which is why we have to get IBM to help us resolve them. That said, I would describe the product as stable.

In terms of extensibility to other applications after development, it's highly extensible. The solution can scale. 

We have developers, who develop various integration requirements, and we have support. Outside that, we don't have physical users using it. There are about 10 developers in all, that handle various requirements that come along. The support unit is about five people and they are handling the support.

We don't deal with IBM directly. There's a local partner of IBM that assists us. We only have a direct relationship with IBM, when the local partner cannot handle a problem. Our contract is designed with IBM in such a way that we have to go through their local partner. In terms of responsiveness, the local partner is good. I wouldn't say excellent, however, they are good in response time. In terms of timeline for issue resolution, TAT for issue resolution, they are fair.

Before we went to IBM, we didn't use a different solution, however, we checked in our industry and we checked how people felt about Microsoft middleware, and they didn't have a good experience. It's not robust, the support wasn't strong, et cetera. Therefore, we chose IBM. We were swayed by how other organizations, including banks in Nigeria, were mostly seeing success with IBM.

We are using WSO2 for some applications, however, we do not rely on it completely as it is open-source and if we run into issues we cannot rely on help from any support.

Setting up the solution is not straightforward. It's difficult and complex. We needed assistance in order to manage the process properly. It's not something you can just pick up, and then, run on your own. You need help from a partner, which involves additional costs.

We didn't do it alone. We worked with IBM, and then, IBM nominated a local partner in Nigeria that worked with us to set this up.

The solution is very expensive. 

We looked at another solution called WSO2. It is a lot easier to set up. It's easier to use, and it's less expensive. However, the challenge we have with that, is that the support is lacking as it is an open-source application. The support is not so strong. That's the only reservation we had for that. Outside that, we are also using it for some other applications as well.

The prominent other contenders were WebLogic from Oracle, and whatever was provided by Microsoft. Among the three then, IBM came out on top in our assessment and rating. However, with the benefit of the insights we now have, if we were to do the same process again, over five years, WSO2 has done so well, and some other middleware is also doing well. Likely we would not choose IBM if we had to choose again.

We are customers and end-users.

I'd rate the solution around a seven out of ten.

I would advise companies to evaluate and consider the options and whether they make sense vis-a-vis the benefit they hope to derive is worth the while. IBM is not cheap. They need to consider costs and make sure they have internal resources available to them. Those using the solution need to be well trained. Otherwise, the company will end up depending on third parties for everything, and that will drive up the costs further. 

I'd also suggest companies implement such a solution early. Load balancing is very critical in our experience. We didn't implement load balancing immediately, and that affected us. As a company is implementing, it should consider load balancing. Rather than invest on the on-prem, a company should consider the cloud. We did on IBM Unix servers on-prem, and that's pretty expensive.

We use IBM Integration Bus to communicate with existing systems like COBOL. We utilize COBOL copybooks, which we need to transform for downstream systems. We create schemas and leverage the COBOL capabilities to convert messages to the target systems. This is one example of our integration use case.

IBM Integration Bus integrates with various applications and systems.

We have many external customers who call our Integration Bus using the SOA WSDL. We expose WSDL to external systems, allowing them to share inputs with the Integration Bus. 

In turn, the Integration Bus integrates with additional third-party and external systems. So, it acts as a middle layer between source and target systems.

IBM Integration Bus has been effective in facilitating our messaging and service-oriented architecture (SOA) or bus architecture. 

So, we're already utilizing it to transform the data from the source it's sending. It converts the data from the format the source sends it into the format the destination system requires. So we are transforming the messages, which are required by the destination system; that's the one way. 

Another way we are routing the messages to the different destinations is based on the source and the payloads they are giving. So we are reading that payload and, based on that, targeting the task. So, we are transforming the same message to the different destinations. That's another way.

IBM Integration Bus's built-in nodes significantly simplified our integration tasks. Almost all of our solutions have benefited from the built-in nodes. Each node has its own specific functions, making them incredibly valuable for various development tasks.

Transforming the messages is a valuable feature for me. 

All the message transformations, conditional routing, and simple data movements are already built-in. 

Additionally, there are some powerful conditional processing capabilities. These features, especially conditional routing and complex data mapping, are crucial for handling multiple complex integrations.

The graphical mapper makes transformations much easier. For simple one-to-one mappings, the source and target can be directly connected, saving developers time.

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.

I have been using this solution for five years now. I use v10. 

I had no issues with stability. I would rate the stability a ten out of ten. 

We haven't encountered any issues with volume or performance based on our testing. While we are still developing these applications, we are confident in the solution's ability to handle high volumes.

I would rate the scalability a nine out of ten.  

I would rate my experience with the initial setup a nine out of ten, with ten being easy. 

It's very easy to set up. It typically takes less than an hour.

Two people were involved. One is the administrator, who has the necessary permissions and installs the product. 

The other is the integration developer, who defines the integration flows, steps, and profiles. 

One person could be from IBM support, while the other would be from the Windows or Linux administration team.

The product requires ongoing maintenance. However, the people required for the maintenance depend on the project. In my organization, we have five to ten based on our projects.

Overall, I would rate the solution a nine out of ten.

I primarily use IBM Integration Bus to integrate core banking and card management systems.

IBM Integration Bus's best feature is integration.

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.

IBM Integration Bus is very stable.

IBM Integration Bus is scalable.

I previously used TIBCO and webMethods.

The initial setup was complex; deployment took around a month, while implementation took around four months.

We have seen a decent ROI from IBM Integration Bus.

IBM Integration Bus is expensive.

I wouldn't recommend IBM Integration Bus to other users because of its high learning curve, and I'd rate it seven out of ten.