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.

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 integration between applications is the most valuable feature. We can use it with multiple applications.

It provides faster interaction between the applications. It makes it easier to integrate the applications.

So we're on MQ version 8, and I was at a recent event for MQ 9 and it looks like they've already added some of the features I was looking. For example, a better monitoring system, and a GUI to display messages, which I think they've already done.

MQ is very stable. It's a very simple application to set up, and once it is set you don't have to really configure or monitor it so much.

Since it is very lightweight, the only thing you have to really scale is hardware. So, migrating is very simple as well. It supports HA, so we have it set up with just an active/passive type set up. And we don't have to scale it as much. So far, its been working out great.

We haven't had to use support yet.

Our first time using a message queue system was MQ, so we went with the IBM MQ product.

Being with a state agency, we actually go through what's called a hub that has a relationship with IBM. We can't directly purchase from IBM, so we have to go send bids. But, since we have quite a few IBM applications, we always you know target IBM since we already have the support that we need and our relationship with our sales person is really great. So, we always choose IBM.

I was involved in the initial setup. It was fairly straightforward. Once you start creating the queue managers, there's some configuration involved, which our developers take care of. I just take care of the basic installation of the product, which is very simple.

I don't know the names of any alternative vendors.

MQ is awesome.

So far, it's helped us with our Maximo integration between the users and the database administrators. I know we kind of lagged behind on some updates, which caused us problems. We recently upgraded, which had made things a lot easier, got rid of some of the issues we had with the older versions.

It helped us with some of our security, on some of our roles, if I remember correctly. It helped us integrating; we’re trying to move a bunch of different things, like trying to move EZMaxMobile into our Maximo and a few other things. Part of that was bringing up WebSphere to the newest version for all the integration.

Off the top of my head, I can't really think of any features I’d like to see in future versions. Right now, I don’t have any improvements to the version we’re using. We just upgraded two or three months ago, and we're still getting it all set up.

The configurations were not difficult, but like I’ve mentioned, again, I believe when they went through the integration, they talked to IBM to make sure that we're going to go through OK. So, there was some interface back and forth during the upgrade.
We’re happy with the user interface, so far.

Getting more analytics coming out of MQ is something we're working with across the board with everything, with our Maximo data, with all the applications we have. We get tired of having to pull reports and somebody has to manually crunch the numbers. We need something behind the scenes tabulating everything and coming up with answers, so we don't spend all our time just collecting everything. If there would be an integrated tool that would give us reports, that would be amazing.

With the newest version, we haven't really had any stability or scalability issues. I guess that's a good thing.

With the previous versions, it was just that we were a version behind on what the version of Maximo and everything we were using, so it was causing a few little glitches and buggy issues.

We frequently use technical support. They have been pretty good, so far.

We knew we needed to invest in a new solution mainly because of the issues we were having with the old version; it was pointed out that they were going to be fixed by the new version, so that was kind of a simple thing.

I was not involved in the initial setup with this current version.

We were already using WebSphere MQ, so we didn’t look any other solutions.

Don't be afraid to call. If you're worried about tackling it all on your own, don't be afraid to call IBM or call somebody that's already gone through the process and get some help, because we're all willing to help; you just have to ask.

I have not given it a perfect rating because there's always room for improvement. I can't give them the improvements; they have to figure that out. It works really well but like I’ve mentioned, with the way everything's changing and developing every day, you always have to be on the lookout for what's coming up next.

In general, when I am looking at vendors, the number one criteria is responsiveness. Number two is time frames and that they meet the schedules. Those are our two biggest things. We've had issues with other vendors in the past with those same things.

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.

Ease of use and ease of setup. I'm an admin type, and I can set things up from the command line, and I can set things up through a GUI. It's easy to work with.

We really haven't had any problems with it. I don't have too many positive things to say because usually, I'm in it when things break, and that's when I form my opinions. And I haven't really had to form too many opinions on MQ because it's been really stable.

Can't think of anything right now. There's one little part, but I cannot remember it's name.

Good stability.

Good scalability.

We've had good luck with the MQ people at IBM, in helping us resolve problems.

It helps to plan, and it helps to understand the product. Sometimes management doesn't understand the project, they just go, "Oh hey, it sounds nice. Let's use it." Then they try to slap it on things they don't understand.

When choosing a vendor, stability and reliability are most important to me.

The most valuable feature of IBM MQ is that it is robust. Its dependability and reliability are its most valuable features.

It has allowed us to take applications that would not normally be able to communicate, to be able to talk to each other.

I would like to see more integration into the security back end.

It's very stable.

It’s very scalable.

Technical support is OK. Quicker escalation would make it better.

This was the first solution of this type and it was the one that was the best fit.

It's very stable and it's pretty straightforward. It just needs some more integration features to make better.

The most important criteria for me when selecting a solution is that it meets the needs.

For MQ, the most valuable feature is our ability to connect our distributed systems back to the mainframe, and pull our legacy data out of the mainframe and bring it down into a modern Java front end.

It's easy to install and it's bulletproof. We never have an issue with it. The upgrades are easy and IBM support is fantastic.

Honestly, the features they just recently released are what I wanted to see. Like I mentioned elsewhere, the appliance device was fantastic. It's MQ in a box, and you just plug it right into the network. I'd like to see improvements around that area, so we can take our z/OS systems into our distributed environments even easier.

We are very happy with the stability.

We are very happy with the scalability. It's easy to scale, easy to cluster, it's highly available, and we love the fact that IBM is now making appliance devices out of MQ, so you can buy them and just rack them right into your data center.

We are very happy with IBM support. Also, their professional services; if you need consulting, they're fantastic.

We used this product to solve our initial development solution about 15 years ago. We were coming on with Java, and we needed to connect our distributed front-end Java to our back-end legacy business intelligence code that's all written in COBOL on the mainframe. MQ was just the perfect way to connect.

I was involved in the setup. It's straightforward, but I had done this before.

We looked at a couple others, such as RabbitMQ and Sonic. They just didn't have IBM’s weight behind them. I love it.

When looking for a vendor, I look at their reputation, reliability, and a recommendation from the industry like a Gartner report. The Magic Quadrant is huge for us. We look at quadrant leaders all the time when we're taking solutions.

Don't hesitate. Call IBM and get them in there tomorrow.

The major thing we like about it is zero transaction loss. The other thing, which is a plus point, is first in, first out (FIFO). You can be pretty sure that if MQ goes down for whatever reason, the transactions will still sustain; they won't be lost. There is a drawback when, once a transaction touches the other point, it is lost, in the sense that if you don't process it, but that is fair enough.

There is a good user interface. It is a very good way of interfacing two systems. For example, in our case, the central bank clearing systems interface our systems using MQ. It is seamless. I did not face any problems. Initially, when you do the setup, you have to be careful and configure it properly. Once you do that, it is OK.

It should be able to keep a copy, so that if there is an accident, we would still be able to record the transactions. Maybe processing could be faster, in terms of EPS.
If you consider migration from one version to another, that is an issue and then initial configuration is challenging; when we change the version or change the server.

We never had stability issues. The issues are there only when you are configuring for the first time. Once you get the right configuration, then you can actually forget about the fact that there is MQ.

We have not had any scalability issues.

I have used technical support once in a while, such as when we are upgrading or when we are going to change the server or something like that. They are pretty good. In our part of the world, it's pretty good support.

Interfacing is required in any situation when you have two systems talking to each other. So, there are not too many options. One, is that you can have a file handoff. You can have MQ messaging. Or, you can have an API. So, we currently prefer API, so MQ is slowly losing its position.

Sometimes I am involved in the setup. But, now my people have become experts setting it up. There are issues that happen once in a while. For example, last year it happened when we changed the server. For whatever reasons, the configurations were in fact reset. So we brought IBM in. Those were complex configurations. For whatever reason, a couple of parameters could not be reset. Or, they didn't remember which parameters to reset.

As far as MQ, we only looked at IBM. There are many open-source products available now, like IBM MQ Plus. IBM is coming out with something called IBM MQ Plus Plus. Obviously we have not gone for it, but those are the competition.

MQ is also closely integrated with the broker; internally, it is now an API. There is a close connection.

When selecting a vendor, full scale support is important and technical acumen. If I'm asking a new question, he should be able to resolve it or at least give me direction. I also want timely support. If my production goes down at 12 o'clock in the night, there should be someone to talk to me. I think IBM has very reasonable support, so it helps. Worse-case scenario, you could call and expect an answer within the next one or two hours.

Do the first configuration really well. Maybe involve IBM right from the beginning.