IBM MQ Reviews

We use MQ as part of the core of our enterprise information bus. We started that journey in 2009. We have it both on the mainframe and in the mid-range. For us, by allowing messaging to integrate with some of our third-party solutions, like for web banking and so on, we are able to create an information highway that took in the legacy events, captured ATM and credit card transactions, and integrates that into a digital web dashboard.

It provides a better customer experience and more timely access to data.

There could be better APIs around cognitive analytics, around how the messages are flowing. For example, plugins to Watson. That would be useful.

Stability is rock-solid.

It is highly scalable.

Technical support has been good.

I was not involved with the initial setup.

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.

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.

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.

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.

We use IBM MQ as a reliable way of integrating different applications. Our transaction service operates using IBM MQ for organizing the asynchronous interaction between different applications and the core banking system. It is easy to organize parallel reading and writing, and you can easily link two IBM MQ servers using the remote queue feature. We also use IBM MQ in web services which are developed using IBM Integration Bus. MQ helps us scale web services and organize parallel execution.

IBM MQ helps us scale our applications and balance our applications' performance. MQ is quite reliable. In some cases, our application became simpler and more reliable simultaneously.

Reliable integration between MQ servers. IT helps us create flexible integration solutions.

MQ needs instruments for connection with new modern queues like Kafka or RabbitMQ.

For us, it's basically just our messaging bus. We pretty much use it just for events that are limited to various applications that we have in our company. That is pretty much the use case that we have with respect to the IBM MQ.

Also, the stability and reliability of the tool system is what makes it really easy to be able to work with.

Technically, it has made our lives a lot easier. Prior to having MQ, we were basically developing these custom in-house solutions, where we were running into a lot of issues. After bringing MQ on board, along with its integration and flexibility that it has provided us with, it has basically shortened the amount of work we had to do in order to get it set up and to get the communications happening in between.

Maybe it should have something with respect to being able to provide a graphical view of the data elements that we are processing. For example, how many messages are being processed by a certain queue or for how much time each message is staying in the queue, and so forth. If there's a way that IBM can provide this tool that can have this out-of-the-box dashboard feature, it would be helpful.

Right now, we are trying to build custom solutions so as to gather that information. We are using Dynatrace, which is one of our monitoring solutions. We try to use it to analyze how many messages this queue has processed today and then we are trying to calculate the data for how long did the message stay in the system before the application picked it up. If there is a tool that can actually provide an out-of-the-box solution of this kind, then it would be really efficient for us.

We have not experienced any stability issues. We have been running this for almost about five years now. I don't think, up to this day, we've had any server down issues primarily because of MQ, i.e., the product itself. It's very stable.

With respect to scalability, we're not such a big shop where we are continuously scaling up, but it's a pretty standard system for us. We did not really have to do a whole lot. It runs on very bare resources; it's pretty good.

We have had a few scenarios where we were trying to develop some custom security solutions that required MQ to be authenticated, when they are trying to push our consumer messages out. It was not really an issue but more of an enhancement that we were trying to do. That's when we tried to approach IBM and get their inputs on the best way to do this.

They certainly were very helpful. They provided us with the necessary guidance and showed us some technical documents that were available for our reference and basically, to get the project completed.

Actually, when I joined this company, they already had the solution.

First, assess your requirement. Basically, understand what you want to do and that's where it all starts. Doing the right analysis, finding the right solution; that's where success and failure happens.

• Ease of use
• Access to support resources
• Access to new release information in a timely manner
• Easy to digest

It is easy to use and seamless with our existing technology. It's a trusted name we know that we've used for years. It performs and it has very low downtime, if any.

With MQ, we always have trouble with the initial priming call failing. It would be nice if we didn't have the little wake-up service. Maybe if it self-monitored, had it's own health monitor, to fire those off upon startup, so we don't have to pay the price for it.

We are happy with the stability.

We have not had any scalability issues to my knowledge.

Our admins have used support in the past. As far as I know, they are satisfied with it. It's pretty solid and it's kind of the backbone of a lot of our stuff.

The initial install was a long time ago.

Stick with the out-of-the-box requirements, unless something tells you to go in another direction. And if so, definitely work with the vendor to make sure that they give you the adequate tools to do that, or help you scope that out.

When selecting a vendor, support is the most important criteria.

The integration it provides makes a lot of stuff easier. There are a lot of ways to integrate things but it works on a lot of different platforms and with a lot different technologies.

We've been able to get some disparate applications that weren't originally written to be integrated, but we've been able to make that happen.

I use the character-based interface for things but a lot of my peers like the GUI. Maybe there's a GUI available that I'm not aware of but that would be something that would facilitate it for some other people. Any kind of GUI; it could be on a phone or a browser or whatever. As far as I know, that is currently lacking, but maybe I just don't know. I primarily use the character-based interface for management when I work with it.

Because you can only put so much information on a text screen, sometimes you have to kind of shift views to look at things. That's something that, I imagine, if there was a GUI interface, you could do that a lot more easily. That would be an enhancement, I guess.

To some extent, it just runs in the background and you kind of forget about it. You don't really think about what else you could do with it. It’s just kind of running there.

It's rock solid.

I don't think we've tested the really high-end but it handles everything we can throw at it.

We have used technical support very occasionally. It's gone well when we've called, but we really haven't had too many opportunities.

Give it a try. It's not hard to do a proof of concept, get something going and build on that. You'll find that it's pretty easy to work with and it does a lot for you.

The only reason I haven’t given it a perfect rating is probably because I don't know everything it can do. I probably could take better advantage of it, but I might not be doing that right now.

The most important criteria for me when selecting a vendor to work with is reliability. I've got to trust that the product will do what they say, that they'll be able to support it, and that they'll be around in 5 or 10 years when I'm still using it. I kind of lump that into reliability. When I invest in something, I want it to be there and still working later on.

We are not using MQ to connect across cloud, mobile and devices as part of the internet of things. We don't do that on this project. The barrier to success is that nobody's interested. It's that blunt.