IBM Integration Bus Reviews

We use IBM Integration Bus for 600 applications that we're running.

The most valuable feature is the security.

Sometimes migration takes too long.

I have been using this solution for nine years.

It's a stable solution.

It's very scalable. When you deploy the solution, you have the option to create two different policies.

We haven't needed to use technical support very much. We reached out to IBM about a problem we had with HashMap.

I was the developer consultant.

I would rate this solution 9 out of 10.

IBM Integration Bus can be deployed in many ways, such as on-premise, cloud, and hybrid. 

The current customer that we have wants to have a hybrid deployment. We're investigating how they can manage to do it. For the hybrid deployment, they will have an instance running in a docker image, or in an Amazon AWS. The heavy operations will be done by the on-premise version. Which is what we currently have.

The most valuable features of the IBM Integration Bus are flexibility. It's also an alternative for integrating it with other projects, which we are not ready at this time to do, such as switching to tunnels. The tunnels would be used with other partners to make sure everything is secured.

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

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

IBM Integration Bus is highly stable.

We have approximately four clients using this solution.

The technical support is very good, they have a fast response.

The installation of the IBM Integration Bus was straightforward. The time frame that it takes for the deployment depends on the environment the customer has. 

The licensing model of IBM Integration Bus is good. It's a yearly subscription. However, the price is depending on the model that you choose. If it's a Cloud version, then you can pay per month or you can pay it annually upfront. There are three-year options available, but it depends on what deployment you have.

As more people are moving operations toward the Cloud. The Clouds are offering subscriptions. They will charge you based on what they're processing. Whereas the on-premise version, the vendors offer a perpetual license. It doesn't have those limitations that the subscriptions models have for the number of transactions. What most of the vendors are doing is they will more or less charge you for a small, medium, or large package based on the number of transactions and they will bill your account.

IBM Integration Bus is a very good solution and they have come a long way with improvements over the years.

I rate IBM Integration Bus a nine out of ten.

We use IBM Integration Bus as a bank middleware solution. 

The solution does omnichannel integration with the core banking and other systems, including core banking, ETC, and click systems. It does so for a host of systems. 

The solution addresses all of our middleware needs in respect of transformation, parsing, security and stability; everything really. 

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. 

The solution addresses our stability needs. 

Thus far, we have been making maximum use of the solution. 

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

We previously used a local solution and replaced this with a new enterprise solution. 

The initial setup was complex. 

Including preparation time, addressing the environment and building the POC, deployment took around one month. We are talking about active, on-premises deployment. 

There are nearly five people required for deployment and maintenance. 

Management would be in a position to address whether we have seen a return on our investment. This said, we have witnessed some returns on our business so far. 

I prefer not to address the licensing costs, or any other for that matter, as this is confidential. 

We did evaluate other products before going with IBM Integration Bus. 

We are customers of the vendor.

From a development perspective, there are nearly 40 people using this solution in our organization, although we have thousands of customers who do so indirectly. 

The solution probably covers more than 95 percent of the integration requirements. 

I rate IBM Integration Bus as a seven out of ten. 

I found all features valuable. There are a lot of connectors. 

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.

I have been working with this solution for seven years.

It is stable.

It is scalable. Our customers are in the medium range.

I never interacted with IBM's technical support for IIB. I haven't raised any tickets so far.

I also work with MuleSoft. Comparing IIB to MuleSoft, IIB is always used by big companies because it is a licensed solution, whereas MuleSoft is open source. So, small organizations use MuleSoft. Our clients in the USA, Canada, and Dubai preferred IIB over MuleSoft because they have more belief in IBM products, and they feel more secure and safe while using it.

Its installation is easy.

I would rate it an eight out of 10. It is a good product. A lot of new products have come into the market, such as Tibco, MuleSoft, but this product still exists, and clients do believe in this product.

My only client at the moment is a national government bank. Currently, the IBM Integration Bus is the integration platform for all the various departments of the bank. There are probably six or seven major departments across the bank that subscribe to or use the integration services like MessageQ, Broker, or the platform's orchestration capabilities. And we have a team of about 15 people managing it.  

Integration Bus has also been put in place to lay the foundation for hybrid integration into the two specific systems on the cloud. We are still deploying it, so we haven't gotten into any actual use cases yet. In the past, it was relatively easy for the team, but I don't think they've ever leveraged the suite's full capabilities. It hasn't been easy in some instances because the reserve bank is unique. It's not the same as other financial institutions, but we've had challenges on the platform before.

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. 

I've been dealing with IBM Integration Bus off and on for the last 15 years.

I think IBM support could be faster. It took us a while to resolve our issues because they don't necessarily have the technical resources in our country. We had to source the resources internationally, so it took a while to get that done. But once we got what we needed, IBM resolved it relatively quickly.

Setting up IBM Integration Bus wasn't simple, but we've got a unique environment. We're probably about two or three months behind on our implementation because of unforeseen interoperability problems between Red Hat OpenShift and VMware. We've got a team of about 15 overseeing the deployment, including engineers, developers, and the support staff for the platform.

I think our enterprise license agreement is included with a bundle of products.

I would give IBM Integration Bus a solid eight out of 10. I recommend it for large enterprises but only for specific use cases. You need to have a relatively mature integration practice in your organization to leverage its capabilities fully. So I wouldn't recommend it to startups or somebody new. I'd instead go open source or something relatively easy.

We are, of course, using the latest version. 

We use the solution for bridging the gap between different legacy systems. Re-usability is another function of the solution. So too, we use it to limit the challenges faced between different systems that are unable to communicate at the same speed and rate, or that need to talk among different systems, to utilize a channel which is bigger and better, to make use of the back-end or in respect of some other point-to-point integration need. As such, our uses for the solution vary depending on the customer. An example would be that which relates to a banking industry, for which there would be a core banking system, the need for card systems, ATM transactions, et cetera. Middleware plays a key role in the usability of these services. The goal is to avoid point-to-point integration between the channels and the back-end systems making use of the solution.

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

Our organization has been using IBM Integration Bus in various branches, spanning a host of  locations, since before I joined 14 years ago. It has been doing so for the past 15 to 20 years. 

I consider the solution to be one of the most stable in the market, in comparison with others such as Oracle and this assessment I maintain on an ongoing basis. I have received much feedback from customers about the solution's stability. 

The solution is scalable, but we have yet to receive the full review and feedback. This is because we have been informed that the latest systems have only recently been produced. So, I cannot give you complete feedback about the scalability of the solution at the moment. The latest deployment is on a container platform.

We have received many complaints from customers that the customer and technical support should be faster. 

I believe the initial setup was easy, but this is a question best taken up with the technical team. 

I use the traditional licensing model, which I believe to not be on a monthly basis, as the solution is not cloud-based. 

I don't mind the pricing.

90 percent of days the solution is on the client enrollment. We are hoping to encounter good business cases, involving integration planning, as the trend is for people to gradually transition to the cloud, the government initiative being that involving Azure. 

As we are a service provider, I cannot give you exact figures about the number of users in our organization who are making use of the solution. As mentioned, this depends on the customer, with each one involving its own user type. 

I would, of course, recommend this solution to others.

I rate IBM Integration Bus as 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.

It is used to enable communication between applications. For example, when application A needs to interact with application B, IBM Integration Bus provides a kind of bridge that helps application A to communicate with application B in terms of messaging. Application A might be using a specific format, such as XML, which needs to be converted into the format understood by application B. IBM Integration Bus takes care of this transformation and routing of messages from application A to application B. I have seen IIB been used in the banking, payments, and finance domains.

It makes the communication between multiple and heterogeneous applications so easy. We can bring together different messages and applications from different platforms and connect them through IBM Integration Bus.

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.

I have been using this solution for the past four years.

It is stable. There are plenty of projects that have been using this tool. My friends or my ex-colleagues who have moved to other organizations also find it good.

I don't have an insight into the scalability as such, but based on the meetings related to the maintenance of the application, I did not come across any scalability-related issues.

There were a couple of instances when my team approached them, and there was a good response from the IBM team. There were some delays, but that happened almost three to four years ago. Their support might have improved recently.

It is quite straightforward. For our project, we do have different needs. We build artifacts that are ready to be deployed. These artifacts need to be placed in a specific folder or directory. They are then picked up and deployed in the servers. It is quite automated these days.

Its deployment is quick. It is a matter of seconds.

I would recommend this solution. I would rate IBM Integration Bus an eight out of ten.