IBM Integration Bus Reviews

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 the solution for synchronizing data across the enterprise and opening data to extend its use by simplifying and making it consistent regardless of its source. 

It's for installing a line of indirection between data source and consumer to reduce contention at the source, and to add security, audit, and combine data from multiple places.

With it, we are implementing GDPR rules on data use, compensating for systems being unavailable, and delivering low latency for website users.

I have designed solutions for payment processing, Service-Oriented Architectures, micro-service architectures, data sharing and synchronization, and point to point data sharing using this product across banking, retail, and many other industries.

Many projects absorb a great deal of time and budget to find data and understand how to access it. This product allows data to be found and cataloged, allowing multiple projects to create a full directory of data in the enterprise over time.

The introduction of a mediation component allows data to be combined from multiple sources and for those sources to change or expand without impacting the consumers. In some settings, the number of consumers can be significant (100+) making adapter patterns rather expensive to maintain.

Having a single (logical) place to go for information reduces the responsibilities of the consumer for navigation - in turn allowing systems to move, update, and be replaced with reduced risk and cost. 

The cost reductions are significant but rely on proper architecture and design.

The solution's most valuable aspects include:

Data enrichment and consistent access. It reduces the need for programmers of consumer applications to understand where data is sourced, or how it is combined. It allows us to avoid the need for consumers to understand multiple API protocols and security arrangements, and in some circumstances can reduce the impact of systems being unavailable.

Data mediation and secure access. It reduces programmer error and hides the underlying systems, making it simpler to change them. It imposes a line of control between consumer and source, reducing the scope of testing needed for new consumers, and avoiding tests on consumers when the source changes.

High-performance data management for data in motion. The product supports clustering and can be tightly integrated into IBM MQ, making it a perfect platform for payment processing and high-performance data processing (50,000 tx/sec and above). For those that do not need the performance, this translates to cloud consumption savings.

Resilient communication management. The product can use transactional integrity to assure consistent data and non-loss communications (especially when combined with IBM MQ). This means that when processing large numbers of transactions no time is lost trying to discover what was lost.

The product has been well managed and continually improved throughout the time I have used it. 

There is very little that can be improved. It already contains adapters for MS-Dynamics and other enterprise packages and supports many protocols and transmission structures. 

The next versions are moving toward container use. It would be a shame to make the product highly complex just to support one pattern of deployment. It is my hope that IBM continues to focus on practical functionality that is simple and cost-effective.

We've used the solution for 20 years - since it was previously named MQ System Integrator.

IBM ACE is very well engineered and very stable. We have several customers running old versions that have been 100% reliable for their operational lives.

If an installation does encounter a failure, for example power failure, the product is good at reporting useful messages, and in combination with IBM MQ to protect data running through the system. The product can be installed in a clustered configuration to remove single points of failure, and to scale to accommodate higher loads.

It's very stable.

This solution is highly scalable and resilient. It's combined with MQ or load balancers for fault tolerance and highly parallel processing.

It's highly scalable.

In my experience, support has always been very good for this product. 

Positive

I have previously used databases to store and forward and C-programs to manipulate data. When this could no longer cope (sometime in the 1990s), I discovered IBM MQ and other messaging products, which are designed to do what we were building. The MQSI product of the time was simply magic and the latest incarnations (App Connect Enterprise) are far beyond anything that could be done with a database. 

I have reviewed other technologies, including Microsoft, open-source, and others. It remains my opinion and experience that this product delivers quicker development and more reliable outcomes.

A was working as part of the vendor team, as part of the implementation consulting organization.

Very much depends on the industry and project.

Installation of the base product has been simplified over the last five years or so, and is now fairly straight forward. 

You need an infrastructure design for the product deployment and an integration architecture and design documented and agreed to get the best from this software. It is relatively easy to program (Extended SQL, Java, and other options are available), however, it's important to think and take advice before you start.

The product is generally priced per processor core.

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.

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.

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.

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.

We are using the solution as an outer layer for all of our API calls we are making outside of our own devices. All APIs integrations are routing through the ESB only. We are using it for IIB server components and the DataPower, which is an API gateway. It is providing us with a security layer because all the outside calls do not have direct communication with our own server, this middle layer is called the ESB. 

The solution has helped my organization because any new integration coming to my backend system, we can easily implement it in a shorter time. This is because the middle layer takes care of all API language conversions or the code conversion, and also does the maintaining of the logs.

Having the solution come from IBM you know you are receiving a product of quality in components and in the services, it is very good.

I do not think there are any improvement areas because it depends on what exactly the use case for this ESB is. Some organizations are having a lot of integration and they will choose a regular ESB. While others will choose the security purpose route, making an extra layer. It depends from organization to organization, to determine how this solution can be improved from their specific use cases. Otherwise, I think that there are not any relevant improvement areas to give.

I used the solution in my last company for a long while.

The solution came to the market a long while ago, it has had time to mature. It is really stable and large organizations can rely on it. Smaller companies could too but it is too expensive.

It is a scalable solution. You can have any number of integration, it depends on the server and how much space you are providing to the IIB servers. We plan to have more than 50 wired integration by the end of the year.

The installation is not easy. You need experts who know how to install this IIB. The common technician will not have the knowledge to do it. You will need assistance installing the solution even though on IBM's website you can download the complete user manual explaining how to install the IIB servers. 

We used a third-party vendor, who help us install the solution and it was not easy. If you have most things in place at the site the whole installation process can take approximately three days. 

To do the complete deployment you will need at least one architecture that understands this IIB solution. It all depends on what kind of IP division architecture you have. Based on the project's scope, you then can define your team. There is no certain number of how many team members is required. It depends on your project, how large it is, and based on that you can decide how much manpower is required.

The solution requires a license and is very expensive here in India. Large organizations will be able to afford it but smaller companies will have a difficult time paying for the solution at the current price.

I am going to continue to use this solution, when you purchase this solution you have spent a lot of money, you have to continue to use it to make a return on investment.

I would recommend this solution if they have a large budget.

I rate IBM Integration Bus an eight out of ten.

We are a solution provider and this is one of the products that we implement for our clients. Usually, they want to use this for consolidating the services. It is used to integrate their core insurance systems with the rest of the environment.

We try to enable this kind of service-oriented architecture (SOA) to assist our clients with consolidating all of their services.

The most valuable feature is the API integration.

The integration is difficult to manage.

Migrating to this solution is complex and it would be helpful if they had a way to convert existing integrations.

We have been using IBM Integration Bus for more than three years.

From a scalability point of view, I think that this product is good.

I would say that it is good for an enterprise-level customer.

We receive our technical support through an IBM partner in Taiwan. However, developing this kind of project required asking for assistance from the IBM Lab Services. Without Lab Services, our support would not have been as strong.

Migrating to this solution is complicated and not simple to do if they already have API integration between systems.

We also work with TIBCO and Oracle ESB solutions. We find that our customers have had a good experience with them and there is always a lot of interest in these two products.

IBM Integration Bus is a good product and I would recommend it for enterprise customers.

I would rate this solution a six out of ten.