IBM Integration Bus Reviews

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 the solution for supply chain management between ERP systems and warehouse management systems. We use it with multiple external partners.

The solution has improved our organization in the sense that it offers new graphical user interfaces and protocols. The fact that they have been made available has helped out business.

The solution has a variety of valuable features.

The ESB characteristics are great. The transformation, protocol bridging and routing are great.

The list of features on offer are both useful and actionable.

The cost is pretty cheap, compared to what else is available in the market.

The solution has been on the market for ten to 15 years, so it's had a lot of time to develop.

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

I've been using the solution for ten or more years. It's been over a decade since I originally started using the product. I've been working at this particular company as an enterprise architect for the last three years.

The solution is very stable. It's reliable.

I don't recall experiencing any bugs or glitches recently. It doesn't crash.

The solution is scalable. When we need to expand the solution, we can do so easily.

We have about 5,000 integrations on the product. 

It is an integration platform, so everybody related to supply chain management uses it, and eCommerce as well.

We've dealth with technical support in the past and have been more than satisfied with their level of service. They are knowledgable. They respond quickly. I'd rate it nine out of ten overall.

Although we didn't use another solution per se, we do use MuleSoft. 

MuleSoft is more lightweight. It's not as monolithic. We use MuleSoft and another IBM solution. However, we've been using IBM Integration Bus for such a long time at this point. It's been ten to 15 years or so. We've only used MuleSoft for the last three years. It has high productivity and a good number of integrations and the API exchange capabilities.

We run the solutions in parallel.

MuleSoft is a pretty good solution, however, we've noticed that the pricing over the last few years has gone up and it's become quite costly.

The solution has been on the market for over a decade, so the initial setup is pretty straightforward. They've had time to perfect the process. There's also a lot of people who understand how to install it, as it's a mature product with lots of history. Many people have worked with it.

The pricing is pretty good. We've noticed that it's quite reasonable, whereas, for example, solutions like MuleSoft are rising. Salesforce recently acquired MuleSoft and has grown its market share, however, the pricing is turning people off. IBM is much more reasonable.

We're IBM customers. We don't have a business relationship with IBM.

The solution is deployed on an underlying platform in the traditional MQ.

I'd rate the solution seven out of ten. I'd rate it higher, however, it's not user friendly. That said, it works really well.

I worked with Integration Bus for a UK-based insurance client and banking domain client. Our main use cases are for integrating different systems. We were involved in integrating their master data management domain.

The message queue connectors are the most valuable feature. They have built-in connectors for most of the systems, like SAP and Oracle Database.

The password settings need improvement. 

I have been using Integration Bus for five years. 

The solution is highly stable. 

The scalability is very high. 

The initial setup is straightforward. 

The pricing of the solution is high. 

Overall, I would rate the product a ten out of ten.

Whenever we want to secure our data, we connect to IBM Integration Bus, and they use that for security.

One very good feature is the UI, and it's easy to understand how to implement the tool.

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.

I've been working with the solution for almost five years.

The solution is stable. I rate the solution's stability a five to six out of ten. 

The solution is scalable. I rate the scalability a five to six out of ten.

The initial setup is easy. If the customer requires any API on any server, it should take a maximum of five to six seconds to deploy.

The solution is easy to understand, and it's a good tool for development and security. I rate IBM Integration Bus a nine out of ten.

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.

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.