IBM Integration Bus Reviews

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.

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.

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 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 primarily use the solution as a basic integration platform for all the complicated technology solutions we have.

The solution's features are all quite useful. We use all of them.

Currently, we have some custom solutions for logs; it would be nice if these solutions could be provided out of the box.

The solution doesn't have a standard testing framework that can be used for integration performance and other tests. 

The user interface could be improved in a future release.

The solution is stable.

The response from technical support is typically quick. However, sometimes when we ask IBM to fix coding, that can take several months. I understand this is because the product is quite sizable.  They can often answer our questions without having to fix the entire product itself and they give a quick and detailed response. 

We previously used other solutions, including Oracle, specifically Oracle Fusion Middleware. IBM is much better. It has many more options and offers more functionality. IBM offers better customization, configuration, and options in general.

The initial setup is reasonable. However, the product requires administrators and developers to spend some time studying or to have previous experience.  Deployment is very fast. 

The first time we purchased the tool, we worked with a consulting company that assisted in the implementation. Now that we have experience, we handle it ourselves.

I'd rate the solution ten out of ten.

We have used IIB as a complete ESB solution with IBM MQ for various financial institutions. IIB supports various connectors, message formats, and transport protocols.

Its transformation language, ESQL, is easy to learn and use. Rich support of the mapping node (GUI mapping), JavaCompute Node, XSL, etc. make it useful and developer friendly.

IIB 10's primary features:

1. REST API design and development support out-of-the-box. OpenAPI compliant.
2. Lightweight run time, hence it is ideal for Docker/microservices implementation.
3. Several ways to admin using web interface, REST API admin capabilities, and console administration.
4. Long list of already built-in connectors for legacy systems (CICS, MQ, etc) and modern system connectors (Salesforce, LoopBack, etc.).
5. Long list of parsers (XMLNSC, DFDL, JSON, etc.).
6. Easy to understand documentation with a huge list of examples and tutorials.

• We were able to implement REST APIs quickly by using out-of-the-box support for design and implementation.
• IBM support is exceptionally competent and quick.
• It has been on the market for a long time, so getting skilled resources is convenient. Therefore, you will see your team growing and learning it quickly.
  

1. REST API design and development support are useful. Building and exposing APIs using GUI API designer with editor makes implementation a breeze.
   
2. Pub/Sub support (using IBM MQ) and MQTT broker support bring complex patterns (CQRS, etc) and services to life real quickly.
3. Web interface, REST API for viewing services, admin, stats, and deployment are premium features, which makes IIB stand among its competition.
4. Several connectors for various different protocols.

1. My biggest concern is its MQ dependency, which are still not 100% independent. E.g., in the case of aggregation flows, IIB needs a complete overhaul for aggregation implementation to achieve orchestration implementation.
2. Development toolkit (based on Eclipse) should be improved in terms of responsiveness.
3. It lacks unit testing framework similar to JUnit for Java or MUnit for Mule ESB.
4. IIB run time and installation still need to shed more weight and become lightweight for to become full Docker applications.

No issues. It is stable enough.

No scalability issues.

IBM support is fantastic and quick.

We did not switch. Wherever I have implemented it, it was either:

1. IIB/WMB was already there.
2. It was the preferred choice.

I would rate the initial setup (with MQ) on AIX and Linux as a six out of 10, as it needs expertise.

We implemented it in-house.

We are going through digital transformation journey. For now, the solution is helping us.

1. The IIB setup is still very command-based. The implementation is not so easy.
2. It still needs a lot of environment and OS-related tweaking.
3. Pricing is on par with its competition.

We evaluated Mule ESB. We didn't consider because:

1. Mulesoft was relatively new. Hence, it lacked skilled resources.
2. The cost was high compared to IIB.
3. The client had a good relationship with IBM. 

IIB is a great product. It could use some minor improvements, such as: 

1. IIB toolkit needs design overhaul; maybe some themes.
2. Current aggregation implementation should be deprecated. MQ independent, as well as an intuitive solution, should be proposed.
3. App Connect Enterprise (IIB's newer version) might solve the above issue.

We use it for migration.

The most valuable feature is that it's robust and its time to market is very short.

In terms of improvement, the UI should be more user-friendly.

I have been using IBM Integration Bus for five years. 

It's very stable and very easy to scale. 

We have the VR application version of our support now but they have been very supportive. 

The deployment takes about a week or so, it's lengthy.

We're satisfied with the price, it's okay. The terms and everything are decided by the company. It's not a big deal for us.

I would rate it a seven out of ten. 

I would recommend it.