What advice do you have for others considering IBM MQ?

I would like to rate it as a seven out of ten. It is quite stable, but it needs to have more documentation, and that is why I rate it as a seven out of ten. At this moment, we don't see a use case for implementing AI, but it is definitely in our roadmap. We will definitely try to find a use case to implement any new features that get announced.

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.

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

Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages. I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.

I would recommend IBM MQ to others depending on their budget and specific requirements. While it offers robust features, its cost-effectiveness varies based on the client's needs and financial resources. I would rate IBM MQ at 8.5 on a scale of 1 to 10. While it offers robust features and reliability, improvements in documentation, ease of configuration, and support consistency could further enhance its value.

IBM MQ streamlined our company's application-to-application communication since it is a rigid and robust solution that allows you to transfer data from one system to another system using the tool's adapters. In general, the product is very robust. A scenario where IBM MQ reliability was critical for our company's operations includes an incident involving three to four of our clients who use the product, among which a few are airports situated in regions like Delhi and Bangalore in India. All the big airports use IBM MQ as an integration platform, so it is considered a tier-one application. In the aforementioned areas, there is a need for a tool that offers scalability and robustness. The feature of IBM MQ, which I found to be most instrumental for our messaging needs, stems from the fact that my company never lost messages when we were using the product. The product has a queue manager, and the message doesn't go anywhere until and unless you read it. The best part of the product is that it ensures that there is no data loss. IBM MQ's security features have enhanced the data transmission process in our company since it functions in a very secure manner. Nobody can get unauthorized access to the product. The product offers very good scalability to support business growth. IBM MQ's integration capabilities with other systems are beneficial since we have developed many interfaces for many airports. Many systems use IBM MQ to send data from one system to another, so it has helped in a great way when it comes to the integration part. I rate the overall tool an eight to nine out of ten.

It is a very stable and scalable product and is a market leader in its appropriate sector. I rate the overall solution an eight out of ten.

I recommend this solution and rate it eight out of 10.

I rate the solution an eight out of ten. The solution is good, but the clustering model can be improved. My advice to others considering the solution is to check other products on the market and ensure their product of choice complies with everything they need. They should go for IBM MQ but ensure they carefully read the terms and conditions and view the price beforehand. Alternatively, if they want to go with a more lightweight solution that is just as reliable, they should review RabbitMQ.

We are customers and end-users. We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises. If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However, it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities. I'd rate the solution nine out of ten.

I would recommend IBM MQ to others that are using major transaction processing. I rate IBM MQ an eight out of ten.

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.

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 would absolutely recommend IBM HQ to others as a very robust, reliable, responsive product. I would give IBM HQ a rating of nine out of ten.

If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost.

I'm not following the versioning part. I'm not sure which version we are using currently. I'd advise new users to try it out as it is easy to integrate, scalable, and stable. I'd rate the solution, in general, at a seven out of ten.

I would rate IBM MQ an eight out of 10.

I would recommend this solution to others. I rate IBM MQ a nine out of ten.

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

I am satisfied with the solution overall. We have five to six people for the maintenance of this solution. I rate IBM MQ an eight out of ten.

I rate IBM MQ seven out of 10.

We're IBM partners. So far, I am satisfied. I'd rate the solution eight out of ten. I'd recommend the solution to others.

I rate this solution a ten out of ten because we have no issues with it. The solution is good, but improvements could be made to the dashboard.

I would rate IBM MQ seven out of ten.

I would rate this solution 9 out of 10.

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

Overall, I am very happy with this product and my only complaint is that the price is high. I definitely recommend it. I would rate this solution an eight out of ten.

I rate IBM MQ nine out of 10. It's a good solution.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do. I would rate this solution an eight out of ten.

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.

We solely make use of IBM MQ and are an MQ customer. I rate IBM MQ as a nine out of ten.

We are an IBM partner. I'd rate the soluton at an eight out of ten. For the most part, I've been pretty happy with its capabilities.

I rate IBM MQ seven out of 10. It's a good option for anything banking-related where you need secure communications. There are some other similar products out there, but I'm not about other servers. But I'm aware of our BME. So if you're doing banking or anything that requires secure channels, I would recommend IBM MQ.

I recommend this product and rate it a nine out of 10.

I recommend others use a more cloud-native approach to messaging. I rate IBM MQ a seven out of ten.

If you want a robust enterprise application that you know is going to be around that you can trust and you are very comfortable with the concept that you are going to pay for that stability and robustness, then IBM MQ is the best choice. If you are on a lighter throughput or you do not need to worry about the robustness as much then Rabbit MQ could be the better choice. It is a fairly stable application, and it works very well but you do not have that industrialization and long-term code benefit that you receive from IBM WebSphere. If your use case and budget fit then this solution would be a great choice. We have used the application for a long time. I understand it, how it works and therefore I feel comfortable with it. From a pure usage standpoint, it is great. It will handle anything, but you have to be willing to understand that you are getting into something you cannot go backward on very easily. You cannot easily swap another suitable or similar application out without a lot of work involved. You have to be very careful what you are trying to accomplish with your software. I rate IBM MQ an eight out of ten.

IBM MQ was the first product that I got introduced to when I started my journey with IBM. This is my 14th year in this industry, and I see that this application is still very much useful and applicable. So I always recommend IBM MQ, and this is one of the most popular IBM products. I would rate it at seven on a scale from one to ten.

We're just a customer and an end-user. I'd recommend the solution to any organization. I'd rate it ten out of ten. It really provides everything we need.

I would recommend this solution. However, there are some emerging competitors on the market that provide a competitive alternative. I rate IBM MQ a seven out of ten.

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost." I guarantee there are solutions out there that can do just those three things. I rate IBM MQ a six out of ten.

I would recommend this solution and suggest you start using it if you have the budget. It's very stable and robust. It's a proven technology, so no one needs to worry about that. It all relies on the budget, that where all of the problems are. People want to use open-source, and businesses do not have a budget. It's a good product to use. I would rate IBM MQ a nine out of ten.

I would definitely recommend this solution, but it also depends on your needs and business case. I have been using IBM MQ for the last 14 years. I am very much used to it, and I like it. I have used other products too, such as RabbitMQ and Kafka, but not that much. I would rate IBM MQ an eight out of ten.

We're just a customer. We don't have any business affiliation with the organization. On a scale from one to ten, I'd rate this solution at a nine.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature. I would rate IBM MQ an eight out of ten.

I'd recommend the solution. It's a very stable solution and very resilient. If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way. That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

My advice would be to rethink the cloud strategy. Make sure to have certain components that you can put into the cloud. Think about cloud-first properly so that it scales automatically. It knows how to work with some of the container services that are out there so that it scales better. It has some cloud components that are good but you still have quite a strong on-prem infrastructure to support it. It's quite a complete solution. They have modules and stuff that they acquire and may add on as features and modules, additional modules, which is a very complete solution. It's been expensive to keep going the way we're going. And the turnaround is a bit slow, slower than we want. The business is changing quite rapidly, being in retail so we need to pivot quite quickly. And so that's why we're looking at seriously moving towards the cloud where we can simplify some of our processes and actually even our maintenance in it and the way we operate. I would rate IBM MQ a seven out of ten.

It's expandable but it will add costs that should be taken into consideration. I would rate it an eight out of ten. In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers.

You must be careful in that it must fit what you want it to do. A few years ago, we had a silo approach where everybody had their own IBM MQ and their own application support with their own teams. That got out of control. In the last few years we realized that you need to be careful about the deployment model you're using. And you need to make sure it's used for the proper use cases. That's really the biggest lesson I've learned from using IBM MQ: You need to be very sure about what you want it to do. I would advise that you talk to someone who knows about the solution and who is not biased. Set up a call with someone like me to look at the solution before you decide to go down this path and, similarly, before you decide to throw it out. Talk to someone who has at least seven years of experience with it and who can give you an unbiased opinion about how it works, and then make up your mind. People have come to us and we have said, "Based on what you are doing, we don't think MQ is the best solution for you. You should be looking at other solutions." And other times, we'll tell them that this is the perfect solution. The way MQ works is very good from a messaging point of view. There is very little that needs improving. MQ is very flexible and very tunable. We use it to transport hundreds of thousands of messages every day with absolutely no problems. At the moment the solution is on-premise. But in the last two years, the bank has decided that it needs to go with the public cloud. So in the last two years, most of our development has gone towards decoupling MQ because a lot of the vendor applications were on the box where MQ was. We're working on the solution and decoupling everything so we can push toward the cloud itself. The solution's built-in connectors are more applicable to when we talk about cloud solutions. As for containerization, eventually we will go for it but, at the moment, we don't use it. It's difficult to work on a mainframe because of the way it's set up. But it's definitely something the guys will be using when we look at the Unix servers and other boxes. For deployment and maintenance we have a team of eight people. We have three people on the mainframe and another three to four people for the appliance. They work with each other as well. On the Unix solution, which includes Linux, AIX, etc., we have another team of four, but all these teams overlap. The average upgrade won't take less than two people, but on the Unix box, upgrades are straightforward and someone can do it on his own.

It's a good product but I think it's too costly. That's one disadvantage because there are already many open-source products, like RabbitMQ, Kafka, and ActiveMQ. If you really need a solid MQ solution then go with IBM MQ. If you don't need such a robust solution then you can go with any of the other solutions. I would rate IBM MQ at seven out of 10. It has less throughput.

I would recommend it to other people. When somebody wants to do colocation with us, we force them to buy IBM MQ.

If you use it for evaluation purposes, it's good but if you're using it for freeware, it's not so good. Multiple fault tolerance and partition tolerance are great. I would rate it a seven out of ten.

If you have mission-critical applications that rely on an exchange of data, and the data is very valuable, then I would suggest using MQ. We have a team of people of 50 to 60 people using it, in middleware admin.

My advice to someone who is looking into using IBM MQ would depend on their budget, the application criticality, etc. If applications are less critical, you can go with open-source products. Apache Kafka is growing quickly. People are using it on almost every project. The future will be Apache Kafka only and there might be some RabbitMQ use as well. But I see that Kafka is gaining the most. IBM MQ won’t support large streams of data but Kafka will support large streams of data. For example, for Big Data projects, will only go with Kafka.

This is a good product if you are looking for 100 percent stability and reliability, as opposed to implementing an open source solution. I would rate the product as a seven (out of 10).

I would rate it an eight out of ten. Not a ten because of the pricing.

I would recommend the solution, but it is very costly.

If you have a lot of money then I would, of course, recommend IBM MQ.

Before joining this company I was mainly consulting for various companies in Germany, and I noticed the core problem was always that in projects where MQ was implemented, they were targeting too low on the management food chain. You need that to go as high as possible because it changes the whole paradigm, your ways of thinking. A lot of the implementations were bad because they were partially patching some problems at the bottom level. The whole strategy was never oriented to messaging. My suggestion would be to be aware of that. Go global from the start. Don't address things partially. There is a team of four people who supervise all MQ activities here. I would rate IBM MQ at 10 out of 10, but ACE or Broker are between eight and nine, because of the lack of transparency.

We are happy with it. I would give it an eight (out of 10). We are not using containers.

If you want high availability with little maintenance, choose this solution. We don't use containers yet. I would rate the solution as a nine (out of 10) because it is not perfect.

I would rate the product as a seven (out of 10).

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.

I would tell people to use this, except that the pricing and support costs are too high. I would rate MQ at eight out of 10.

I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.

Apart from IBM MQ, we are using IBM Integration processor. We are pretty satisfied with the product. I would strongly recommend the solution, depending on the elements and architecture you're using. If you want to keep your data safe, I would definitely recommend using IBM MQ. We are satisfied with the service provided by IBM MQ. We don't have any issues. I would rate it at 10 out 10. It's the best.

The best advice I can give is that it provides stability and performance and there's no loss of data. That is most important for our customers. The data will never be lost. It is used by large enterprises.

I would definitely recommend IBM MQ to other people who are looking to implement this solution. They are going in the right direction. Everything is really in place and can be fully obtained. For me, the solution is a perfect product. I would rate this solution overall as a nine (out of 10).

Overall, MQ is good, capability-wise. You still need a messaging platform and MQ is quite a reliable messaging platform. I have not seen hiccups using MQ across multiple environments in the bank. I have been using it since 2006 and I have never experienced any issues with the product itself. The guidelines of the product, the way it is used, the way things are done, are pretty self-explanatory. There are multiple blogs/ online helps available and there is a lot of help available from experts around the world. Have a look at the features. If they complement the requirements you have, go ahead with it. If you are very technical and want to understand more about the open-source tools and features, that may require a notable learning curve. The product has been around for a long time. It's probably time to see what MQ is going to add to its features. We have not started using IBM Cloud Pak with Red Hat OpenShift yet. We are also looking at using containerization but probably it may take some time.

For the most part, this solution serves our purpose. It is not difficult to manage and the only challenges we have really had were to deal with some of the messages manually. My advice to anybody who is researching this solution is to consider costs first. It is expensive and you have to ask what value you are going to get from it. You need to consider factors like how many messages you are sending per day. If your budget is sufficient then IBM MQ is your choice, otherwise, you should look into a cheaper option. Also, if stability is the most important thing to you then IBM MQ is the choice that you want to make. I would rate this solution an eight out of ten.

We also considered Apache Kafka as a solution. The main difference is that Kafka is an open-source platform.

IBM MQ is one of the oldest, most underrated products in history.