We just raised a $30M Series A: Read our story

IBM MQ OverviewUNIXBusinessApplication

IBM MQ is the #1 ranked solution in our list of top Business Activity Monitoring tools. It is most often compared to Apache Kafka: IBM MQ vs Apache Kafka

What is IBM MQ?

    IBM MQ provides the universal messaging backbone for service-oriented architecture (SOA) connectivity. It connects virtually any commercial IT system, whether on premise, in the cloud, or a mixture. For more than 20 years IBM has led the market in messaging middleware and more than 10,000 businesses across all geographies and industries rely on IBM MQ.

    Visit for your trial here.

IBM MQ is also known as WebSphere MQ.

IBM MQ Buyer's Guide

Download the IBM MQ Buyer's Guide including reviews and more. Updated: October 2021

IBM MQ Customers

Deutsche Bahn, Bon-Ton, WestJet, ARBURG, Northern Territory Government, Tata Steel Europe, Sharp Corporation

IBM MQ Video

Pricing Advice

What users are saying about IBM MQ pricing:
  • "You have to license per application installation and if you expand vertically or horizontally, you will be paying for more licenses. The licenses are approximately $10,000 to $15,000 a license, it can get expensive quite quickly."
  • "IBM MQ is expensive and they charge based on the CPU."
  • "It is a licensed product. As compared to an open-source solution, such as RabbitMQ, it is obviously costly. If you're using IBM Message Broker, which is a licensed product, IBM MQ is included in the same license. You don't have to pay separately for IBM MQ. The license cost of IBM MQ is lesser than IBM Message Broker."

IBM MQ Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Sunil Sahoo
Manager at a financial services firm with 10,001+ employees
Real User
Top 20
We don't lose messages in transit and we can store messages and forward them when required

Pros and Cons

  • "Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. We don't want to notify the customer for each and every payment but, rather, more like once a day. That kind of thing can be enabled with the help of MQ."
  • "I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka."

What is our primary use case?

We are a bank whose core banking system is not so advanced. It is still running on an AS/400 system. Credit Card system is are deployed on IBM mainframes. About 70 to 80 percent of the bank's core systems rely on IBM AS/400 and mainframes. The enterprise service bus is used in conjunction with MQ to break synchronous web service /TCP calls into asynchronous MQ calls and expose them a web services-based or API-based service for both internal and external customers. 

As part of enterprise architecture principles, we have enforced all connectivity to be service/ interface based by using ESB, MFT or API. Minimize the point to point connectivity.

We are using dedicated IBM power/pure-app servers to run IBM Integration Bus, IBM MQ, and WebSphere Application Server. These are the three components being used for the bank's enterprise service bus.

How has it helped my organization?

People have started using the likes of Kafka, Spark and other new messaging technologies. But when you take the likes of banks into consideration, which mostly are running on mainframes and AS/400, implementing advanced technologies are not an easy job. Getting an MQ-certified guy is not that difficult in the ASEAN market. There are a lot of certified professionals. That's one of the reasons we still use MQ for most of our messaging. We are still looking at open-source deployments but we have not yet implemented anything like that because of the knowledge GAP & dependency on the existing products. We do not have a dedicated team to take on that task yet.

With IBM MQ still in the bank, and a dedicated team which has expertise in it, we really cut down the time-to-market, from a few months to a few weeks. The development framework is already there. If business comes up with requirements, technology team already know what needs to be done. And by building the in-house team, it gives us the facility where we don't need to ask the IBM guys or other vendors in the market to help us every time we have a new requirement.

Another way MQ has improved the way our organization functions is customer notification. Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. There are requirements for notifying customers on a real-time base & also for each and every payment sometimes, once a day. These are be enabled with the help of MQ.

In addition, there are fewer failures during the end-to-end payment process. MQ comes in very handy because we don't lose messages in transit (message persistence). It gives us the ability to store and forward messages when required. We heavily rely on MQ for these kinds of requirements.

Also, we have certain applications that want to receive the messages in both production and the disaster-recovery data center at the same time. Without MQ in the picture, it would have been very difficult for us to configure that. MQ Publish subscribe capability is very helpful in that scenario.

MQ has helped to reduce integration costs, mostly by acquiring the enterprise license of MQ. We can actually set up multiple MQ servers in the same environment and each MQ server is dedicated to a particular application. We also use MQ up to a level where the messages are coming from multiple host systems and they go back to a single channel. When written back, the response goes to the exact host that had sent the request (Message Affinity). Without a tool and without a messaging architecture that is as good as MQ's, it would take a lot of time in hard-coding to achieve that. Prior to the team being set up and having these frameworks in place, it took roughly two to three months to deliver any of these integrations. Now it takes three to four weeks. It has helped reduce the effort and man-hours by half.

What is most valuable?

We have been using the normal messaging along with channel authorization. 

At certain times — although not in this bank, in my previous experience — we had used the message authorization on top of the queue. That meant that the moment a user tried to write a message it would be authorized before it was written. 

In the ESB architecture, MQ is used to decouple synchronous consumer specific web services calls from the host system calls, by implementing state management. Request and response message matching rely on MQ Message ID & Correlation ID (MQMD header properties).

Message load balancing being implemented using MQ or achieving high throughput, while Message affinity ensures response messages are propagated to the very same host system which had generated the request message.

MQ publish subscribe feature being used to for notification where multiple instance of one or more applications can subscribe to the same topic at different time. 

Message expiry features ensures the redundant or unwanted messages are expired automatically from the MQ based on the settings. This feature is being used at times to ensure no duplication of payments.

Message persistence feature ensures the message availability even after any planned/unplanned downtime.

MQMFT feature ensures files are delivered asynchronously and complete file transfers are automated.

MQ authorization can help to ensure high level of security in accessing the messages from a MQ server or sending messages via MQ channels between two or more systems. 

What needs improvement?

Day-to-day, I don't really see anything much that we are lacking, but I have never really compared MQ with other products to see what it lacks.

I am well aware of the way that IBM sells the suite of products. But I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka.

One of the other improvements that I would like to see from MQ is for it to be containerized. It may already have that functionality.

For how long have I used the solution?

I have worked with IBM MQ for more than 10 years. I started using it in 2006. Recently, in the last three to four years, I have not had any work in the development area. I have moved on to enterprise architecture, so I don't really get a chance to use the solution every day. I haven't used it in the last three years.

I do read up on the new features when I get a chance to read, but I don't exactly have hands-on now-a-days. I now guide the team when they have issues, on things like how to set it up, how to have particular architectures on MQ. I still consult on it and I'm still familiar with it.

What do I think about the stability of the solution?

It is stable.

We have only had issues with the IBM GPFS File System, but that is a different product. We had an issue when we wanted to have an Active-Active deployment architecture across our production and disaster recovery site. We wanted the same MQ server to fail over to the disaster recovery site and come up from the state in which it went down on the production site. To achieve that we need a synchronous file system that is able to replicate the same data on the other side.

What do I think about the scalability of the solution?

We haven't had any scalability issues with MQ. We are running on a scalable hardware platform with a goal of virtualizing deployment up to multiple cores, and it can add on more and more compute and RAM when required.

For at least the next five years we are sticking with the existing implementation, while we are looking to implement new features, such as containerization.

How are customer service and technical support?

Our in-house support members are all certified. Most of them have 5 to 10 years of hands-on experience. They don't fall back on IBM for day-to-day support/issues. But if there is a Severity-1, they do log a problem ticket for further expert advises from IBM.

We have only had one issue that I can recall from the last four or five years, to do with the file synchronization. To figure it out, it took a few days.

Overall, the support has been good. As IBM doesn't have a lot of resources in Malaysia, they rely on India or Singapore region for support sometimes.

How was the initial setup?

I am MQ version 6, & 7 -certified solutions architect & system administrator. So I find the setup to be very easy. I have been using MQ since very early of my career, and I was also with IBM for quite some time. So for me, it's very straightforward. The installers come with a nice, quick-setup guide, and most of the time, after the training, users can go set up their own MQ.

The amount of time it would take to bring it to production depends on the scope of the services. If I just have to install MQ, it is not more than an hour. But if I have to install MQ for specific servers, I would probably have to take account of the log size, its location, and what the volume is per day or per week, availability aspects, so it would take a bit longer.

Most of the time, when we implement MQ, we implement it along with other products. It depends on the use case. If you just want to query the server to get the information, I would recommend that to be asynchronous because inquiries are huge in volume. If the use case is payments, it could be defined as synchronous mode, and within the flow we could still break it into two or three parts.

From the design point of view, it is still pretty straightforward, depending on what licensing model you want to go for. If you want to use one MQ server with multiple clients it's doable, but if you have more critical systems running, then you should go for multiple MQ servers so that you have a dedicated server for each particular application. Those are the guiding principles that we use internally for projects to follow.

For deployment, we have written our own scripts. We are mostly relying on AIX/ Linux server. Our scripts are pretty much standard to do things like create/ change queue, channels and it's properties, shut down, restart the MQ services. All these are already scripted, so for our support team it takes them a few minutes to run through them, one after the other, and wait for scripts to be executed.

What about the implementation team?

We have a fully dedicated team in-house to support MQ. There are teams that can help. TCS is one of them and IBM itself is one of them. And there are a few local vendors in the market that are quite proficient in it.

We have a support/ maintenance team of four pax and we are running 200 to 300 services on MQ. The solution doesn't exactly provide a user interface to the business user. The solution is more of a technology layer to support applications and we have 15 to 20 applications that are connected via ESB & MQ.

What's my experience with pricing, setup cost, and licensing?

We have a multi-year OIO (open infrastructure offering) with IBM and if there is any additional licensing required it gets deducted from the OIO. We have been using IBM's other services as well.

Which other solutions did I evaluate?

We have been looking at some competitors; for example, TIBCO Messaging and MuleSoft from Salesforce. One difference I have seen is that TIBCO is already a containerized edition. I have yet to discuss with IBM MQ if it is available on container. Another thing TIBCO has is that its messaging framework comes with a package for Kafka support as well as plugins for MQ connectivity. It allows you to connect to MQ or to Kafka for messaging.

We are also going to look at the IBM API-led integration. We have been running IBM products for some years so we may want to compare & see how these gets compared with their counter-parts.

What other advice do I have?

Overall, MQ is good, capability-wise. You still need a messaging platform and MQ is quite a reliable messaging platform. I have not seen hiccups using MQ across multiple environments in the bank. I have been using it since 2006 and I have never experienced any issues with the product itself. The guidelines of the product, the way it is used, the way things are done, are pretty self-explanatory. There are multiple blogs/ online helps available and there is a lot of help available from experts around the world.

Have a look at the features. If they complement the requirements you have, go ahead with it. If you are very technical and want to understand more about the open-source tools and features, that may require a notable learning curve.

The product has been around for a long time. It's probably time to see what MQ is going to add to its features. We have not started using IBM Cloud Pak with Red Hat OpenShift yet. We are also looking at using containerization but probably it may take some time.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
NK
Technical Lead at a financial services firm with 10,001+ employees
Real User
Top 20
Using the Appliance has enabled us to consolidate servers and licenses

Pros and Cons

  • "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."
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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 is most valuable?

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.

What needs improvement?

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

For how long have I used the solution?

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.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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. 

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

The IBM consultants we worked with were very good.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Learn what your peers think about IBM MQ. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
540,884 professionals have used our research since 2012.
MT
Head Of Operations at a financial services firm with 10,001+ employees
Real User
Top 20
Highly scalable, easy to use, and entirely robust

Pros and Cons

  • "I have found the solution to be very robust. It has a strong reputation, easy to use, simple to configure in our enterprise software, and supports all the protocols that we use."
  • "Everything in the solution could be simplified a little. We have trouble with the configuration and cost which is mostly an internal issue, but nevertheless, the errors do come up when there are configuration changes across a specific version. We have slightly different versions, which may have slightly different configurations which cause issues."

What is our primary use case?

We have two different use cases for this solution. We use it for the interactive interconnectivity between clients into the cloud and applications communicating within our enterprise software.

What is most valuable?

I have found the solution to be very robust. It has a strong reputation, easy to use, simple to configure in our enterprise software, and supports all the protocols that we use.

What needs improvement?

Everything in the solution could be simplified a little. We have trouble with the configuration and cost which is mostly an internal issue, but nevertheless, the errors do come up when there are configuration changes across a specific version. We have slightly different versions, which may have slightly different configurations which cause issues.

It is intensive to maintain and train people to use the application. There has to be a certain amount of education going into the developers, as well as the infrastructure staff. This could be improved.

For how long have I used the solution?

I have been using IBM MQ for approximately 20 years.

What do I think about the stability of the solution?

The solution is very stable.

What do I think about the scalability of the solution?

We have found the solution is highly scalable. It is very easy to scale horizontally, we can scale across and make another instance of the application if we need to.

We have approximately 2,000 to 10,000 are using this solution in my organization.

How are customer service and technical support?

The quality of service can vary depending on the level of support for different issues. If it is on an issue with what IBM does within their cloud that they control as an ASP it can be somewhat complicated because it is not visible to us. They only support and run the model for us. They will do the updates, manage, and make sure everything is working, it is an effective service but if we have an issue, we do not get that much of a response from them. However, when it is on-premise with us on our side and we talk directly to IBM and they support us fully for the application. 

How was the initial setup?

The installation can be fairly simple, but when changes or modifications are necessary within the system for the implementation it can be a bit difficult. We standardize a lot of the process whether it is using Jenkins or Pipelines, or another solution to make it as simple as possible. However, when we make changes and more errors and configuration problems come up, it can be quite difficult to narrow down those problems. Generally, we automate most of this part which has limited the impact but the process could be improved.

Since we automate a lot of the deployment elements I am not sure the breakdown of how long it takes for each part, but typically all together it takes approximately half a day.

What about the implementation team?

We do the implementation of the solution.

This solution is a message exchanges system for queuing messages. The messages come in and if they are rejected or if they fail to be received, they sometimes fall into something that is called a dead letter queue, queues that are dead, or queues that are ineffective. Those have to be maintained and monitored at all times. There is quite a lot of attention needed. It is extremely critical and the robustness is extreme when it is on the edge. When it is in the enterprise is not that bad, but if it is on the edge, outward-facing to the client, we do a lot of work to maintain and ensure that it is working at all times.

What's my experience with pricing, setup cost, and licensing?

You have to license per application installation and if you expand vertically or horizontally, you will be paying for more licenses. The licenses are approximately $10,000 to $15,000 a license, it can get expensive quite quickly.

We maintain and support a lot of applications across a wide enterprise. Therefore the cost of licenses increases with each individual implementation of a client because we have to pay for licenses. We are looking for an alternative solution to reduce costs by going to an open-source messaging system because we do not need the robustness of IBM MQ.

Which other solutions did I evaluate?

I have evaluated Rabbit MQ.

What other advice do I have?

If you want a robust enterprise application that you know is going to be around that you can trust and you are very comfortable with the concept that you are going to pay for that stability and robustness, then IBM MQ is the best choice. If you are on a lighter throughput or you do not need to worry about the robustness as much then Rabbit MQ could be the better choice. It is a fairly stable application, and it works very well but you do not have that industrialization and long-term code benefit that you receive from IBM WebSphere. If your use case and budget fit then this solution would be a great choice.

We have used the application for a long time. I understand it, how it works and therefore I feel comfortable with it. From a pure usage standpoint, it is great. It will handle anything, but you have to be willing to understand that you are getting into something you cannot go backward on very easily. You cannot easily swap another suitable or similar application out without a lot of work involved. You have to be very careful what you are trying to accomplish with your software.

I rate IBM MQ an eight out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
AA
Unix/Linux Systems Administrator at a financial services firm with 10,001+ employees
Real User
Easy to install and manage, with the stability needed for our banking application

Pros and Cons

  • "The most valuable feature is the Queue Manager, which lies in the middle between our application and our core banking server."
  • "The memory management is very poor and it consumes too much memory."

What is our primary use case?

We have a core banking application. If any system or application wants to talk to the core banking application, the request and the response will go through the MQ servers. The requests and responses are in the form of XML.

We have a VMware environment with Windows and Linux. 

How has it helped my organization?

We have clients spread all over Africa and they have to process different types of requests, such as credit requests and debit requests. We use the Queue Manager to handle these requests. Our MQ server will accept the request and send it on to our core banking application.

If you imagine the order from left to right, the application is on the left, then the enqueue server is in the middle, and the core banking is on the right. In between the queue server and the banking application, we have APIs and systems in place to understand the XML files.

What is most valuable?

The most valuable feature is the Queue Manager, which lies in the middle between our application and our core banking server.

Managing this solution is not difficult.

IBM MQ is very stable, which is important for our core banking application.

What needs improvement?

The memory management is very poor and it consumes too much memory. We have 24 gigabytes of RAM and almost every day, we had to free up processes so that it can run.

Some of our messages were not being transmitted so we had to manually look at the MQ server to cut and paste them. That is supposed to be fully automated. The problem is normally a routing issue but it is compounded if there are connectivity troubles. For example, if 3,000 messages are supposed to be sent but 1,000 were not then you have to do it manually.

The solution is not very lightweight and if it could be decentralized, then put into three or four containers, it may be an improvement in this regard.

For how long have I used the solution?

I have been using IBM MQ since 2015.

What do I think about the stability of the solution?

The MQ service has never gone down and has never failed us. It is only offline when the VM is offline.

What do I think about the scalability of the solution?

This is a scalable solution. We scale by adding another VM to our cluster.

We have eight engineers who are using MQ, but in terms of end-users, or people who are consuming the services, there are thousands or millions. It is an enterprise-level organization and each application has a user base, so the scale depends on the application.

How are customer service and technical support?

I have never had support for this solution.

Which solution did I use previously and why did I switch?

As far as I understand, we did not use another solution prior to IBM MQ. Our old strategy did not use this type of technology.

How was the initial setup?

The initial setup is very straightforward. I have done it both on Linux and on Windows. With Windows, it is just a case of hitting the "next" button. I would say that within ten minutes, you should be finished with the installation.

Prior to the installation, you have to make sure that you have Java installed.

What about the implementation team?

I deployed this solution for the company.

The number of people required for maintenance depends on the environment. We used to have one person manage each application that was connected to the MQ server, which meant that we had four people maintaining it.

What was our ROI?

It is difficult to assess the ROI for this type of solution.

What's my experience with pricing, setup cost, and licensing?

IBM MQ is expensive and they charge based on the CPU.

Which other solutions did I evaluate?

I am familiar with a couple of similar solutions, including Red Hat AMQ. In fact, I am trying to migrate to Red Hat. It is very easy to install and get it running. All you have to do is get your API and you're done. Stability-wise, however, with Red Hat AMQ, I have seen cases where some of the messages were lost. IBM MQ is definitely more stable.

What other advice do I have?

For the most part, this solution serves our purpose. It is not difficult to manage and the only challenges we have really had were to deal with some of the messages manually.

My advice to anybody who is researching this solution is to consider costs first. It is expensive and you have to ask what value you are going to get from it. You need to consider factors like how many messages you are sending per day. If your budget is sufficient then IBM MQ is your choice, otherwise, you should look into a cheaper option. Also, if stability is the most important thing to you then IBM MQ is the choice that you want to make.

I would rate this solution an eight out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
NK
Software Engineer at a financial services firm with 10,001+ employees
Real User
Highly secure but there sometimes are complicated network issues

Pros and Cons

  • "IBM is still adding some features and coding some other systems on the security end. However, it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes."
  • "There are many complications with IBM MQ servers."

What is our primary use case?

We provide a channel that we call "the link," so we are distributors of numbering services. These links are connected to a simulator, for example, when MQ is related to some application or the scanner. It's a synchronized communication where we first check two-step authentication. So first, we start with the authentication. In the second step, the MQ server provides the connection. Then the system decides if it can make the connection or not. For example, if I'm uploading something, it will check one cluster, not the other five. So next time, I'm just checking to see if we can connect. After that, the other side is also checking. Those clusters are physical connectivity clusters.

We are sending everything. The partner and we create an acknowledgment number and check to see if everything is fine or not. Once everything checks out and we have verified the person with our partner, we establish the connection, sending a message. Then we are also checking the permissions and format. Sometimes there are some errors, so we have to check the login acknowledgment number and figure out what the error code means. We are handling everything for the project, from the code and deployment to support. We are handling everything through an RFP repository. So from there, we are handling every version released in the last two years. Every year, we upgrade according to the guidelines.

What is most valuable?

There are so many good things with IBM MQ networking. So many complicated issues arise when you're trying to configure your network, and MQ helps by providing the clustering. In our project architecture, we have a cluster that distinguishes between major requests from applications. There is also a centralized cluster. Let's suppose 10 applications are connecting to that cluster. In each application, we add differently. 

If I need to add multiple features to the centralized cluster, we can create another cluster. From there, the GMG is connected. Also, clusters can provide a backup. So suppose this solution faces some failure, like a power outage, MQ can automatically redistribute the load to other servers. 

We are using the synchronizer and another module in our product. We are stepping the connection from the IBM channel. After that, we can send or receive any message. This is synchronizing. We are handling the clustering, and we have created a design for how the NP is built with the partner.

IBM is still adding some features and coding some other systems on the security end. However, it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes.

What needs improvement?

Sometimes, there are network issues, which means more applications are connected to those messages, so I would like to fix that. For example, suppose there's a new network, and I want to add virtual memory to address a network issue within the cluster. So there is a network issue that needs to be resolved from the cluster. So I need to add the permissions for that particular team or particular time. There are many complications with IBM MQ servers.

For how long have I used the solution?

I've been using IBM MQ since last year.

What do I think about the stability of the solution?

IBM MQ is reliable.

How are customer service and support?

We don't use IBM support much. Sometimes partners will come to us with questions, so we just guide them. Sometimes, you need an MQ person because they have access. We guide the customer to ask this question. You have to ask the MQ entity or the entry person. They will help you. And we are not writing any protocols because a separate team does that. And also, if anything goes wrong with the MQ product, then IBM will address that.

How was the initial setup?

From a coding perspective, it's a straightforward process. There are no complications. We cannot directly access the IBM server because there is a separate team assigned to do some security and get some code of conduct from the MQ team. They are handling the MQ server. So we ask them to create these entry servers to discuss that. And also, we are defining everything. We are responsible for handling invalid queries. So they recreate a wrong question or wrong to them. So, whatever is an appropriate question. 

In terms of maintenance, there are three reasons you'll get a maintenance window. On the maintenance window, we are just restarting the epicenter. Nothing else. If it requires any patching or updates, we perform those. But you don't have to restart the application.  The epicenter typically runs continuously.

What other advice do I have?

I rate IBM MQ seven out of 10. It's a good option for anything banking-related where you need secure communications. There are some other similar products out there, but I'm not about other servers. But I'm aware of our BME. So if you're doing banking or anything that requires secure channels, I would recommend IBM MQ. 

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
JL
Lead Architect at a retailer with 10,001+ employees
Real User
Top 20Leaderboard
It's a very strong integration platform but it's developed as more of an on-premise solution

Pros and Cons

  • "The most valuable feature is that it's a very strong integration platform but it is quite a monolithic solution. It's got everything."
  • "It's hard to put in a nutshell, but it's sort of developed as more of an on-premise solution. It hasn't moved much away from that."

What is our primary use case?

It's the EAI for connecting all our services like transport systems, replenishment systems, and order entry systems to our supply chain warehouse systems.

What is most valuable?

The most valuable feature is that it's a very strong integration platform and it is quite a monolithic solution. It's got everything.

At the moment we're trying to be a little bit more nimble in terms of how we deliver things for the business. We need to look at using some of the cloud-first as we have invested quite heavily in Azure. So we want to move away from all our legacy data centers and at the right time, we will move into the cloud as much as possible.

What needs improvement?

It's hard to put in a nutshell, but it's sort of developed as more of an on-premise solution. It hasn't moved much away from that. But we want to use the auto-scaling and scalability of some of the cloud services. It has developed a fair bit in terms of even the database of the board and stuff like that. Over the next three to five years, we want to move totally into the Azure.

For how long have I used the solution?

I have been using IBM MQ for fifteen years in total. 

What do I think about the stability of the solution?

It's very stable.

What do I think about the scalability of the solution?

It's the old way, old school scaler, where you need to add calls and you need to add memory, you need to add compute power, and you need to add storage capacity. You need to have bigger CPUs and more and more cores.

That's the old way of doing it. So you need to think about hardware. You need to think about memory, you need to think about storage capacity, you need to think about different switches, network switches, and whatnot. Scalability hasn't been a problem. It's just the sort of older generation of doing scaling so we want to be able to scale in the cloud.

The process for the scaling could be a little bit simplified.

How are customer service and technical support?

IBM handles technical support. They are good. 

Which solution did I use previously and why did I switch?

We did a selection and instead of going with some of the others, like TIBCO and whatnot, we went with IBM MQ.

How was the initial setup?

We've set it up in several ways. I had it for a year. Each original implementation was with Accenture and we've had several crews come in to manage the services. There are different SIs that come in like Tech Mahindra and HCL. Over 15 years we've had a lot of independents come in and support. 

We're just building on top of the existing platform now. But we've made a strategic decision to move away from this on-premise infrastructure, the data centers if possible.

We've got 4,000 employees, it's quite a sizeable business that we take on vendors to come in. We're not an IT shop. Different managed services from different vendors.

We don't consider users for the platform. It's more about what transactions. So I think it ranges from two and a half million to 10 million messages a day.

What other advice do I have?

My advice would be to rethink the cloud strategy. Make sure to have certain components that you can put into the cloud. Think about cloud-first properly so that it scales automatically. It knows how to work with some of the container services that are out there so that it scales better. It has some cloud components that are good but you still have quite a strong on-prem infrastructure to support it.

It's quite a complete solution. They have modules and stuff that they acquire and may add on as features and modules, additional modules, which is a very complete solution. It's been expensive to keep going the way we're going. And the turnaround is a bit slow, slower than we want. The business is changing quite rapidly, being in retail so we need to pivot quite quickly. And so that's why we're looking at seriously moving towards the cloud where we can simplify some of our processes and actually even our maintenance in it and the way we operate.

I would rate IBM MQ a seven out of ten.

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Prashant Powar
Senior Middleware Administrator at a tech services company with 501-1,000 employees
Real User
Top 10Leaderboard
A reliable and scalable solution that comes with advanced features and good support

Pros and Cons

  • "Currently, we are not using many advanced features. We are only using point-to-point MQ. I have previously used features like context-based authentication, SSL authentication, and high availability. These are good and pretty cool features. They make your business reliable. For critical business needs, everyone uses only IBM MQ. It is the first choice because of its reliability. There is a one-send-and-one-delivery feature. It also has a no-message-loss feature, and because of that, only IBM MQ is used in banking or financial sectors."
  • "It would be an advantage if they can include streaming in IBM MQ, similar to Kafka. Kafka is used mainly for streaming purposes. This feature is clearly lacking in IBM MQ. If they add this feature to IBM MQ, it will have an edge over other products."

What is our primary use case?

We are all using the file transfer or MQ FTP feature. We are also it for distributed queuing and clustering.

What is most valuable?

Currently, we are not using many advanced features. We are only using point-to-point MQ. I have previously used features like context-based authentication, SSL authentication, and high availability. These are good and pretty cool features. They make your business reliable.

For critical business needs, everyone uses only IBM MQ. It is the first choice because of its reliability. There is a one-send-and-one-delivery feature. It also has a no-message-loss feature, and because of that, only IBM MQ is used in banking or financial sectors.

What needs improvement?

It would be an advantage if they can include streaming in IBM MQ, similar to Kafka. Kafka is used mainly for streaming purposes. This feature is clearly lacking in IBM MQ. If they add this feature to IBM MQ, it will have an edge over other products.

For how long have I used the solution?

I have been working with IBM MQ for the last 14 years.

What do I think about the stability of the solution?

IBM MQ is a very stable product. You also get very good support from IBM, but we rarely have to go back to IBM for support.

What do I think about the scalability of the solution?

It has good scalability. We are using point-to-point or distributed MQ, so we are not that much worried about scalability. If we need scalability, we can use MQ clustering for a high workload. We can configure it for resiliency and high availability by using the multi-instance queue managers. If one of the nodes goes down, it will automatically failover to the other node. It also provides some advanced high availability features on top of the multi-instance queue manager.

How are customer service and technical support?

You get very good support from IBM. If you are facing any issues that are tricky or there is any code issue where FDC files are being generated and you're not sure what is happening, you can open a case with them. They will help you with that. They are very efficient.

How was the initial setup?

The initial setup is very simple. The installation doesn't take more than 15 or 20 minutes.

What about the implementation team?

I have installed it myself. I'm also doing maintenance, patching, upgrades, and migrations. We have a team of 11 administrators who are working on IBM MQ. They use it on a daily basis.

The upgrade process is simple. I refer to IBM Information Center. As a part of the preparation, I go through all the steps that they have given. I correlate the information with the infrastructure that we have. According to the current infrastructure, we document the requirements, and after that, we do the upgrade. We couldn't do in-place migration or upgrade, so we had to do parallelization. We took a new server, installed the new version, created a new queue manager, and migrated all the services.

What's my experience with pricing, setup cost, and licensing?

It is a licensed product. As compared to an open-source solution, such as RabbitMQ, it is obviously costly. If you're using IBM Message Broker, which is a licensed product, IBM MQ is included in the same license. You don't have to pay separately for IBM MQ. The license cost of IBM MQ is lesser than IBM Message Broker.

Which other solutions did I evaluate?

I have been asked to do a PoC for one of our use cases, and we used RabbitMQ for that. They wanted to assess RabbitMQ in comparison to IBM MQ.

Obviously, IBM MQ has more advantages when compared with RabbitMQ. The main reason for doing this PoC was that RabbitMQ is an open-source product. Cost-wise, it looks effective, but from a technical point of view as well as from the point of view of scalability and features, IBM MQ is very enriched.

What other advice do I have?

I would definitely recommend this solution, but it also depends on your needs and business case. I have been using IBM MQ for the last 14 years. I am very much used to it, and I like it. I have used other products too, such as RabbitMQ and Kafka, but not that much. 

I would rate IBM MQ an eight out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
VB
IT Development Manager at a financial services firm with 501-1,000 employees
Real User
Very stable with good integration capabilities and easy to work with

Pros and Cons

  • "The solution is very easy to work with."
  • "The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. It's one reason we are moving away from IBM."

What is our primary use case?

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly. 

What is most valuable?

The solution is very easy to work with.

The solution is very stable, it also offers transaction management and support.

The solution offers very good integration with other services. It's one of the great advantages of the service.

What needs improvement?

We have had it for a long time now - version 7.1, which is not the latest. 

The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.

The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.

IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

For how long have I used the solution?

We've been using the solution for a very long time. It's been at least a decade - about ten years.

What do I think about the stability of the solution?

The stability of the solution is good. We've never run into any issues.

What do I think about the scalability of the solution?

IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers. 

My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.

How are customer service and technical support?

I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.

Which solution did I use previously and why did I switch?

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

How was the initial setup?

While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.

In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.

In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.

What other advice do I have?

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Buyer's Guide
Download our free IBM MQ Report and get advice and tips from experienced pros sharing their opinions.