IBM MQ Reviews

Its scalability and uptime is very high. So, these are the two main valuable features of this product. We rarely see any downtime on MQ's side of the product.

It helps us, i.e., even if some of the other apps are down, we don't lose any of the customer data, so it's very beneficial from that perspective.

We would like to see more clustering, high availability, and also monitoring features. Monitoring is a big part. We would like to see if we get back out queues or the queue depth goes high, so that we can be alerted on that.

It still needs some improvement, in terms of high availability and the clustering needs to be improved. Monitoring is a big piece which is missing.

We have been using this solution for the past ten years.

For the stability of this product, I would give it a 9/10 rating. Only sometimes when some queue manager dies, then at that point, we lose a couple of messages but not a whole lot.

I would give the technical support a 7/10 rating because we do get the response back, but a lot of time gets wasted in carrying out processes such as getting and sending logs, instead of coming online and sharing the screen and troubleshooting the issue.

We work with Proficient Solutions, Inc. and Prolifics. There are others as well, but these are the two major ones.

The number one criteria while selecting a vendor is availability. The other factors that we look for are proximity, their technical knowledge, market reputation and of course the pricing policy.

It's a good product. Compared to the other products on the market, it's a very good product. Based on your company needs, you should give it a try and it should work.

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.

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 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.

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.

It's one of our core parts of a middleware platform for integrating our CRM billing application and our online transaction application as well. That's the key usage for day-to-day activities.

Integration is a key benefit; it integrates easily. Management is easy. Queue management is one of the key features of it; how easy it is to get set up, get started, get running, look at your queues, look at your workloads, etc., and see what's going on.

We’re not using MQ to better connect across cloud, mobile and devices, or part of the internet of things. It's something that we're looking at for IoNT. We're looking at doing mobile parking, our parking meters. It's something that we're looking at, but we're just doing the road mapping. We haven't deployed that yet.

Currently, it's our connection between our web front end and our back end billing, but that's the next step.

Everything that we need so far works, so I think I'd have to look at the road map, what we planned for internet of things and see if it meets that, which it should. At that point, we'll have a better understanding of what we need going forward.

My support guys, because they use it on a day-to-day basis, might want to see improvements from a management perspective, the management interface. That's one of the complaints I've heard: modernize to a more mobile platform. It's not modern enough for what they wanted to do with it, from what I've heard. That's one area I would say improvement could be done, but again, that might be a small component. Beyond that, nothing.

The main reasons why I haven’t rated it higher is the management interface, which has been a topic of discussion among some of the users, and some issues we’ve had with MQ for z/OS; that's probably because we were on an older version. I haven't looked at the newer version. Those are the two main reasons.

As far as the price point, I don't deal with that; that's somebody else's problem. From a deployment perspective, I didn't have an issue. It's a set up and go for me, from an architect's perspective. These are the requirements, these are the design, you go.

Stability is pretty good. We haven't had issues from a stability perspective. It seemed to always be running. Everyone seems to say, "Hey, it's an MQ issue." Once you look at it, though, the bottleneck is always somewhere else.

Scalability is great as well. You can create your queue managers or you can add a node if you need to and just grow your platform.

I personally haven't used technical support, so I can’t comment on that. Once it's deployed, the support team manages everything into it.

I was not involved in the decision to invest in MQ.

I was in the initial setup; I was involved in the design of the environment for MQ and the rollout of that platform.

It was midway between straightforward and being complex. Our environment is quite complex. We have to integrate the different systems; we have MQ on z/OS, we have MQ distributed. It's right across the platform. The setup of MQ was not complex, but the integration with our environment had some complexity. Overall, with the MQ platform, I don’t think we could have done it any easier.

It's a great tool. It's a great integration middleware tool. Once you have your requirements set, MQ should meet it, but review: Make sure that you understand what you need, what you're setting up, and how you're going to deploy it.

The most important criteria for me when selecting a vendor to work with is how easy it is to get the information from that vendor. Usually, when we get a project, it needs to be deployed yesterday; very tight timelines. If a vendor can come to the forefront, come with all the information, show that their product will meet our needs and it's above any other product on the market, or even on par, but you get a little bit of extra service or support, that's what we look for.