IBM Integration Bus Reviews

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.

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.

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

Our organization is a bank, so we use IBM Integration Bus for integration with core services and test applications.

IBM Integration Bus facilitates communication between parties and legacy systems. For example, the banking industry has a lot of legacy systems, so IBM Integration allows for communication between the legacy systems and new ones and allows us to develop solutions that can respond to the new ones.

We currently use version 10 of IBM Integration Bus. The most beneficial feature is the integration we have with legacy services. We can do the integration to expose other technology to stop, rest and manipulate the output of many legacy services.

We would like to separate the services into different containers, and we don't have this ability right now on IBM Integration Bus. We are currently doing this as an organization, and IBM is setting up the OpenShift.

The version of the technology and current knowledge is a bit outdated. There is also no DevOps, and the process of deploying that is the downside. Regarding additional features, we would like better integration with external solutions like Apache Kafka.

We have been using this solution for six years.

It is a stable solution. The downside is that sometimes it is easier to use another post, like a language outside of IBM Integration Bus, but overall it's a good solution.

It is not scalable.

We do not communicate much with IBM, only for initial setup and completing bootstrapping technology. However, we have IBM partners that work with us. I rate the technical support a four out of ten because they are sometimes a bit selective with the partners they pay attention to.

Our company has been using IBM technology from the beginning.

The initial setup is difficult to configure and set up the first time. I rate the setup a four out of ten.

I rate this solution a seven out of ten.

IBM Integration Bus is mainly used to integrate banking systems.

IBM Integration Bus' most valuable features are its performance, fast and easy development, and easy support.

Some of the runtime properties need to be improved because if you want to load certificates as sales security, you have to restart the server. There are also some bugs with file transfer protocol.

I've been using IBM Integration Bus for three to four years.

IBM Integration Bus is very stable.

The initial setup was straightforward, and IBM has a great knowledge base to help. I would rate the setup experience as four out of five.

IBM Integration Bus is expensive.

I would give IBM Integration Bus a rating of nine out of ten.