IBM MQ Reviews

Basically 100% message delivery and how easy it is to integrate the system to another system / .NET / Java applications are the most valuable features. It provides 100% guaranteed message delivery, so you won't lose any messages, even in the event of a MQ failure.

The benefit is that we are in an industry where we cannot lose any piece of data, so MQ gives that reliability. In terms of security, like I mentioned preciously, you won't loose any of the transactions at all, even if you have a failure. It's very important to us, especially the FIFO feature (first-in, first-out) and that kind of persistent messaging. We have a billing system where whatever messages drop first need to be consumed first. Thus, these features are really good. It helps us flowing all the MQ messages.

One of the bottlenecks for us is owing to the industry that we're in, we sometimes get the large payloads and the MQ queues that we can increase. But, the maximum payload size allowed is only 100 Mbps. So, I wish to see if it bumps up because sometimes we hit that ceiling and the message won't process. We have to find another way to mitigate one or two instances like that. It's critical, so I don't know if there are any future plans to increase that size to unlimited or at least where you can set it based on your business model, i.e., if your payload is higher, then you can set it higher.

It's pretty stable. We did not experience any downtime. Probably, there's no other product out there like MQ for messaging. It's the most reliable solution. We had our MQ running in production for almost 800-900 days without any issues, i.e., for more than three years, we didn't even have to restart, and still everything runs so smoothly.

It's fully scalable. You can add as many queue managers or queues in there, so it's pretty flexible in terms of scalability.

I have used the technical support around one or two times, but not that much. I did have some meetings scheduled with the architecture guys at a recent IBM conference. I am quite happy with the support that I have received.

We were not using any other solution previously. From the beginning, we implemented it. We always look up to IBM software. We have so many IBM shops with products such as the IBM AIX Servers, WebSphere Servers, WebSphere Liberty, IBM Integration Bus, IBM InfoSphere MDM Reference Data Management, IBM PA and IDMP. We have lots and lots of IBM products, including the WebSphere Portal and WebSphere Commerce, so we got a lot of things from IBM.

It's a good solution and you should go for it!

When selecting a vendor, mainly the support part is very important, especially when something goes wrong in production; you don't want to leave the system down. This could cost the customer a lot of money, so having that level of support is important. Sometimes, we run into an issue where the support is not able to help, then we always reach out to our self-service representatives. After which, the ticket gets escalated and addressed pretty quickly, so that's the kind of attention required.

It's certainly a product that you can rely on. It delivers the stability and security within our applications that we desire as an organization.

The time to deployment is quick and easy. Again, it is stable, auditable, and uses automation to deploy products and keep the systems up and running while the business is still functioning.

I think the cloud is our next solution. Because we’re in the healthcare industry, I want to make sure the security is really strong and capable of keeping our members' data secure.

It's very scalable. It's very easy to build out with high availability, and you're also able to scale both vertically and horizontally very easily.

I was not involved in the initial setup.

We used all the big players and we chose IBM just because of the fact that we've used them before with other solutions. We know their capabilities. Their delivery solution team has helped guide our solutions across the board and has delivered high availability, high quality to our members.

We also used Oracle, and we also used the Tomcats and JBoss product lines.
The most important criteria when selecting a vendor is reliability; knowing that they're going to be there to support you when you need them; the ability to bring solutions to an issue in a quick manner that allows you to keep your business going.

Every application could always use improvements, but it's a very stable application and delivery solution tool that we are able to implement quickly and add applications to it quickly; keep us going in an ever-changing environment.

Guaranteed delivery of the messages and then the ability to scale the messages the way we need it according to our application, performance, and scalability.

It helps us to make sure that every time you do a swipe on your credit card, the credit card transaction is guaranteed to transact.

Some of the new features that their competitors are coming out with. Things like AMQ are coming out with - transformation of messages with the security aspect of it and even scalability with AMQ, it's scaled at the microservices level and MQ is not quite there yet.

We're currently evaluating AMQ to see if from a cost perspective it makes sense or not to switch from IBM MQ. We still have IBM MQ.

Very stable. Within the last year or so we hardly had any issues with the MQ or the queue itself going down.

Scalability good, we can scale by the application needs and also scale by the need of the application but also the need of the infrastructure. At our peak, we're able to scale and make sure the transaction goes through.

Service is good. We've been able to meet all our SLAs in the agreement that we signed with them.

We have an enterprise level agreement with IBM. If there's any issue with MQ, we have a direct line to them.

AMQ is one of them, Kafka is the other, and of course IBM MQ has always been on the list.

We chose IBM a long time ago from all the criteria I mentioned and then at the time other players were not evolving yet. IBM MQ has been an enterprise solution for many companies and the stability's there. It made a lot of sense for us to use IBM MQ back then.

Partnership with the vendor and stability of the product are most important when selecting a vendor. I mentioned AMQ earlier, and there's no guarantee that AMQ will be around next year.

Stability is key to the product and the performance of it, you can get high availability, high performance too, but we talk about tens of thousands TPS through the product so, from that perspective there's no other competitor on it.

The most valuable features of this solution are its reliability, efficiency, and the capacity to bring value.

The benefits are the satisfaction of my users (my clients), the stability of the solution, and the availability it provides.

It would be nice for the next release to have better reporting. For example, elasticsearch or ELK. We don't have that with IBM. So we have implemented our own solution.

We have a major application based on DataPowers and WebSphere servers.

We had an main issue to visualize efficiently the utilization of our WebSphere applications (load, who is using, when, how). It’s critical in defining our “capacity planning”.

Actually, we’ve developed our own reporting solution based on Kibana/Elasticsearch. Kibana analyses ours logs in real time. We have done a portal with several graphs. It is really impressive. We are very happy with our solution.

IBM doesn’t provide, by default, a reporting item as efficient as Kibana. DMGR is not as powerful and flexible.

The stability is quite good. It's strong and the performance is important.

Scalability is a bit difficult for us. Since this product is an IBM product, we have to work together with IBM to be more efficient at this point.

We are not really happy with their support. They don't have the skills to very efficiently answer our questions, so our relationship with them is difficult.

I was not involved in the initial setup.

When it's too difficult to have what we want with IBM, we develop our own, better solution and we try to integrate our own solution with IBM.

When selecting a vendor, we look for the confidence, the relationship. We have to share the same objectives and to agree in order to deliver the same value to the client.

I think the most valuable feature is the scale that it can run at. It runs millions of transactions in our environment on a daily basis, scales and works well.

I don't know if it improved my organization but it basically drives communications between a lot of our subsystems and processes. It's kind of the backbone of a lot of our services.

I think some of the management tools could be improved. We've got a variety of different management tools, that we have in place. Having them be more a core part of a product, rather than being add-ons from either other solutions or open source, would be good.

Stability is very good.

Technical support is good. For the most part, we get what we need. We did have AVP for a number of years, which was another level of support. We're reconsidering that maybe we should be going back to that level just for the more timeliness and quality of support.

There are a lot of open-source alternatives coming out now, today. Sometimes MQ can be perceived in the organization as being expensive. Price is an issue.

Where we've deployed other open-source solutions, we're not at the same scale so it's difficult to say at this point whether they do as good of a job as MQ. Obviously, we're very conservative in taking some of our core systems and moving them to unproven technologies.

There aren’t any features that they have that I wish MQ had as well. They actually tend to be a little lighter weight than MQ, in a bad way.

Make sure that whatever solution you have is going to scale to meet your needs and that you have the tooling infrastructure available to you, as well.

The most important criteria for me when selecting a vendor to work with is, obviously, quality. Reliability of the product is number one but it needs to be cost effective, as well.

We haven't really moved into the cloud with MQ at this point.

The most valuable features are content security and content delivery, from a whole network protocol perspective.

It's adapting itself to get into every single component throughout the entire world being Java enabled.

We are able to transport data across any platform in a secure fashion, be it internal or external.

From the send and forget perspective, MQ allows you to – on your own – manage your data, collect your data, and manage your data perspective.

The barrier to success is basically the engine behind the collection of the data.

I also think the administration could be a little more straightforward. Right now, we have to develop our own truly distributed administration system. There's a GUI that's really not manageable; not that easy to use.

It's very stable.

It’s very scalable.

Technical support is responsive; it comes out of Hursley, which is their main support and development location. There is a direct line to their development; it's very good.

We were previously using all kinds of solutions, including SCP, SFTP, FTP and proprietary APIs. MQ allowed standardization to port data.

We decided to use WebSphere MQ because we needed data transport from all kinds of systems.

Responsiveness is the most important criteria for me when selecting or working with a vendor.

Initial setup was straightforward and flexible.

We did not really consider any options other than MQ.

My advice is to lay out your infrastructure in a fashion you can support.

MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.

The system integration is good. 

The pricing needs improvement. 

I have been using IBM MQ for six years. 

The scalability is a nine out of ten. 

The initial setup is complex. 

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

In our company, it's the main hub for our whole CRM solution. MQ manages things through the Broker.

I like the whole idea. But the first things are its simplicity and its robustness. Compared to any other product, it's the most robust I've worked with. And it's extremely easy to manage.

The worst part is the monitoring or admin, especially in the ACE or Broker. There is always a problem of transparency. In MQ you can observe any process and you know exactly what's going on behind the scenes, but with the ACE or Broker, it's a problem monitoring the HTTP inputs. It's like a black box.

The reason that I'm emphasizing monitoring is that I used to work for the company that produced the administration and monitoring tools for IBM. There was a lot of competition and a lot of confusion in the market. When I moved to this company I actually used my previous experience and wrote my own tools. I am not much of a C# programmer, so I was struggling a bit. I know the concepts, but I was missing some straightforward support from IBM. They were selling it as a part of Tivoli, but you needed to implement the whole Tivoli infrastructure. If you had some other monitoring provider it was a bit of a pain. That is my concern here.

I've been certified as an MQ specialist since 1997 so I have about 23 years' experience in this field. I've been using it since version 2.0. Currently, I'm in production support and supporting version 9, mainly.

It's stable. I'm working for a FT 500 company, a global company employing about 60,000 people, and we've been using this product ever since I joined the company in 2003. We haven't had a single major performance issue or crash.

It's scalable. We have gradually increased our usage over time.

I am satisfied with the support from IBM. To be honest, I used to be an IBM trainer for this product, so I know people there. The only issue I have is that if the product goes out of service, it's difficult to get PMR (Problem Management Report) for it. In production, a lot of businesses tend to stick with the older versions.

I've been doing it for over 20 years, so it's straightforward to me. Beginners might struggle with the initial settings, like user rights and the basic stuff, but setting up MQ is fine.

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.