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.

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.

Our use cases include ATM transactions where a customer, for example, inquires about balances. Transactions go from an ATM at a branch, using a Java application to take the information, and it connects into our mainframe, gets the balances, and goes back. 

We also use it for when customers go online using the internet itself for things like pre-approved home loans. We take the customers' information from the front-end and pop it into MQ to look up the customer's data in the bank itself — all of the databases — and then come back to the customer. 

It is also used in our mobile banking. MQ is connected to SAP in the background. MQ is in between, passing information to SAP and SAP will give the reply back on the mobile banking app, like when a customer asks for a one-time password.

We initially went with a single server or two servers. We used a lot of the mainframe and we used it on the one server. Then we realized that we were down to a single point of failure. What we did was we enabled something called queue sharing where you have multiple landing platforms, which lets you execute multiple applications in the background. And we're now able to use our HA failover quite extensively. It previously required one server to be down and there would be an effect on customer business. Now it requires at least three servers to be down before we start feeling the workload. And even then, we're hardly ever down because we have now spread the load using the queue shared clusters.

In terms of the solution helping to reduce the cost of integration, we're using what is called the MQ Appliance. Because the appliance connects multiple solutions in our bank to this platform, we don't need to procure more licenses or more servers or more infrastructure. So at the moment, we're using a very cost-effective model, compared to two to three years ago, which is when we started to consolidate servers. We had about 400 servers but we've reduced their number by moving them to the appliance. We've consolidated all of those server licenses and server infrastructures.

For example, we took a server that was front-end, using Java, and connected to the mainframe. We have that entire server's application queue, entry queue, and all the objects moved onto the appliance. And there is no cost to it. It's just a box. There's no operating system on it. We have MQ on it and MQ then connects things to the rest of the bank, so we save on the infrastructure, on server licenses, and MQ licenses. We've created a setup like that a few times already in our bank.

This process of integration has saved us a lot of time. Previously our projects would take at least three to four weeks. Now, once we have firewalls and security in place, and once we have an acceptable solution design in front of us, they take three to four days. From the time we design the solution until things are connected to the appliance, it takes a week. It's only fast because most of it is scripted. It's almost like a container.

What we find most valuable is the fact that we can decouple it from the application. If one side is down, but someone in the bank is serving a customer and needs to connect to an account, he can put in the information and wait. When the remote system comes up and connects, we can push messages with the push function. So what is quite useful is the asynchronous function which means we don't lose everything in the bank. Although we use a lot of things synchronously, asynch is the best thing so that no banking information is ever lost, even when the network goes down and comes up.

We can also expand it across many servers with the cluster, using load balancing and failover. We use that extensively as well. The load balancing works absolutely wonderfully.

Overall, it makes us very flexible in the architecture we can use at the moment. When someone comes to us and says, "I need ABC," we can put together the correct solution for him with all our flexibility.

We use Red Hat from a server point of view. With our Linux box, MQ is on the box itself. We use that quite extensively as well. Inside of that, we find the shared HA function quite useful. It allows us to do HA really quickly, compared to how things were before.

At the moment we're very limited in the way we can interface with the cloud. 

I have been using it for 20 years now. I've been at the bank for 17 years and I used it before that as well.

The stability of the solution is very good. I would give it a nine out of 10. The main features are its reliability and availability and, as a messaging platform, it's very good in those areas.

The scalability is the one area where IBM has fallen behind. As much as it is used, there is a limit to the number of people who are skilled in MQ. That is definitely an issue. Places have kept their MQ-skilled people and other places have really struggled to get MQ skills. It's not a widely-known skillset.

In terms of the number of business areas using it in our bank, there are about 15. A lot of the major ones use it, such as credit, operations/finance, home loans, and ATMs. 

The bank has been very good in getting good technical resources to help us. There is a specific couple of people in IBM who know our architecture itself. We have what is called a value-add program where, when we have a problem or a service request, it will go through IBM but it will automatically land in the box of one of the experts who knows our architecture very well. We reach the same two people each time. We don't have to explain things to them.

We did not have a previous solution. Early on, we didn't have many options to choose from. A procurement person came along and told us that this is the best solution for us.

The setup was very complex in the beginning: how we had to put it in, how we had to tune it, and how we had to fix it. There were so many parameters. It wasn't just a simple drop-in, deploy, and go. In addition, because certain applications work in a certain manner, it required a lot of tuning.

My team, on average, has 10 years of experience on MQ so at this stage we've come to the point where we can tune it fairly quickly. So while the initial setup wasn't simple and quick, it has become very quick.

The initial setup took us several weeks, if not a few months. We had to get IBM to help with things in the beginning. We had system issues then, but it has been stable since then.

The IBM consultants we worked with were very good.

MQ's features are very extensive compared to SQS on Amazon or messaging from Microsoft. Those solutions have basic features in there. They say, "This is what 90 percent of the use cases will use," whereas MQ is very robust in the way it's set up, in the way it works, and in the way it can be tuned. You have a lot of connections where you can connect thousands of users to the bank and thousands out of the bank as well.

It is definitely way ahead of all the other messaging platforms. It's like the "BMW" or "Mercedes" of messaging. The others will still do the work, but they're fairly average in what they do. They're very basic compared to what we do. Because we are a major bank, we have many different platforms and many languages, so we use it very extensively.

You must be careful in that it must fit what you want it to do. A few years ago, we had a silo approach where everybody had their own IBM MQ and their own application support with their own teams. That got out of control. In the last few years we realized that you need to be careful about the deployment model you're using. And you need to make sure it's used for the proper use cases.

That's really the biggest lesson I've learned from using IBM MQ: You need to be very sure about what you want it to do.

I would advise that you talk to someone who knows about the solution and who is not biased. Set up a call with someone like me to look at the solution before you decide to go down this path and, similarly, before you decide to throw it out. Talk to someone who has at least seven years of experience with it and who can give you an unbiased opinion about how it works, and then make up your mind. People have come to us and we have said, "Based on what you are doing, we don't think MQ is the best solution for you. You should be looking at other solutions." And other times, we'll tell them that this is the perfect solution. 

The way MQ works is very good from a messaging point of view. There is very little that needs improving. MQ is very flexible and very tunable. We use it to transport hundreds of thousands of messages every day with absolutely no problems.

At the moment the solution is on-premise. But in the last two years, the bank has decided that it needs to go with the public cloud. So in the last two years, most of our development has gone towards decoupling MQ because a lot of the vendor applications were on the box where MQ was. We're working on the solution and decoupling everything so we can push toward the cloud itself. The solution's built-in connectors are more applicable to when we talk about cloud solutions. 

As for containerization, eventually we will go for it but, at the moment, we don't use it. It's difficult to work on a mainframe because of the way it's set up. But it's definitely something the guys will be using when we look at the Unix servers and other boxes.

For deployment and maintenance we have a team of eight people. We have three people on the mainframe and another three to four people for the appliance. They work with each other as well. On the Unix solution, which includes Linux, AIX, etc., we have another team of four, but all these teams overlap. The average upgrade won't take less than two people, but on the Unix box, upgrades are straightforward and someone can do it on his own.