IBM MQ Reviews

It allows more people to be able to support the application. They have training and we get folks to actually go in and bounce services and update services through IBM MQ because it is graphical. It's fairly intuitive on what's there. It enables us to have better and deeper support as an organization.

What I like about IBM MQ is that the ability to add applications to it is quite simple. There are a lot of extensible options for security, i.e., various things you can do. It's pretty easy to navigate. It's pretty easy to install and use from that perspective. Those are the things that I really like about it. It's our web hosting application of choice over using something like Tomcat or whatever because you can click through it, you can see things, and it's a lot easier from an administrative standpoint.

I think one of the things to improve on could be more administrative profiles which might simplify the experience. IBM MQ has a lot of settings. We're only using probably a fraction, maybe 10%, of the overall settings. Working for a large aerospace/defense firm, we have pretty tight security. There are a lot of settings that we do have but we're still only just scraping the surface of what's there. Being able to get to those sub-menus can be a bit challenging.

So there's the fact that there's a lot in IBM MQ presenting only the options that maybe somebody might do, such as a web application administrator might have to do. They don't need to see all the other bindings that are there, so it could be a little overwhelming trying to find it. So, I think if there's anything, that would probably be it.

Presenting and maybe having some different options for different user experiences based on the administrative duties that you have to do as an app manager or configure the server or security would be an improvement. For instance, in our information insurance organization, we have folks that go in and look at the security bindings that we have with our applications. Having those different roles mapped would be an asset, so you're not having to go through all the various sub-menus to find it would be something that would, I think, take it over the edge.

Stability is really good, actually. We haven't had any issues with IBM MQ .

We haven't had any issues adding applications to it and scaling up from it. So all in all, I think it's been fantastic.

I would say that technical support is average. Obviously, we are going through their PMR system. They are such a large company. I think the availability of somebody on the phone or calling somebody when you need something fixed immediately is a bit challenging for the organization. I think that's an area that they can improve on.

If we have IBM MQ or one of the applications go down, our entire plant is down. Then sometimes, it's 2-3 hours or something before someone calls us back. It would be nice if we can call somebody and have somebody you can actually work with that is knowledgeable on the product right away. That's my only gripe.

For a lot of other things, like lower priority items, working through the PMR system's been fine. I think their system is good. I just think that they need to be a little bit more responsive to their severity one tickets.

Initial setup was pretty straightforward. The more complicated part of it was the actual IBM CLM tools implemented within IBM MQ. IBM MQ itself was pretty simple.

I've heard that there have been challenges with upgrades, but we haven't gone through an upgrade cycle yet, at least in quite some time. We'll see how well that is but we haven't had that challenge yet.

We didn't evaluate any other products beforehand. It was just what IBM recommended.

Typically, what we'll do is, we'll go with the vendor recommendations because from a support perspective, if they're saying that because they support an application, we prefer to do go with that one because we know we can get the support as it goes on. That's really it.

Access to support is the most important criteria for me when assessing vendors. I think support is a key for us being in IT because we are supporting the application, so we need good support.

The second one is the ability to reach the developers on key issues and improvements that we would want to see in future versions of the application. Being able to influence the roadmap, I guess you could say. That would probably be the second thing we care about.

There are a lot of vendors that don't take that seriously. Like, you go in and you might have great features that would really broaden their product base, adoption of their tools. Some want to hear it; some don't. I think the ones that do hear that end up being more successful; they find ways to work that information back into their development stream.

That's probably the second most important criteria but, again, being in IT, I'm looking out for myself a little bit there. Support is number one.

I don't think I'd give anyone any advice at all. It's pretty straightforward to go and implement. The only thing that I would say is that perhaps if you're - depending on what you need to do - like deploying some of the IBM CLM tools, you might look maybe for a lighter-weight solution because of those various menus.

I know there are other IBM products and there are various lighter-weight solutions that are provided as part of the IBM MQ family. Going with something that's not full IBM MQ but maybe one of the other IBM products that's much more suitable for your organizational needs would be a good choice.

The pub/sub model is the one that we use heavily on IBM MQ. That's the most valuable for us. We are an enterprise team and we provide a lot of integration to the enterprise systems, so when the data changes on the enterprise systems, we publish a lot of these changes to all the subscribers, whether it's a customer change or the account changes.

It provides seamless integration with the enterprise and any enterprise data changes. Also, the reliability is important for us.

Using it as a service, as a platform on cloud, would be an improvement. I think it's always had room for improvement, so I would definitely put more on the cloud-based services than on what we currently use.

Also, ease of use isn't that great, as it's still considered enterprise class, whereas the more modern applications or platforms do offer modern interfaces and a way to integrate with those systems. Still, I feel its very legacy-natured.

I think the stability is great. That's one of the assets IBM MQ is known for.

So far, I think we haven't faced any scalability issues, but it is well architected in terms of its high availability and DR purposes.

I don't have any complaints about the technical support.

I think it was always an IBM MQ base which we used.

I was not involved in the initial setup.

I don't have information regarding which vendors were considered before we chose IBM MQ.

The features and the reliability of the product are important considerations when selecting a vendor.

Definitely it's a great product. But, I think we need better interfaces.

Most valuable for us are the queue depths and creations for the installations. Being a business in financial solutions, we depend on it more for those things, so it's very valuable for us. For most of the applications like JBoss and others we use IBM MQ.

It just needs a better installation. An easier user-friendly installation.

The stability is good. I mean we do have some issues but we always contact IBM whenever we have performance-based issues and we get solutions quick and fast.

Scalability is great.

The technical support is great. Normally, whenever we have an issue, within 24 hours we will get a resolution, so we can close it and leave it to the IBM technical support guys. We get a solution mostly within 24 hours, so that's great.

We didn't have another solution previously, we have always been with MQ.

I would say it was both straightforward and complex, but not that complex. I mean the installation normally would take some time and with all of them open, it's just a button click and you're done.

I wasn't involved in the selection of the vendors.

Go for it. You should always check out the performance and trust for a good solution.

We can do the authentication and authorization of incoming requests using IBM WebSphere and DataPower. That's important to us because we can confidentially send the data with restrictions to other platforms.

In terms of benefits, our customers are happier since we are doing a good job.

In the next release, we would like to see more authentication capabilities embedded and included in the existing product.

I don't know about the stability.

We are good with the scalable data in the product.

I haven't used the technical support.

I was not involved in the initial setup.

I'm not sure about alternative solutions considered.

I definitely recommend them.

When selecting a vendor, we are looking for timely interaction. In case there any issues, we need to get support immediately.

For the IBM MQ solution, the most valuable feature is the interconnection of data between the different systems. In our company, we use mainframe, Windows, and Unix and it provides communication with different plans like associations and the federal employee plan. That's what we're looking for.

The main feature right now that we're looking for is open source and that is where we see more challenges coming up with the product. This is because a lot of the applications are going with open source such as cloud and providing connection with the cloud. We have Amazon AWS cloud services or Microsoft Azure services and the applications are deployed there, so connectivity with those type of applications is necessary.

IBM MQ has broadened a lot of communication between interconnecting the applications. It's more fault tolerant, since we have the message delivery guaranteed. We have high availability for the application and it's not stateful. It has provided the features such as the application to process messages from the mainframe as well as from the web, so we can increase the throughput of the system.

The response time could be improved because that's our main concern. Once our system is down, then it impacts our business since we have another partner who is dependent on us.

There is need for more integration with cloud. That's what we're looking for, because that's what the company is moving towards.

The stability is very good, actually. In our organization, we saw almost 99.9% uptime for the product.

The scalability is really good, because only your system limits the functionality. We can add more storage / more memory and we can always scale up.

We have used the technical support, but we are more concerned about the response time. For example, we have severity 1 issues and the system is down, but we still see time gaps and they don't respond.

Previous, we were using the Oracle Tuxedo solution and it had a lot of limitations. It was not able to interface with a lot of the other systems, i.e., the interface was only with C-based operating systems/programs that use only Windows. That's why we switched to IBM MQ, since it brought a lot of benefits.

The setup was complicated because when I started and there were around 400 queue managers. We have four companies that we communicate with, so we changed a lot of the architecture, i.e., we went from the local queue managers to centralize and to reduce issues, in order to have a more manageable system.

Actually, we looked at IBM and Microsoft. However, IBM had a wider scope of the product, and compared to it, Microsoft provided limited platform support. That's why we chose IBM.

The factors that we look at before selecting a vendor, are how the product supports integration with other companies and the overall support they provide to us.

Definitely, you should use IBM MQ because it is a stable product and provides a wide interface with different systems. You can talk to mainframes on other systems as well, so I would highly recommend this product.

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.