IBM Integration Bus Reviews

We use the solution for synchronizing data across the enterprise and opening data to extend its use by simplifying and making it consistent regardless of its source. 

It's for installing a line of indirection between data source and consumer to reduce contention at the source, and to add security, audit, and combine data from multiple places.

With it, we are implementing GDPR rules on data use, compensating for systems being unavailable, and delivering low latency for website users.

I have designed solutions for payment processing, Service-Oriented Architectures, micro-service architectures, data sharing and synchronization, and point to point data sharing using this product across banking, retail, and many other industries.

Many projects absorb a great deal of time and budget to find data and understand how to access it. This product allows data to be found and cataloged, allowing multiple projects to create a full directory of data in the enterprise over time.

The introduction of a mediation component allows data to be combined from multiple sources and for those sources to change or expand without impacting the consumers. In some settings, the number of consumers can be significant (100+) making adapter patterns rather expensive to maintain.

Having a single (logical) place to go for information reduces the responsibilities of the consumer for navigation - in turn allowing systems to move, update, and be replaced with reduced risk and cost. 

The cost reductions are significant but rely on proper architecture and design.

The solution's most valuable aspects include:

Data enrichment and consistent access. It reduces the need for programmers of consumer applications to understand where data is sourced, or how it is combined. It allows us to avoid the need for consumers to understand multiple API protocols and security arrangements, and in some circumstances can reduce the impact of systems being unavailable.

Data mediation and secure access. It reduces programmer error and hides the underlying systems, making it simpler to change them. It imposes a line of control between consumer and source, reducing the scope of testing needed for new consumers, and avoiding tests on consumers when the source changes.

High-performance data management for data in motion. The product supports clustering and can be tightly integrated into IBM MQ, making it a perfect platform for payment processing and high-performance data processing (50,000 tx/sec and above). For those that do not need the performance, this translates to cloud consumption savings.

Resilient communication management. The product can use transactional integrity to assure consistent data and non-loss communications (especially when combined with IBM MQ). This means that when processing large numbers of transactions no time is lost trying to discover what was lost.

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.

We've used the solution for 20 years - since it was previously named MQ System Integrator.

IBM ACE is very well engineered and very stable. We have several customers running old versions that have been 100% reliable for their operational lives.

If an installation does encounter a failure, for example power failure, the product is good at reporting useful messages, and in combination with IBM MQ to protect data running through the system. The product can be installed in a clustered configuration to remove single points of failure, and to scale to accommodate higher loads.

It's very stable.

This solution is highly scalable and resilient. It's combined with MQ or load balancers for fault tolerance and highly parallel processing.

It's highly scalable.

In my experience, support has always been very good for this product. 

Positive

I have previously used databases to store and forward and C-programs to manipulate data. When this could no longer cope (sometime in the 1990s), I discovered IBM MQ and other messaging products, which are designed to do what we were building. The MQSI product of the time was simply magic and the latest incarnations (App Connect Enterprise) are far beyond anything that could be done with a database. 

I have reviewed other technologies, including Microsoft, open-source, and others. It remains my opinion and experience that this product delivers quicker development and more reliable outcomes.

A was working as part of the vendor team, as part of the implementation consulting organization.

Very much depends on the industry and project.

Installation of the base product has been simplified over the last five years or so, and is now fairly straight forward. 

You need an infrastructure design for the product deployment and an integration architecture and design documented and agreed to get the best from this software. It is relatively easy to program (Extended SQL, Java, and other options are available), however, it's important to think and take advice before you start.

The product is generally priced per processor core.

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

The product helps us develop integration applications. It also enables communication between applications from different environments.

The features I have found most valuable in this solution are transformation and routing.

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.

I have been using the solution for the past nine years.

I rate the stability an eight out of ten.

The people in our organization who faced scalability issues deployed the product on the cloud, where they could make it scalable. I rate the scalability an eight out of ten.

I have spoken with the support team about a couple of issues. They were really helpful, and the response was very fast.

Positive

The initial setup is straightforward. We did not face any challenges.

It took us a couple of minutes to deploy the product. We deployed the solution with our in-house team. A team of two to three administrators usually monitors the product in the production environment.

I am using the latest version of the solution. We use Jenkins to deploy the applications we build on IBM Integration Bus. My organization is one of the largest IT service providers, with hundreds of customers across the globe.

We depend on IBM for patches when there are some issues in the production environment. I am a developer, and I work in solution development. I have worked with multiple organizations for multiple accounts. I would recommend the solution to others. IBM Integration Bus is a leading product.

Overall, I rate the product an eight out of ten.

Typically, when engaging in application integration, especially when receiving data through an integration gateway, the common practice involves routing or transforming the message. This process aims to enrich the data before forwarding it to other downstream systems, and we utilize IBM Integration Bus for it.

It offers easy adaptability, allowing for seamless modifications. With versatile nodes, it facilitates effortless connections with other integration components. The platform supports diverse functionalities such as making web service calls, conducting file transfers, and interacting with databases. Additionally, it accommodates synchronous communication, addressing a variety of technical implementation needs. It effectively replaces the effort involved in such coding tasks.

It can be implemented as an enterprise service bus to seamlessly connect all applications within your enterprise. This tool serves as a bridge, ensuring a smooth flow of data across all applications, regardless of their formats or communication protocols. By leveraging its features, you can efficiently manage and facilitate communication between various applications in your enterprise ecosystem.

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.

I have been using it for more than nine years.

It exhibits high stability, consistently performing well in the majority of environments. Any disruptions typically arise only when there are issues with the underlying infrastructure supporting the Integration Bus.

While I can't provide specific user numbers, we have numerous clients across the globe who rely on IBM Integration Bus to meet their business needs. If you aim to enhance the scalability of your integration application developed in IBM Integration Bus, there are specific options and features you can utilize. This enables you to scale up your applications effectively, allowing them to handle a higher volume of requests from various sources.

I am confident that we would receive a prompt response from IBM whenever we encounter any technical issues or require technical support.

The initial setup was relatively straightforward and not overly challenging. Establishing the required environment to run the IBM Integration Bus was a simple process. All that was needed was some server space to install and bring up the runtime environment.

A common practice is the implementation of CI, CD, and DevOps tools. These tools automate the deployment process seamlessly. Whenever code changes are made and pushed, the configured DevOps tools take over, ensuring an automated deployment without the need for manual intervention. This streamlined approach enhances efficiency and minimizes manual efforts during the deployment phase. Maintenance for IBM Integration Bus is well-established. As part of routine maintenance, regular fixes are provided for the product, contributing to the overall stability. Daily monitoring of IBM Integration Bus objects is a crucial aspect of maintenance. We maintain a dedicated team that monitors these objects 24/7, both on-site and offshore. This continuous vigilance ensures that any potential issues are promptly identified and addressed, minimizing any impact on business operations.

I find it to be a highly regarded solution. If you are considering the implementation of an Enterprise Service Bus, this product emerges as a robust and effective solution for your business needs. Overall, I would rate it eight out of ten.

We used the solution for opening new accounts for a banking system. Our client used some old techniques and didn’t have an integration layer. I created an account opening application for our client.

IBM Integration Bus is a very strong tool. It helps in integrating the front-end and back-end systems.

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

I have been using the solution for six months.

I did not face any issues with the solution’s stability.

The solution is scalable.

The initial setup is easy, but the database is quite heavy for the local DC. It was also a little bit complex to connect to some databases.

The deployment of the solution is very easy. We just add the integration server and drag and drop the services to the integration server. We deployed the solution in-house. We do not face any trouble in the maintenance of the product.

I am a system integrator. In Software AG, debugging does not intervene with any other process. I also use Software AG webMethods and TIBCO. Software AG webMethods is the best product because it is very easy to develop and flexible. Overall, I rate the solution an eight 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.