IBM MQ Reviews

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.

Stability and reliability are the most valuable features. It's very reliable and very stable. You can do a fast recovery in case of any failure. It's a very consistent and stable system.

The whole integration channel between PowerVM and third-party applications goes through MQ. This is why MQ plays the role of middleware, of integration, and it helps us to quickly integrate all applications around PowerVM.

One possible area with room for improvement is some integration with the alert system to alert us in case of any failure of any message to be transmitted from one source to another; maybe that could help. It doesn't do that right now.

We will see how MQ will help us when we go to cloud, one day.

It’s very stable.

We have never faced any problem with upgrading or scalability between MQ series and the IBM the PowerVM. It's good.

Once you install MQ, you don't need a lot of support. Of course, we have support with an IBM partner in our country, but up until now, we have never faced a major issue that could impact our business.

Implementation was very straightforward.

Our environment is 60% IBM. We did not shop to search for another solution.

In general, though, the most important criteria for me when selecting a vendor to work with are support, response time, credibility, to be near to us, and that they are not working from the cloud.

In a financial institution, for very critical applications, when you invest, you have to invest one time. You don't have time to redo the work over and over. When you build your setup, your infrastructure, to do your service and your financial service for mission-critical applications, you have to choose the best-of-breed application that supports you. This is why we choose IBM without any hesitation.

We have never faced any problem. It works fine.

We are a bank, and regulations restrict us from using the cloud, at this point. We're using MQ only on our data center.

Obviously, the biggest thing is that we’ll never lose a message. We use it for a lot of real-time information between our systems for integration, where we cannot lose data during that point in time, because then we lose track of inventory, our manufacturing systems, sales orders and things like that.

It's reliable. It's a solid foundation. It’s always up and running. MQ doesn't crash on us. It gives us the stability of the platform to be able to do all of the integration between our applications.

The user interface might be an area with room for improvement, but we use MQ Explorer and that helps solve a lot of our problems there.

On my test systems, I have over 150 queues; maybe a better way to manage those and to see them visually instead of just one long list.

We started using MQ back in 1996.

It’s up 24/7.

We haven't had any scalability issues. We keep adding more applications to it all the time.

We use technical support only when there are problems, which is very rare. It's always been good when I've had to call them; responsive, efficient.

I was partially involved in the decision process to invest in MQ. We were not previously using something else. We were actually early adopters, really and truly. We started using MQ back in 1996. We've been using it ever since then.

Initial setup was straightforward.

At that time, there were no other vendors on our shortlist.

The most important criteria for you when selecting a vendor to work with is obviously that it is a stable company; a vendor that will be around for a while. Those kinds of things.

Take a look at it. It's well worth the effort to play with it and to understand it.