IBM MQ Reviews

The most valuable features are the transactional semantics around messaging, and some of the reliability that they have built-in, from disaster recovery and deliver-once, and at most months, schemes for messages.

One of the things we do is, we send SWIFT messages and SWIFT is built on the MQ protocols. So, that's kind of its core features.

I really need more of the API management. It's perhaps the biggest thing. I don't really care that much for the analytic side but in terms of monitoring, we have everything tied in the way we need. However, that involved a lot of work on our side, but more importantly, it is really some of the APIs that allow me to do administration and provisioning the whole time.

The migration from different versions can be very different and difficult. We build a lot of our code around it. For example, we wrap it with the APIs and we embed a lot of things into our environment. We have close to 400,000 lines of code just around that and it has to be a reviewed with every upgrade.

We have a rather large implementation. Perhaps, the largest one on the planet and from a stability perspective, it's very stable, i.e., when it's used appropriately.

We usually always get to the right people, because of the criticality of some of our problems. So, it works very well.

The setup was straightforward and we wrapped it in a very complex way.

You should read the manual.

The way we use this solution, there is nothing else that even comes close to it.

What's important is that we can team up and work together because we tend to drive the products really hard. So, that relationship with the vendor, at the technical side, is really important to us while selecting a vendor.

MQ is a very affordable and easy to use messaging product. I like how fast you can write an API and send a message. Thus, its versatility, portability and easy to use functionality are valuable features of this product.

We use MQ for our insurance claims and use it heavily for CICS in the IBM Mainframe and use the IBM IMS for our applications.

Right now, with the new functions such as z/OS & distributed, I don't see any need for additional features as such. This is because everything that MQ provides, we do it. It's okay right now. Things are working fine.

The migration aspect is different and it depends on who is doing it, i.e., whether a person is doing it for the first time or a person who has done it for 18 times. I have done a lot of migrations in MQ, starting from this product version 2 and now it is on version 9. I have done a lot of migrations, so it all depends on how much experience you have, how you set up your migration task and so on. Migration is fine. I don't see any problem there.

If IBM develops a tool inside the MQ product for monitoring, then that will be better for the other IBM products available.

We have been using this solution for 17-18 years.

It's a very stable product. Being one of IBM's high-end messaging solution, it's a very robust product.

We have not had any issues. It is scalable.

I use the technical support from time to time in Hursley because MQ is developed in Hursley. I keep in contact with Hursley developers because in my organization, we use MQ a whole lot for our messaging. I am very happy with the support.

It is a good messaging product from IBM and is easy to use. It is very affordable and flexible, so I will advise other customers/companies to look into this product and use it.

The most important criteria while selecting a vendor are the customer support and easy to use the product. It is also important if the vendors can provide training to the staff and always be behind the customers to help them.

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.