IBM MQ Reviews

Reliability is the most valuable feature. MQ is used to support critical business applications.

The installation of product upgrades and patches is very difficult. It requires the use of the IBM Installation Manager (IM). The original IM data location used for installing the base must also be used for the installation of product upgrades and patches. In the Network Deployment edition, upgrades and patches need to be installed in the deployment manager and node agent profiles. I would improve this area by eliminating the need for the IBM Installation Manager.

We have not had stability issues.

We have not had scalability issues.

Technical support is excellent.

We had no previous solution.

Setup was complex. It requires a lot of components to be configured.

Use the new and lightweight version (Liberty) to lower licensing costs.

We didn’t look at other solutions.

Use the new and lightweight version (Liberty) to lower licensing costs. It is also easier to upgrade/maintain.

It doesn't lose transactions, it's fast, and it runs on every platform.

The benefits are the same as the most valuable features. Close coupling between different domains, which reduces your total cost of ownership by not inter-tweaking everything.

For me, there are no areas with room for improvement. We are happy like it is. I don't think we have any special additional needs. I think it does what it's supposed to do and it caters to the requirements we have at this moment.

We would actually like some dashboard improvements, because we've set up some manual dashboarding. We use other tools to monitor MQ. But, if that would be a part of MQ, then we're looking at a TCO reduction again. So it would be interesting if we could get rid of these additional tools.

For me, the management is lacking. It's doable, but it's not graphical. Almost everything you need to do in command line mode. It's pretty technical.

There is no downtime. It is very stable.

We have no problems with scalability. It scales all the way around.

We have used technical support. For MQ, it's very good, compared to other products.

We didn’t have a previous solution. There was a new requirement to handle asynchronous transactions, and MQ seemed to be the best solution at that moment.

I was involved in the setup of the distributive systems. It was straightforward.

We did't look at other vendors, because, at that moment, IBM was our preferred partner, and still is, so we first looked at the IBM solution.

Just do it.

It allows us to do point-to-point integration in an easy manner. It allows different applications to talk to each other; applications that may speak different languages. You have mainframe technologies, Java-based apps, .NET, things of that nature, and MQ allows you the ability to share the data between those different types of systems.

The thing that I like about MQ most is its reliability. It's one of those types of products that just works. You don't have to tinker around with it too much. One of the biggest things that I really look for in a product is from a reliability perspective. Can I count on this to be up 24 hours a day, and do I have to keep hacking around with it? MQ is definitely something that is really reliable, so it's something that I really appreciate it.

I would just like a more user-friendly experience to do common administration tasks. I know that you can use MQ Explorer, but having something that's already built in would definitely be useful.

We haven't necessarily experienced any issues from a migration perspective. Typically, where we see the majority of our issues at is when we're doing upgrades to the Message Broker, or IBM Integration Bus is what it's called now. Those two products are typically married together. Most of our issues ... I wouldn't even call them issues. We see some issues when we migrate from different versions in regards to like, IIB. I think that's just because this is a more complex product. You have customized code in there. From an MQ perspective, everything's pretty straightforward.

I haven't had any stability issues. I think the biggest thing, when there are issues, is having an easy way to figure out what's going on. I think one of the things that I'm looking forward to, from a MQ perspective, is just having more of a user-friendly experience. MQ has traditionally been somewhat of a command-style solution, so anything that they could do to improve that would definitely be helpful.

We have not had any scalability issues.

We have teams that usually interact with IBM. My team doesn't necessarily do that that often but when we do, it's a fairly pleasant experience.

From an MQ perspective, it's something that we've been using for a long time. Unfortunately, when you're dealing with very large companies, it's difficult to transition away from stuff that you built a long time ago, so you have a lot of this stuff that's just hanging around, that's been built a long time ago, and you still have to maintain it. Once something goes into production, it's typically very difficult to get money to update that service five, ten years down the road.

Setup was pretty straightforward. MQ has been around for a long time. It's a reliable product. It doesn't change that much, so I think everybody, at least in my organization, is fairly comfortable with installing and implementing MQ.

MQ was, to me, pretty much the gold standard in regards to what it does. To me there's really no point to look at other vendors.

Have a common understanding of why you feel that you need MQ. MQ was something that we implemented years ago, so there may be new technologies out there that you may be able to utilize to make the project you're trying to do easier, and make your implementation a little easier.

The subscribe and publish features are excellent. We use them a lot.

The usability of the solution is very good.

There isn't that much happening with the installation consoles and monitoring consoles. This could be improved.

We need to have a better administration console and better monitoring features. Right now, they are not good and could be a lot better.

The pricing could be better.

I've been using the solution for ten years. It's been a decade so far, therefore, it's been a rather long time overall.

The technical support has been pretty good. Every time I've used it, they were pretty good and I found them to be knowledgeable and responsive. I'm quite happy with their level of service.

The pricing could be lower. It's not the cheapest option out there. However, I don't have comparison prices with other solutions at this time. We're working on comparison pricing currently.

We are currently evaluating other options. We are starting the comparison now and we are starting on the technical scope, not on the budget. However, we will also consider pricing as we evaluate other potential options for our company.

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.

The number one thing is it's pretty reliable with data integration. It gets done what we need to do; transport messages from source to destination.

It is the core component of what we do. We're using it to distribute messages from one platform to different multiple platforms.

We're moving to the next version. I really don't have anything I want improved. There are unknown bugs that we run across where we don't know where they are from, and the next fix pack will fix it.

Stability is pretty good, really. We have not had any downtime.

Scalability is good.

My colleagues have used technical support. I would say it's good.

I wasn't part of the decision to switch.

I was not involved in the initial setup.

Use it.

For Rogers, MQ is the cornerstone for the billing system for cable. It's accessed through the help desk and through the online stores. It's a very valuable piece of software that interfaces with the customers; there are well over 8 million customers.

Using MQ, because of the speed of getting the transactions, adds the value back to the customers. When you are dealing with a customer in the store, you don't want to be sitting and waiting for transactions to come back on the customer information, the CIF file. Having MQ with the instant response adds value back to the customer's experience.

Price is one thing that could be improved.

Probably because I don't know how it interfaces with the cloud, I would like to see more of that functionality; get more of the cloud experience and more of the mobile experience back into MQ from the customers. That's something I don't have right now.

I think MQ could go farther in terms of the customer experience.

Stability is awesome. MQ is up all the time. We never have an MQ issue. The interfaces that feed into MQ are quite stable and the APIs associated with it are quite proficient. MQ is a very efficient piece of software from a CPU utilization perspective, which I'm interested in. It's very productive and it's quite tuned in terms of performance.

It's quite easy to scale out and to build other regions using MQ. We've developed a peak performance testing area with MQ and we're planning on putting it in the sandbox area to gain more experience before we roll out versions of it. It's quite easy and adaptable to implement into other regions.

I have not used technical support.

It's a very stable product. It's been out in the industry for years. Many industries use it, so it fits into any commodity that you have. It's a very solid product. Give it a try, look at it and understand what it's used for.

The most important criteria for me when selecting a vendor to work with are reputation, post-support, reliability, and improvements on the product.

They’re not really using MQ to connect across cloud, mobile, or devices as part of the internet of things.

• Guaranteed message delivery
• Easy to use
• Works for both distributed and host applications

It allows us to do real-time claims processing through a non-host platform into the host platform.

A better user interface; right now, it's technician dependent, so it's a tech support role. It would be nice if we could provide better interfaces to see the queues, the channels and how they're used, and the queue depths.

We've been using it for 25-30 years.

It is solid. We have no stability problems with MQ.

It's solid, and it scales.

I personally have not used technical support. As a corporation, we have, and it is solid.

If you have the right technologist, it's a good tool.

It works. It scales. It does what we need it to do. It's stable. It's a technology that, again, is platform agnostic.

The most important criteria for me when selecting a vendor to work with is: Is it a partner or is it someone that's just looking to get paid?

We are not using MQ to connect across cloud, mobile, and devices as part of the internet of things, so much. It's more for internal.

The barrier to success is that I haven't had a business need to use MQ. We use DataPower instead.

The most valuable features are messaging between applications; sending messages. We use it a lot to communicate with the IBM SIS service.

Actually, we didn't have a choice. If we wanted to speak with IBM SIS, it was the way to do it, so we had no choice there. We had to do it.

There are some part of the business side that couldn't be done without it. It's an integral part.

It would be nice to actually have something like a dashboard. I've been to a presentation about the PowerHA. They now have something like a dashboard, where you can see the health of your nodes and stuff. It would be great to have a dashboard like this. I think there is MQ Explorer, which does that, but I haven’t found it. I would like to use it more to work with the queues, and less to see the health of the environment.

It’s reliable and it's quite all right to work with, but I would like the tools to be easier to work with on a day-to-day basis. For instance, the logs and stuff. For now, we just use the command line when we go in the log directory for each queue manager. It's not very, very easy to operate.

Stability is good. It's okay.

Scalability is okay but it can get a little complicated. The application should really be aware of the way it works. We had quite a few issues where the app wasn’t able to talk to many queues. We didn't know that much about MQ; the dev team didn't know a lot about MQ, we did not know a lot about how to code for MQ. It was kind of difficult conversation there.

I strongly suggest taking good training first, so you will really know the product and know how to implement it. Then, everything should be fine.

Stability and support are the most important criteria for me when selecting a vendor to work with.