IBM MQ Reviews

We use MQ for our transactional layer in conjunction with IBM Bus. We use MQ for our web application servers and many of our processes.

We like IBM MQ for our synchronous communications and transactional applications that require a lot of CPS.

We've been using IBM MQ for about 10 years, but we are currently in the process of migrating our IBM workload to the integration layer in AWS.

IBM MQ is highly stable.

The portion of IBM MQ that we have in the cloud is scalable, but the on-premise part isn't so much. However, we are working on sending our loads to cloud.

IBM support is good. I would rate it nine out of 10.

Positive

It's straightforward to set up IBM MQ because we can use it in lightweight modules, like containers, for example. It's not always easy for applications to connect to IBM MQ, but I think it's fine in general.

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

Mainly we are using MQ to pass the orders in the format of messages. We use MQ mainly for all the asynchronous messages that we pass.

It's easy to use and also quite compatible with all the language technologies where they can read messages and they can push messages to Java. It's easy to integrate and compatible with most coding languages.

The solution is stable.

I have found that the solution scales well. 

The integration capabilities could be even easier. 

I've been using the solution for a while now. It's been maybe ten or 15 years. 

The stability has been good. The performance is reliable. There are no bugs or glitches. It doesn't crash or freeze. 

The scalability is good. If a company needs to expand it, it can do so. It's easy.

We have a team of about five on the solution right now. 

We do not have plans to increase the number of users at this time. 

IBM technical support for any product is pretty much the same across the board. I have no complaints. They are okay. They are fast and knowledgeable. 

We have been using MQ for a long time. In the past we were using a custom-developed framework instead of MQ, however, that was ten to 15 years ago.

I can't speak to how the initial setup went. Those kinds of tasks are handled by the technology team. Therefore, I can't say if it was an easy or complex process.

I'm not sure, ultimately, how long the deployment process was.

I wasn't a part of the process. I can't say if we enlisted outside help or not. 

You do need to pay a licensing fee in order to use this product. We pay it on a yearly basis. 

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.

It's predominantly for message queuing, to assure delivery.

Our team manages messaging aspects with this product, among others.

I like the architecture it provides seamlessly for assured delivery.

The monitoring could be even better by building it into the product. The disaster recovery mechanism could also be built-in. 

I would like to see them not rely on third-party tools for everything.

Finally, they have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like.

I have been working with IBM MQ for almost seven years.

It is stable, for sure.

We are facing some issues with the scalability in some of the components. That can be improved.

We are satisfied with the technical support.

The initial setup is straightforward. It takes a few minutes.

We started with IBM but we have recently been looking at Kafka and Solace.

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.

It allows data transmission from multiple platforms in a fault-tolerant manner, that's the biggest feature. It is important for us because we do a lot of data transformation and data transmission between different systems; that's one of the biggest things that we do.

It's the backbone of all our data transformation and integration. Thus, this solution is our main integration platform.

Maybe, there should be a containerized version of the application, that can be deployed on the enterprises. So, there is need for a Docker container version of this product.

They need to do a better job of getting it into the open-source world, so that other people, who are more dependent on open-source technologies, start using it as well.

We've been using it for ten plus years now, so it's been good.

It has scaled to all our needs.

We have used technical support. I can't think of any issues with technical support. We've received the support that we needed, on time.

We've been using it for a long time. We were not using any other solution before.

We probably looked at IBM and Red Hat solutions. The reason as to why we chose IBM is because they are more mature in that area.

Longevity, deep support and technical depth are my most important criteria in selecting a vendor.

You should take a look into this solution.

The benefit would be scale. Because of the way it works, you can really have many, many users who use the solution at the same time. Other benefits would be the ability to send messages between systems and do systems integration, without interrupting their run-time behavior.

It's ability to scale, it's ability to do guaranteed delivery and it's ability to do point-to-point of what we subscribe are the most valuable features. And finally, it's ability to handle messages in various formats and structures.

I would like the ability to connect with some of the more recent offerings, such as API Connect; being able to publish our MQ endpoints, the queues, the messaging infrastructure as IT assets. To control them, govern them and manage them and being able to publish non-functional requirements around it. For example, we support this size of the payload, we support this much throughput. Making it known and available to the rest of the organization, because this technology is so technical in nature, business management doesn't understand it. I would really like a business-friendlier or end-user friendly information layer, and some kind of simple ability to communicate what we have with the users.
I want an information layer that I can publish and tell the whole rest of the organization this is what you get.

Stability-wise, it has worked for us. It is an old technology and it has always worked well for us.

You can really have many, many users who use the solution at the same time.

We haven't had to use support much, because we have really good people. So, it has worked for us the way we wanted.

We did not have a previous solution. We always knew we needed something that worked asynchronously, something that did the messaging in the background. The reason we knew we needed MQ is, it's one of the integration backgrounds we supported and this was an obvious choice.

When selecting a vendor, the knowledge and the experience that the vendor has is most important. For example, IBM has had MQ for forever. So, that's definitely helpful. It's finding resources that know the product and technology and obviously the ability to support the platform. And, when necessary, be able to guide the customer through various usages and integrations with the rest of the IT infrastructure.

In the latest installation that we are talking about right now, I was not involved. But, for other installations in the past, I was involved in the set up and it was pretty straightforward. I'd consider MQ one of the simplest products to use.

We didn't look at many alternatives. We considered the Microsoft platform for a little bit, but we almost always knew we wanted to do this with MQ.

If they're thinking about a solution similar to this, I would say, look at your requirements and not just the business requirements. People often stop at that point. Look at your ability to support and run the platform, and the cost of running the platform, because, depending on your need, it could be very expensive to run a large messaging infrastructure. Also, think about what non-functional requirements you want to support now, but what you might have to support three, five, or ten years down the road. Think about it from the bigger picture perspective. And don't implement the solution for one small single requirement. People often make that mistake. They commit to a big licensing and support cost but what they're running is very small and there is not very much value added. That’s a problem there. So look at whether can you put a lot of solutions on it. Can you use it as a platform rather than a points solution is what I would look for.

The messaging and the security are the most valuable features. We can find everything in queue, because that's the basis of our business.

It is hard to say how it has improved the way my organization functions because it's been here since the beginning. I'm not sure I have an answer.

Right now, I can't think of anything that needs improving.

Stability is great. We have not had any issues recently. Version 7 was a tough one, but since then, they've improved it.

Scalability is great. We use it on Unix, Linux, z/OS, Windows, everything.

We use technical support, the PMR, all the time and it's great. It's usually really quick.

It was too long ago; it wasn't my decision to switch.

I was involved with the initial setup. It wasn't quite straightforward because the original versions used CICS and that was a little tricky sometimes. But, then they went and made the agent as part of the package of using the CICS.

Go for MQ. It will solve your problems for interconnectivity and just whatever you need to do; scalability wherever you need to go.

We use the WebSphere and also use the IBM Maximo Enterprise Management System. The most usable functionality for us is just for tracking work orders and work requests, so that we can provide better customer service.

It has improved the way my organization functions by just being less paper, and more efficient with timing; again, going back to the customer service, with clients being able to close their work orders within a shorter time frame.

I'd like to see a more graphical user interface type of configuration for the application.

Normally, the system is very stable but we've actually just got a call, "Part of it's down!" So, at the moment, we have got a bit of downtime.

The scalability is enormous, which creates issues as well as has benefits. The scalability adds complexity to it. It is scalable, but with some caveats.

We honestly don't utilize IBM for tech support. We have an independent partner that we use for all of our IT support for this product.

It works well, but I think that the overall scale of what you can do with this product adds, again, to the level of complexity, as to what you need in-house for support.

Definitely, you should go out and really try and define your requirements before you actually go out to look at other products. You should know exactly how you're going to use it, and what you hope to get out of this product. Thus, you will have better information to actually go out and compare different products.

It's rock solid. It just works. We have to have guaranteed delivery and support. Support is solid as well, knowing that IBM is there. We looked at some open-source products and other competitors, and at the time that we made the decision, IBM was the one that had the largest support structure. Rock-solid performance really is the most solid feature of it.

We had to integrate different systems and MQ allowed us to send messages between systems and guarantee delivery. What that did is allow us to more easily integrate those systems and feel 100% trust in this solution.

From an MQ perspective, if they had some built-in monitoring, built-in dashboards, maybe some web-enabled functions so we don't have to load specific tools on our workstations. The training and scalability clustering could be a little bit easier. They could also make it failover- and fault-tolerant. The training aspect is a big part. I think IBM maybe has some work to do on the training side a little bit.

Stability is great. Stability is rock solid. We have very few issues with it.

Scalability: We're a smaller shop so we don't have the resources necessarily to take care of it. Scaling out MQ is possible, but it's not as easy as some other products. It's not as easy as other technologies even.

We were not previously using a different solution. The business challenged the pattern we used. Using queuing and messaging presented itself as the best solution.

When choosing a vendor, we want support, access to information, solid products, and, hopefully, building blocks where we can build on and use other products and foundation.

Setup was more complex than what I thought it might be. We have an active-active cluster, meaning that the systems will fail over to each other if they need to. It was more complicated to set up. We had difficulties setting that up initially, even with consultant help.

I would go back to the rock solid performance. If you can get through the setup and the learning curve with the product, it will just run and work for you. That would be the advice I would give.