IBM MQ Reviews

We're using the IBM MQ series in development, integration, UAT, and production areas.

What I found most valuable in this software is its reliability because messages that are sent into the queues are consumed by the other end of the connectivity. It has helped us maintain integration between two different systems, so that has been part of one of the layers of our architecture that communicates, for example, a back-end platform and back-end core system with a front-end platform. In our case, we are using the backend as a 224 banking system and the frontend we are using the Wall Street front office system. Those two systems are interconnected via the IBM MQ series.

An area for improvement for this software is that sometimes, messages are not consumed in the queues. We have seen queues where not all messages are emptied. That issue has been solved by our IBM team located in Spain, but we haven't received detailed technical information as to why those queues are not totally consumed. A probable reason could be some service and availability issue because of server updates in IBM MQ itself, or server updates related to the operating system, which in our case, we are using Red Hat Linux.

I have seen a lot of problems with the file transfers, e.g. using FTP or SFTP or LFTP. Normally with all these kinds of transfers, they are not on a transaction boundary, meaning a transfer can fail during the execution. We are not certain why it hasn't reached the destination as these protocols are not transactional which you normally have in MQ messages. What I would like to see in the next release is a solution for the MQ file transfer. I saw some literature about it, but I am not sure if the feature is available, or if it will be easy to configure and maintain in the bank.

We've used IBM MQ within the last year. We've being using it on a continuous basis because it is the secure platform we have in our banking system.

IBM MQ is very stable. It's the best server in terms of interconnectivity. The reliability that the MQ series has, I haven't seen in other servers that are also based in MQ.

My impression of the scalability of this software: We started with a very easy installation where we have very few queues defined. Then, we had a huge integration where we applied, pulled, and observed that the scalability is very straightforward. We also found an easy way: making an active-passive configuration automatic. For example: If you have one active server going down, the passive server is switched on automatically, without us needing to do anything from our end, which means the active-passive configuration works properly.

I haven't been involved in contacting IBM's support, but in general, we didn't have any vendor issues.

The setup for this software was very complex, particularly with the integration between the two systems I was talking about earlier: on the core backend and on the user frontend that is the Wall Street system. It has a lot of different types of flows, and all those flows are defined into the server that is called TTI that is working under the MQ series. That contains a lot of complexities because the vendor of the front-end system has included in the MQ side the server functionality for the application, instead of doing it directly in either the backend or the frontend. This means the MQ part is also helping with the logic for processing messages, and the logic is maintained in a layer: the MQ layer in the server that's called TTI. This is the first time we have faced such complexity, but regarding the MQ as is, meaning the vanilla version, it is quite straightforward. That server works the proper way.

We used consultants for the implementation and those were consultants from the vendor who were already experienced in the TTI server.

The licensing for this software is on a yearly basis, but the bank is holding just one license for the entire bank: a corporate license. As for additional costs, it's a standard fee that includes the maintenance and updates that are released periodically.

I didn't download Active MQ and IBM MQ. I was checking on the website because I wanted to know certain functionalities about those two series. So what I downloaded was the literature about their functionalities.

Regarding IBM products, the only one that I was working with was the MQ series.

All products in our organization, particularly the banking systems are on-premise. We are not yet ready to do cloud deployment.

Deployment of this software in the TTI part took three months. For the core part, deployment took approximately one month. The time that it took for deployment is also associated with the number of servers that we had.

We have four groups: development, integration, user acceptance test, and production. In each of these groups, they have their own MQ servers. We started with the installation for the development group, then going forward and solving the issues we found at the beginning with the installation instructions. We continued with the other areas until we reached the production server recently, back in mid-October.

We currently have 200 users of this software.

Deployment of the IBM MQ at core requires two people in our organization, but for the personalized application or the customized one, we have 10 people.

I'm rating this software a five because it is quite expensive and complex. I'm giving this a five over ten rating not just because it runs, but because it has a lot of features.

I think the whole product is useful. Their database and all is very good, and the product is fine. The fact that it ensures message delivery is probably the most important thing. I also like that you're able to trace and track everything. If it doesn't arrive at the destination, it will go back to the queue, and no message will be lost.

They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java. 

Many things should be done out of the box, like MQPUT directly to databases or MQGET to link to the main database. MQ should be able to connect to any language and just do it whether you're using mobile apps or web apps. It should be possible. 

The other probably more key thing is that to get IBM on-premise is hard because there are no freely available videos and courses. Technical support in Australia could be better.

I used to be an MQ specialist 20 years ago, and now I'm a solutions architect and consultant who sometimes recommends this solution to clients.

I think IBM technical support isn't too bad. IBM support can be a bit slow. Someone should be able to check on the problem straight away. 

I know that IBM in the States is very good. You can get good IBM staff and engineers and architects 24/7 or from 09:00 to 05:00. They have highly skilled and highly experienced staff there. Here in Australia, it feels like it's run by an account manager and run by salespeople. It should be run by architects and engineers and not by the account managers and sales teams.

I think IBM needs to look at its pricing. The prices of IBM products should be simple. The old way of pricing should now be moving on to the cloud to be pay as you go, a plan-based kind of pricing.

To become competitive, they actually need to move to AWS and Azure. If they really want to be highly available, they can have a highly available location, and charge another price.

On a scale from one to ten, I would give IBM MQ an eight.

I use the solution in my company since our clients always go for a middleware solution. IBM MQ is a part of the middleware solution category. When I design a middleware solution for our clients, I use IBM MQ to basically store the message.

The most valuable feature of the solution stems from the fact that it offers guaranteed delivery of messages to users. One good thing about the product is the guaranteed delivery since it guarantees that the message won't get lost. My company uses IBM MQ since we handle a lot of asynchronous modes of the design flow, and that is why we choose to use the solution to host the message before we proceed with the other sub-processes. The tool is effective in areas like message delivery and managing large message volumes. It is a very good solution.

In IBM MQ, the channel connection is an area where my company faces some limitations. At times, we hit limitations on the connection, meaning the connection is fully occupied.

I have been using IBM MQ for more than ten years. My company is a reseller of IBM tools.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution an eight out of ten.

I rate the technical support a nine out of ten.

Positive

The product's initial setup phase is very easy.

The solution can be deployed in an hour.

The tool saves on development, implementation, and operation costs. The product is quite easy to maintain.

If one is cheap and ten is expensive, I rate the tool's price a seven. The product is expensive.

Maintenance is quite easy when there is an upgrade of any version. You just need to migrate the configuration to the other platform, and it is quite easy.

I rate the tool a nine out of ten.

MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.

The system integration is good. 

The pricing needs improvement. 

I have been using IBM MQ for six years. 

The scalability is a nine out of ten. 

The initial setup is complex. 

Overall, I would rate it an eight out of ten. 

IBM MQ is the standard for financial industry messaging. As far as I know, it is the best in class.

The most valuable feature of IBM MQ is it has all the features necessary for contemporary messaging, not only for the financial industry but for any application.

IBM MQ has developed into some newer solutions. It has a message broker, it is now on the cloud, it has containerization, that has high availability features

IBM MQ may not be as convenient for Java programmers as Active MQ, for example, because Java programmers prefer Java, even though it is slower.

IBM MQ could improve by adding more protocols or APIs for a standard application, such as MuleSoft.

I have been using IBM MQ for approximately 15 years.

IBM MQ is stable, performs well, and is highly reliable. They guarantee message delivery.

The scalability of IBM MQ is good. There are cluster, container, and broker features available. It scales well horizontally and vertically.

Most of our company is using IBM MQ in my company.

The support from IBM MQ is good. They have always helped with my problems, but sometimes it can take them a while for a resolution. Sometimes you might find a bug in a one-year span of using the solution, but they will provide a fix within a matter of weeks.

Positive

The initial setup of IBM MQ can be straightforward if you have the documentation, it is step-by-step and straightforward.

IBM MQ is an expensive solution compared to other solutions. However, if you pay less you will not receive the same experience or features.

It may not have all the APIs, features, or protocols that the newest systems have, but in performance and reliability, it is the best.

The amount of people needed to maintain the solution depends on the company and how they want to maintain it. When I was working for a bank I supported 300 MQ managers with approximately 150 systems running. However, for the basic use of the solution, you do not need many people. If you add more features, such as broker and clustering you will need more people for maintenance.

My advice to others is this solution is the best there is. For maintenance, you will probably need fewer people to maintain it than other solutions because of its reliability. The features are probably the most extensive in its class.

I rate IBM MQ a ten out of ten.

There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

The publish and subscribe features are the most useful aspects of the solution.

It's not too difficult to set up the solution. 

It's stable.

Technical support is quite helpful. 

The moment you send the data, there is no latency there.

We haven't experienced any data loss. 

If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great. While you may not be able to edit your messages, at least if you could look at them, see the queue, and what's inside, et cetera, that would be helpful. We'd like visibility on the health of the environment. 

I've used the solution for two years. 

The stability is good. In fact, we have not seen any issues. Only recently have we observed an issue. There was a limit on the number of messages it could contain. We are having an issue now, however, we have not usually seen any issues related to IBM MQ. Therefore, in general, the solution is stable. I'd rate its reliability eight out of ten. 

I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

We handle about 300 to 400 transactions per day. 

Technical support is very helpful and responsive. We are satisfied with the level of support we get. 

Positive

I have previously used TIBCO EMS as well. 

The initial setup is pretty easy. It's not that complex. I'd rate the ease of implementation at a seven or eight out of ten.

The deployment time is pretty short. It's not a long process. 

In an integration scenario, like payment processing, where the payment has to go to the backend system, SAP, or talk to multiple applications, due to the fact that it's a lengthy, complex business process, we just decouple it. Some of the information we get immediately after receiving the request, and we pass on the information to the customer. Then, we put the payload into the IBM MQ, and then we started processing from IBM MQ. So there are integrations that sometimes need to be done or worked with. 

We have an admin team that does the configuration and setup of the solution. They can do it in one or two business days. 

We have witnessed an ROI while using this product. For example, we've had no data loss since using the solution

A different team handles the setup, and likely they also handle the licensing. I don't have any visibility on the cost of the product. 

I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

I'd recommend the solution to others. I'd rate it seven out of ten overall. 

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

All the features are valuable.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

I have been using the solution for ten to fifteen years.

The solution is rock-solid and stable. 

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Customer support is good but there is room for improvement in their process. Their support is 24 hours so if you are dealing with support in the U.S. and it is passed over to a support person in the UK for example the person in the UK will not be provided with a detailed log of what has transpired. A lot of time is wasted waiting for them to catch up by reviewing the information each time the case is passed to a support person in a different country.

Neutral

If it is a standalone implementation, it is straightforward. If the implementation is the higher availability mode, XM mode, it becomes a complicated process because it comes with a shared disk resource where one instance goes down, and another instance comes up. This means it can not always be an Active mode, you require an Active-Passive mode all the time. This can increase the setup cost and complexity.

Implementation was done in-house and it took a couple of hours.

Within the first two years, you will see the initial cost returned. 

The fee for this solution is on the higher end of the scale. The licensing fee is high.

I rate the solution nine out of ten.

We currently use the solution with 30 to 40 applications across the organization. It requires four to five people to maintain the solution including engineers, application support, an architect, and integration engineers.

For all the cases where IBM MQ is no longer required, we are migrating to a different solution (Kafka). 

The solution requires a lot of work to implement and maintain. I would suggest looking at other more modern solutions depending on what your organization requires.

I am an integration developer at a bank, and we use IBM tools to develop our solutions. We use IIB (version 10), IBM App Connect (version 11), IBM MQ (version 9.1), IBM web servers, and IBM ODM. We use IBM MQ for exchanging messages between applications.

It is useful for exchanging information between applications. 

It could always be more stable and secure.

I have been using this solution for about three years.

I didn't use anything before IBM MQ.

It was straightforward. It took less than a minute.

We didn't use any integrator. We have a team of about five people who work with this solution. We have developers, a team lead, and a project manager.

I would recommend this solution to others. I would rate it an eight out of 10.