IBM Integration Bus Reviews

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 the solution for a digital payment system.

The Cloud Pak for Integration is a useful feature.

The solution’s pricing could be improved.

I have been using IBM Integration Bus for five years. We are the solution provider.

The solution is stable.

The product is scalable. There are four customers using this solution.

The initial setup is not complex, but you should have a good understanding of programming. Installation depends on the project. For some projects with a limited interface, it takes two to three months, but for a bigger and complex one, installation can take up to six months.

In banks, it is deployed on both Cloud and On-premise.

The solution is expensive.

Overall, I rate the solution an eight 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.

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 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 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 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 are trying to use IBM Integration Bus in our organization. We have multiple things to do. Like DataStage, we also have SAP BODS as another ETL. We are also using JAM Server and Java. 

Instead of separately writing the Java code and restful web service and then using the ETL and JAM Server to call on a file basis, I am thinking of using IBM Integration Bus. I have a message flow. Once I drop a file, IBM Integration Bus will pick up all the functions, do everything on the MQ Server, and finally fit it with the web service, which is also created in IBM Integration Bus. I would have the complete message flow in one architecture site. I can apply it by using ETL, Java, and the JAM Server. However, it is failing at the data mining stage itself. It could be because of my lack of knowledge of IBM Integration Bus.

I use the integration of Kafka and the message flow, which is really good. It is also good for moving any file from one location to another. 

Using IBM Integration Bus in the data stage is pretty simple. You can see the preview and other things.

The MQ server integrated with IBM Integration Bus is really great. I don't have to do a lot of configuration from that side. It is really good.

It needs improvement in terms of technical support as well as in terms of integration of data mining. I am not convinced about many things in this solution, such as the conversion of the DFDL or copybook file, which is the conversion from a text file to XML. It is very complex.

They should also provide more information about this solution in the IBM Knowledge Center. I can get a lot of information from the IBM Knowledge Center about DataStage, but I don't get that much information about IBM Integration Bus. There is hardly any information even on the internet and various channels such as YouTube. They can provide good step-by-step documentation based on a company's requirements. It would be really helpful.

My company is mainly looking for data mining and communicating with multiple servers. IBM Integration Bus is good for communicating with multiple servers, but it needs improvement for XML conversion and data mining. We have a lot of old systems that use XML.

I have been using IBM Integration Bus for two to four months.

I contacted technical support, but I wasn't able to get the correct answer. I feel I wasn't given a good response. I was communicating with a person from technical support, and he took two to three months to help me with the support. Finally, he delegated that ticket to some other person, and he resolved my issue in one week, but the solution was not convincing. 

I wanted to know how DataStage does one-to-many and many-to-one mapping because it was failing in IBM Integration Bus. I have a DFPL file, and I have an XML Schema. I want to map the added element from the DFPL file to the XML Schema. The technical support person was saying that you have to write the ESQL code for mapping, but I don't know how many elements are there. Suppose I have 100 elements for one area at present, but next time, I might have 90 elements. He was saying that you should know somehow where IBM Integration Bus is failing, but there was no way to find that out. The mapping for that element was not there in the dynamic run-time query.

The initial setup is complex. It is not user friendly. When you have a file in the MQ Server, it moves to the next directory, which is the output. It is very complex to call a web service. It should just give the setup of the endpoint and do some basic stuff so that it can be consumed by the web service. It might be complex because of my less experience in using IBM Integration Bus.

I would recommend this solution if you are not doing any XML conversion or data mining and just want to use a message flow, such as reading a file and transporting to another location and then calling some message and integrating it with an existing system such as Salesforce.

If you have a lot of integration, I would recommend hiring some experienced people for it. IBM Integration Bus is a very big product, and people don't know even 20% of this product. If people have good knowledge of it, they can really do a lot of stuff. Based on my understanding, its complexity is the reason why people don't have good expertise in this product. I am an experienced Java professional, but I am facing a lot of difficulties in understanding IBM Integration Bus.

I would rate IBM Integration Bus an eight out of ten. It needs improvement for data mining, DFDL, and schema converter. There should also be more documentation and information in the IBM Knowledge Center.