IBM Integration Bus Reviews

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.

We use IBM Integration Bus with IBM DataPower for IT integration. It’s the most used and essential component. For data security and governance, we use it with HiSphere. It’s also integrated with Outlook for handling video files.

The Aspera feature for high-speed transfer is highly effective. For DataPower, we use it to export our servers and integrate with government sectors. It's also used internally to integrate isolated solutions and manage traffic overload.

IBM Integration Bus is a reliable solution that helps us handle performance challenges effectively. However, I believe there is room for improvement in the pricing structure to make it more accessible. As far as IBM Integration Bus is considered for other organizations, it has strong performance capabilities and integration features.

I have been using IBM Integration Bus for two years.

Integration Bus is quite stable, I would rate it at eight out of ten.

In terms of scalability, it's a solid ten. IBM's technical support is good, I'd rate it at an eight.    

The installation was manageable, although it required specific skills in the Open-Sec environment. It took us about two weeks to install and configure everything, depending on the environment complexity and the number of servers. Currently, around thirteen technical users are working with IBM Integration Bus in our organization.

Overall, I recommend IBM Integration Bus with a rating of nine out of ten.

I did only one PoC which is critical to the organization so I'm not an expert. We had consultants who developed most of the prior applications, but my part involved a new project to integrate with our external partners with new changes from a legacy format to amodern web service. We needed to help them connect to our service, as well as access our data. They were already doing that, but with legacy protocols. They are now moving to a modern system.

This is something that is easy to do with IBM Integration Bus. Some of the challenges were  in understanding the overall format of the data and understanding their need. Most of the time was spent in understanding and analysis rather than coding. The coding, itself, didn't take much time. For me, it was a learning curve in understanding the tool, analyzing the graphical interface, and even learning how to develop an application. We had many prior applications built and to use as examples.

My dream is that most applications should have a graphical way of expressing what you want to do and kind of get to know different parts of the workflow in the application.

My favorite feature is the XML-based DFDL mapping, which is a tool that allows you to graphically map legacy data formats to modern data formats. I like it because there is less programming involved. On the internet I do not see many users who are aware of this capability or its importance. Since I have a theoretical background in this area I was able to quickly understand its value. In the past, we had to do a lot of programming in Java, whereas now, it is just linking one node in one format to another node in another format. The linking is done in a very smart way, and behind the scenes, the solution knows what to do. For different types of inputs and outputs, the interface already knows how to do the translation or conversion. All you have to do is draw a line and make simple additions. It has reduced the programming from one hundred percent down to ten or twenty percent.

In this solution, you can design the workflow too, graphically. There are two graphical tools in this solution. One of them is for the format conversion and it is called mapping. The other one is actually developing the application itself. It is a good GUI that I really like.

This solution would benefit from improvements to the configuration interface. It is hard to understand, and one small change can have a huge impact. For example, if you say Yes instead of No in one of the configuration settings, or Transactional instead of Non-transactional, then the whole meaning changes and it is difficult to track down the problem. This is the reason that many of our projects are progressing slowly. We just don't know what is going to happen with different parameter settings. It makes it very difficult to be creative.

The only other difficult part is that IBM adds its own meta-data, in addition to the normal, generic XML data, into the tree. It's hard for us to understand how to navigate the tree and pick what we want or figure out where our own application data lies, because of the additional IBM specific data. We understand that they do things this way in order to reduce the programming, but it's more of a learning curve.

This product is very stable. 

This solution is extremely scalable. It's a top product in terms of scalability. The mechanism and capability are there, although it is a difficult problem and only top-class experts with enough experience can do it.

We have four or five people who are development users of this solution. We also have a number of public users for the application.

Technical support for this solution is extremely good. They are very supportive. Their answers are very quick, and they quickly understand what problem I am facing.

It would be nice if they visited the site so that they could see the project and what is happening. It would give them the opportunity to look at the structure visually, instead of me continuously sending ZIP files. That would be awesome.

Prior to this solution, we used TIBCO. I was not involved in the integration bus, so I don't know the history before we moved to IBM.

I was not part of the initial setup for this solution. One of the things that I have been doing is migrating from version 9 to version 10, and I have been struggling with it for the past several months.

The problems are due, in part, because there are a lot of things that we didn't know. There were mistakes in the migration because some of the things were not upward compatible. It had to do with a bug in the new version. We'd had to fix things, and we are still working on it. If the vendor would have proactively warned people about the bug then it would have been a great move.

I take care of the upgrades myself, but the maintenance is handled by three of us.

I have been working on the migration myself, but I am using a support engineer to help us. He is working very hard, spending many weeks and months with me, guiding me when I experience a problem.

I did not implement all of the applications, but I took on the responsibility to migrate all of the previous ones. This is a challenge because I was not involved in developing them. I treated it more like a recompilation problem, but some of the functions are not working. The old libraries are no longer used, so I am learning all of the new things that have to be done.

Given that I thought the upgrade process would be automatic, I did not really have an upgrade or migration strategy. I thought that all of the projects would compile. When they did not, I looked back at the manual that the previous consultants had written.

What I found is that the project structure was a little bit tricky, and it took some time for me to understand it. Things were not done in a normal way, and it did not work when I set it up as such. This meant that I had to backtrack and follow the instructions in the manual.

Most of our products are IBM, which makes it easy to integrate them.

This is a very large and complex product. It takes several people to understand every feature in it because nobody understands it completely. 

I am an architect but I also develop. I really love this product and the graphical way of doing things, but there are limitations because you are not doing hundred percent programming. Instead of programming, you are solving some complex functionality needs by configuring, and you have to understand how to do it.

For anybody who is implementing this solution, it is important to say that even though I am senior, I'm a junior when it comes to this solution. I was only brought in to work on this two years ago. It requires many years of experience to be good at it. You can't just jump on and be skilled at using it. Even when the people from IBM came and worked on prior applications, they were having challenges. Of course, the nature of the problem that IBM Integration Bus solves is challenging. All of this said, I like the graphical interface and I don't mind working on projects that are long-term.

For most of the features, I would rate them ten out of ten. But when it comes to understanding transaction related settings (and other solutions provided via the configuration settings), and the fact that there are so many documents you have to read to find one small thing, I would rate that area a five or six out of ten.

Overall, I would rate this solution a seven out of ten.

We are using Integration Bus for SOA (Service-Oriented Architecture) services. We are using it to connect APIs to servers, we are using it as an integration bus for hosting, and we are hosting our web services over it. I am using and testing this from the QA (Quality Assurance) perspective.  

The Integration Bus has provided us with a certain level of security. For instance, before we used this solution, we were directly connecting to databases through a DB link. We were able to stop that practice and make it more secure using Integration Bus. It has also provided us with the capability to reuse developed services. Services we developed can now be used with multiple systems and we are able to remove duplicate applications due to this advantage.  

Surely something that can be improved is session management. Sometimes sessions hang. Practically every day we hear about session congestion and this kind of thing. Troubleshooting the issue has become a long-standing problem. Where the true problem lies is a challenge for our support team.  

The session management issue may be a bigger problem for us because our support team is not so highly trained. Also, sometimes our developers are not able to dig down to locate the actual problem. To resolve the issue when it occurs, we have to at least restart the server. It is not really solving the problem, it just relieves the symptoms. These session management problems are the basic issues we are having, but otherwise, our services have become better after bringing in the Integration Bus.  

One thing I would like to have added to Integration Bus is a plugin — or some other software, — to enable testing the performance of our services from the application hosted on the IBM service. I think that the users of the system should be able to get something like that and somehow do performance testing on their own. Currently, I have used some studio or some plugin to find these results. Another option is using services that are available that I have also tried. If IBM could provide this same type of testing capability in its application, that that would be great. It would enable us to report to our business on the facts about how much we have improved from the earlier architecture.  

We have been using IBM Integration Bus for the last three years.  

It is a stable product especially with the release of version 10. We had problems with version 9. But now, version 10 was really a lot more stable and a lot of things have improved. We are much more satisfied with the product and stability of the performance. It is fairly rare that we are unable to troubleshoot something. But I think that most of the problems that we have, from my point of view, is because we are not better trained on the product as a whole. Maybe training could resolve some of our troubleshooting issues. Everything may not be the fault of the product.   

We had scaled up the product usage, so I know it is scalable. We were only using it with a few systems in the beginning and now we are using it with a whole bank of systems and all of the systems are integrated tools.  

The IBM partner that we are working with here is System Limited. IBM was not directly supporting us during the installation and if we have issues we work with the IBM partner.  

We did previously have another solution called BixTalk which we were using four to five years ago. One major problem with BizTalk was that we had very few people available who were actually trained on it. Secondly, there were some sever issues as well. We had a synchronization problem on top of that. Because it was so long ago I do not remember all the issues. Maybe we did have some other problems also. But we had a problem with the product support as well.  

From an installation point of view and just initially setting up this product, it required a lot of configuration. The configuration is the harder part of the installation. Otherwise, the installation was done in a few days by our team. I do not remember exactly whether we had any major problems in doing that, but it could be there were problems and I just did not hear about them.  

There were a lot of things to configure, but that was taken care of by a different department. Our operations department would be the group that handled this. So I do not have actual first-hand information because I did not participate in the process.  

It is a little hard to suggest a product for someone else without knowing anything about their situation. I would surely recommend it for companies that have lots of applications that they want to integrate. This is mostly what I would recommend it for. If you want a platform that seamlessly integrates your different applications, IBM Integration Bus for you.  

On a scale from one to ten where one is the worst and ten is the best, I would rate IBM Integration Bus as something like seven to eight. For the time being, I will give it a seven. I am pretty much satisfied with the product, but there are certainly ways I have mentioned in which it could improve.  

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 within a finance domain.

The product helps efficiently work with different connectors from different back-end systems.

IBM Integration Bus needs to be more compatible with stable connectors for specific domains. For instance, it has two protocols: ISO 8583, a legacy protocol, and ISO 2022, which works on XML for the finance sector. Similarly, they should add connectors to banking applications and other specific industries.

We have been using IBM Integration Bus for ten years.

Being in the market for quite some years, IBM is a very stable and mature product. I rate its stability a seven out of ten.

The technical support services are good.

Primarily, our customers have the product deployed on-premises to follow protocols. Some customers deploy on private clouds as well. The product’s installation and configuration process is straightforward. It takes six months to two years, depending on the complexity of specific requirements.

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