IBM MQ OverviewUNIXBusinessApplication

IBM MQ is the #1 ranked solution in top Business Activity Monitoring tools, #1 ranked solution in top Message Oriented Middleware (MOM) tools, and #2 ranked solution in top Message Queue Software. PeerSpot users give IBM MQ an average rating of 8.2 out of 10. IBM MQ is most commonly compared to Apache Kafka: IBM MQ vs Apache Kafka. IBM MQ is popular among the large enterprise segment, accounting for 78% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a financial services firm, accounting for 36% of all views.
IBM MQ Buyer's Guide

Download the IBM MQ Buyer's Guide including reviews and more. Updated: May 2023

What is IBM MQ?

    IBM MQ is a middleware product used to send or exchange messages across multiple platforms, including applications, systems, files, and services via MQs (messaging queues). This solution helps simplify the creation of business applications, and also makes them easier to maintain. IBM MQ is security-rich, has high performance, and provides a universal messaging backbone with robust connectivity. In addition, it also integrates easily with existing IT assets by using an SOA (service oriented architecture).

    IBM MQ can be deployed:

    • On-premises
    • In the cloud
    • Hybrid cloud

    IBM MQ supports the following APIs:

    • MQI (Message Queue Interface)
    • REST
    • .NET
    • MQTT
    • JMS
    • IBM MQ Light


    IBM MQ Features

    Some of the most powerful IBM MQ features include:

    • High availability
    • Stability and scalability
    • Flexible deployment options
    • Uniform clusters
    • Automated and intelligent workload balancing
    • Broad language, API, and messaging protocol support
    • Administrative features that simplify messaging management
    • Open standards development tools
    • Simple management tools

    IBM MQ Benefits

    Some of the benefits of using IBM MQ include:

    • Multi-style messaging: IBM MQ supports simple multi-style messaging, making it easy to connect diverse systems with support for message queuing, transactions, and more.

    • Reduced risk: With IBM MQ you will never lose a message, and messages are never delivered more than once.

    • Cloud-native: Because IBM MQ has a minimal infrastructure, it is suitable to be cloud-native, and therefore has the capability to always remain on.

    • Available anywhere: Using IBM MQ, you have access to secure messaging anywhere, at any time.

    • Secure: IBM MQ makes sure to keep your data safe by using TLS secured communications, providing access identity management, message-level security, and more measures to protect your information.

    • Easy for application programmers: To use IBM MQ, application programmers do not need to have any knowledge of communications programming.

    • Technical support: IBM MQ has a large user community and also provides support 24/7 as needed.

    Reviews from Real Users

    Below are some reviews and helpful feedback written by IBM MQ users who are currently using the solution.

    PeerSpot user Sunil S., a manager at a financial services firm, explains that they never lose messages are never lost in transit, mentioning that he can store messages and forward them as required: "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."

    Another PeerSpot reviewer, Luis L. who is a solutions director at Thesys Technologies, says that IBM MQ is a valuable solution and is "A stable and reliable software that offers good integration between different systems."

    The head of operations at a financial services firm notes that "I have found the solution to be very robust. It has a strong reputation, is easy to use, simple to configure in our enterprise software, and supports all the protocols that we use."

    In addition, a Software Engineer at a financial services firm praises the security benefits of it and states that “it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes."

IBM MQ was previously known as WebSphere MQ.

IBM MQ Customers

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

IBM MQ Video

IBM MQ Pricing Advice

What users are saying about IBM MQ pricing:
  • "Licensing for this software is on a yearly basis. The standard fee includes the maintenance and updates that are released periodically."
  • "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."
  • "I think it's pretty reasonable, but I'm not so too sure of the current pricing strategy from IBM. We use many bundled services, and most often, we go through a service provided by some other third-party implementation. So, I can't really give an honest opinion about that."
  • "The licensing fees are paid quarterly and they are expensive."
  • 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
    Solutions Director at Thesys Technologies
    Real User
    Top 20
    Reliable and stable software with good integration but the file transfer process needs improvement
    Pros and Cons
    • "A stable and reliable software that offers good integration between different systems."
    • "Sometimes, not all messages are consumed in the queues. File transfers need improvement."

    What is our primary use case?

    We're using the IBM MQ series in development, integration, UAT, and production areas.

    What is most valuable?

    What I found most valuable in this software is its reliability because messages that are sent into the queues are consumed by the other end of the connectivity. It has helped us maintain integration between two different systems, so that has been part of one of the layers of our architecture that communicates, for example, a back-end platform and back-end core system with a front-end platform. In our case, we are using the backend as a 224 banking system and the frontend we are using the Wall Street front office system. Those two systems are interconnected via the IBM MQ series.

    What needs improvement?

    An area for improvement for this software is that sometimes, messages are not consumed in the queues. We have seen queues where not all messages are emptied. That issue has been solved by our IBM team located in Spain, but we haven't received detailed technical information as to why those queues are not totally consumed. A probable reason could be some service and availability issue because of server updates in IBM MQ itself, or server updates related to the operating system, which in our case, we are using Red Hat Linux.

    I have seen a lot of problems with the file transfers, e.g. using FTP or SFTP or LFTP. Normally with all these kinds of transfers, they are not on a transaction boundary, meaning a transfer can fail during the execution. We are not certain why it hasn't reached the destination as these protocols are not transactional which you normally have in MQ messages. What I would like to see in the next release is a solution for the MQ file transfer. I saw some literature about it, but I am not sure if the feature is available, or if it will be easy to configure and maintain in the bank.

    For how long have I used the solution?

    We've used IBM MQ within the last year. We've being using it on a continuous basis because it is the secure platform we have in our banking system.

    Buyer's Guide
    IBM MQ
    May 2023
    Learn what your peers think about IBM MQ. Get advice and tips from experienced pros sharing their opinions. Updated: May 2023.
    710,326 professionals have used our research since 2012.

    What do I think about the stability of the solution?

    IBM MQ is very stable. It's the best server in terms of interconnectivity. The reliability that the MQ series has, I haven't seen in other servers that are also based in MQ.

    What do I think about the scalability of the solution?

    My impression of the scalability of this software: We started with a very easy installation where we have very few queues defined. Then, we had a huge integration where we applied, pulled, and observed that the scalability is very straightforward. We also found an easy way: making an active-passive configuration automatic. For example: If you have one active server going down, the passive server is switched on automatically, without us needing to do anything from our end, which means the active-passive configuration works properly.

    How are customer service and support?

    I haven't been involved in contacting IBM's support, but in general, we didn't have any vendor issues.

    How was the initial setup?

    The setup for this software was very complex, particularly with the integration between the two systems I was talking about earlier: on the core backend and on the user frontend that is the Wall Street system. It has a lot of different types of flows, and all those flows are defined into the server that is called TTI that is working under the MQ series. That contains a lot of complexities because the vendor of the front-end system has included in the MQ side the server functionality for the application, instead of doing it directly in either the backend or the frontend. This means the MQ part is also helping with the logic for processing messages, and the logic is maintained in a layer: the MQ layer in the server that's called TTI. This is the first time we have faced such complexity, but regarding the MQ as is, meaning the vanilla version, it is quite straightforward. That server works the proper way.

    What about the implementation team?

    We used consultants for the implementation and those were consultants from the vendor who were already experienced in the TTI server.

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

    The licensing for this software is on a yearly basis, but the bank is holding just one license for the entire bank: a corporate license. As for additional costs, it's a standard fee that includes the maintenance and updates that are released periodically.

    What other advice do I have?

    I didn't download Active MQ and IBM MQ. I was checking on the website because I wanted to know certain functionalities about those two series. So what I downloaded was the literature about their functionalities.

    Regarding IBM products, the only one that I was working with was the MQ series.

    All products in our organization, particularly the banking systems are on-premise. We are not yet ready to do cloud deployment.

    Deployment of this software in the TTI part took three months. For the core part, deployment took approximately one month. The time that it took for deployment is also associated with the number of servers that we had.

    We have four groups: development, integration, user acceptance test, and production. In each of these groups, they have their own MQ servers. We started with the installation for the development group, then going forward and solving the issues we found at the beginning with the installation instructions. We continued with the other areas until we reached the production server recently, back in mid-October.

    We currently have 200 users of this software.

    Deployment of the IBM MQ at core requires two people in our organization, but for the personalized application or the customized one, we have 10 people.

    I'm rating this software a five because it is quite expensive and complex. I'm giving this a five over ten rating not just because it runs, but because it has a lot of features.

    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.
    PeerSpot user
    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
    PeerSpot user
    Buyer's Guide
    IBM MQ
    May 2023
    Learn what your peers think about IBM MQ. Get advice and tips from experienced pros sharing their opinions. Updated: May 2023.
    710,326 professionals have used our research since 2012.
    Integration Lead at a financial services firm with 10,001+ employees
    Real User
    Top 5
    Robust, reliable, and has good documentation
    Pros and Cons
    • "I haven't seen any issues with respect to the message loss."
    • "While there is support for API, it's not like the modern API capabilities."

    What is our primary use case?

    We use it as our enterprise messaging bus, not from the transformation use cases. It's mainly from the messaging use cases only. We use it for connecting to mainframes predominantly.

    How has it helped my organization?

    It was the main messaging bus for us for a very long time. Therefore, we have applications connecting, and even some of the modern applications are still using MQ. From a company's productivity perspective, we see a lot of benefits. It's all point-to-point connectivity. For any point-to-point messaging needs, MQ is very good.

    What is most valuable?

    The reliability is great. You will not see a case of a message loss in IBM MQ unless there's a queue full or there's some issue with the capacity of the queue. I haven't seen any issues with respect to the message loss. That's the main thing I like about MQ.

    It's very robust.

    It's a stable product.

    Support is helpful and there is lots of good documentation available. 

    The solution can potentially scale. 

    What needs improvement?

    While there is support for API, it's not like the modern API capabilities. If you want to automate the creation of queues and topics, IBM provides command-line utilities. It does provide API capability; it's just not that complete.

    They should make CI/CD available. There is no CI/CD support from the product. Maybe MQ should think about the modern way to handle deep-based development. 

    For how long have I used the solution?

    As a user, I have about eight to nine users of experience with this solution. 

    What do I think about the stability of the solution?

    Stability-wise, we have no problems. It's very stable. 

    What do I think about the scalability of the solution?

    Scalability-wise, in terms of the implementations that we have currently, it's not quite scalable. The implementations that we had were more active-passive kind of implementations up until now. There are product features that came up that allow it to scale. We understand it is scalable. However, we still need to explore it. There's a new HA capability that has come from IBM, which is a cloud-native replica set way of doing it. It's possible, it's just more difficult how we have it arranged.

    We have a user base of millions and maybe 50 to 100 developers working on the solution. 

    With MQ, we are trying to reduce usage since we have better products to support JMS. Most of the applications are Java-based applications, which have native support for JMS. We only use MQ right now for mainframe use cases. For all the other messaging use cases, we use Solace.

    How are customer service and support?

    Technical support is quite good. They are some of the best. They are responsive.

    Since we've used IBM for a very long time, we need to rely on them less. Most issues can be dealt with by looking at the documentation, which is available online. You often do not even have to reach out to support. That said, if you do, they are great.

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

    We did not previously use a different solution. 

    How was the initial setup?

    From an implementation perspective, it was hard for the features that we were using. However, recently, it has become quite easy to implement.

    The setup team is a bigger team due to the size of MQ in the company, which is quite huge. We have around 200 managers and the size of the team is around 20 members and they can all assist with deployment tasks.

    What about the implementation team?

    The initial setup is done by our deployment team. In fact, I currently work in pipeline development for MQ, so it's easy to implement.

    What was our ROI?

    Returns are quite good for the amount that you pay, since, with IBM products, you see fewer bugs.

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

    I don't have any information related to licensing costs. 

    We likely have an enterprise license, based on the size of infra that we have. My understanding is it is not very expensive. However, for a new company, it may be pricier.

    We get everything in a bundle. There are no extra costs involved. 

    Which other solutions did I evaluate?

    I didn't look into other options. When I arrived at the company, MQ was already there. They've used it for even longer than I have - for maybe 15 years. 

    What other advice do I have?

    We are customers and end-users.

    We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises. 

    If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However,  it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities.

    I'd rate the solution nine 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.
    Flag as inappropriate
    PeerSpot user
    Software Engineer at a financial services firm with 10,001+ employees
    Real User
    Top 20
    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.
    PeerSpot user
    Manjunath-V - PeerSpot reviewer
    Senior Member Of Technical Staff at Tata Consultancy Services
    Real User
    Top 5Leaderboard
    Reliable with message transformation and an easy setup
    Pros and Cons
    • "The initial setup is easy."
    • "The GUI part could be better."

    What is most valuable?

    I haven't used 100% of the IBM product. That said, the message transformation is very good. My application may not always be running, yet even if it is off, whenever I stick on my applications, I get all the messages that I'm supposed to get. Also, the sending functionality of the application may not always be on. I can keep sending the message, and they will get my messages when their applications turn on.

    The initial setup is easy.

    What needs improvement?

    The GUI part could be better. The command line part is fine if the person knows the commands. However, we started using it on the GUI. It needs more direction, and it needs to be easier to understand. If the connectivity is not happening between the receiver and sender, it would be ideal to have some kind of a GUI that helps me to find the issue. Right now, whenever the connection is not happening, I use the debug a lot, and I use it to see configurations. I'd rather just have a message in the GUI that can say, for example, "The port is not enabled. The port is wrong." 

    I used to get an issue with the connection. Maybe the configurations are perfect. However, the issue is on the other side, where maybe the component is down. I will only come to know that when I ping or ask the other person. Instead of that step, if there was a GUI that would tell me exactly what the issue is would make troubleshooting clear.

    In general, they need better visibility and not just the GUI design side. They need something that elaborates to the customer or user where the issue is. 

    Technical support needs to be faster and more knowledgeable. 

    For how long have I used the solution?

    I've been using the solution for more than four years. 

    What do I think about the stability of the solution?

    Product-wise, there is no problem with the stability.

    That said, when there are a lot of messages, I may need to increase the bandwidth or the queue size. If I have to increase the queue size, maybe I can increase it to even a million, however, in the down sessions, when I extract the transaction, it takes a lot of time. When I want to see what information is inside the queue when I extract it, it takes much more time, which could be looked into. It might be a performance issue or something. It might not happen every time. Whenever there is an issue with a large set of transactions, for example, if, in a minute, you get a lot of transactions, we might have an issue. Still, it rarely happens. 

    What do I think about the scalability of the solution?

    We have had a limited number of users. We haven't tried scaling since we are rather small. There are very limited users. 

    How are customer service and support?

    I have raised a couple of tickets with IBM support. The one thing I say is, all the support members are not always knowledgeable. I need a very senior person when I need something. Whenever I log a ticket, there will be one person who will not have the information to help, and I need to escalate. Every time I have to push and ask for somebody more senior, only I can get help.

    What is expected is, as soon as we give some logs or share some issues, that we get a person to help immediately. However, that's not the case. It takes too long. 

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

    I have not worked with other products. 

    How was the initial setup?

    In terms of the initial setup, we never faced any problems. It's quite easy. Even the cloning and queue managers are really good. 

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

    I'm not involved on the licensing side. 

    Which other solutions did I evaluate?

    I have only really been into IBM MQ. It's a good product at the moment. I didn't get an opportunity to look into or work with other products.

    What other advice do I have?

    We're IBM partners. 

    So far, I am satisfied. I'd rate the solution eight out of ten. 

    I'd recommend the solution to others. 

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
    Flag as inappropriate
    PeerSpot user
    Enterprise Architect at a energy/utilities company with 501-1,000 employees
    Real User
    Versatile, easy to implement, and good at doing what it does
    Pros and Cons
    • "The methodology and the way in which the platform has been produced as a standard is most valuable. There are so many different versions of it now, but the actual basic functionality and the simplicity of it have made it far easier to be implemented in so many different instances. When I worked with the OS/2 or PS/2 machine environment, the messaging mechanisms were based upon IBM MQ. It is so versatile, which is the main reason that I'm a fan of it."
    • "There are things within the actual product itself that can be improved, such as limitations on message length, size, etc. There is no standardized message length outside of IBM. Each of the implementations of the MQ series or support of that functionality varies between various suppliers, and because of that, it is very difficult to move from one to the other. We have IBM MQ, but we couldn't use it because the platform that was speaking to MQ didn't support the message length that was standard within IBM MQ. So, we had to use a different product to do exactly the same thing. So, perhaps, there could be more flexibility in the standards around the message queue. If we had been able to increase the message queue size within the IBM MQ implementation, we wouldn't have had to go over to another competing product because the system that was using MQ messaging required the ability to hold messages that were far larger than the IBM MQ standard. So, there could be a bit more flexibility in the structuring. It has as such nothing to do with the IBM implementation of MQ. It is just that the standard that is being put out onto the market doesn't actually stipulate those types of things."

    What is most valuable?

    The methodology and the way in which the platform has been produced as a standard is most valuable. There are so many different versions of it now, but the actual basic functionality and the simplicity of it have made it far easier to be implemented in so many different instances. When I worked with the OS/2 or PS/2 machine environment, the messaging mechanisms were based upon IBM MQ. It is so versatile, which is the main reason that I'm a fan of it. 

    What needs improvement?

    There are things within the actual product itself that can be improved, such as limitations on message length, size, etc. There is no standardized message length outside of IBM. Each of the implementations of the MQ series or support of that functionality varies between various suppliers, and because of that, it is very difficult to move from one to the other. We have IBM MQ, but we couldn't use it because the platform that was speaking to MQ didn't support the message length that was standard within IBM MQ. So, we had to use a different product to do exactly the same thing. So, perhaps, there could be more flexibility in the standards around the message queue. If we had been able to increase the message queue size within the IBM MQ implementation, we wouldn't have had to go over to another competing product because the system that was using MQ messaging required the ability to hold messages that were far larger than the IBM MQ standard. So, there could be a bit more flexibility in the structuring. It has as such nothing to do with the IBM implementation of MQ. It is just that the standard that is being put out onto the market doesn't actually stipulate those types of things. As a result, rather than following the recommendations and the standard that was within the IBM MQ implementation, some suppliers say that we need the ability to have longer message lengths than they've implemented, but that's the way it is. Other than that, I'm very pleased with it as it is. It is good at doing what it does. I love the actual implementation, and I've used it a lot.

    For how long have I used the solution?

    I've been using IBM MQ since it came along. We've got a lot of different platforms. We have IBM MQ. We have had BizTalk, IMMQ, WebSphere, and WebLogic platforms, but we're moving very much into the cloud.

    How are customer service and support?

    The support that we have goes through third-party vendors. In the past, their support has been very good, but I can't say anything about it today. About 15 years ago, in the companies I was working with as a consultant, we had very good support. We were working very closely with IBM, and IBM implemented the PS/2 and OS/2 operating system together with Microsoft. The implementation there in terms of the connectivity was an implementation of the IBM MQ series in the OS/2 operating system, PS/2 environment. The support we received for that work back in the late '80s was fantastic.

    How was the initial setup?

    The initial setup is usually left to other people to do. I've never actually done the installation and setup of it myself. It has been other people with a bit more deep technical knowledge who have done the implementation and actual installations. It was a very long time ago when I received the first set of CDs where we were going to be doing the installation of it, but I don't have that deep technical knowledge of the implementation as such.

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

    I think it's pretty reasonable, but I'm not so too sure of the current pricing strategy from IBM. We use many bundled services, and most often, we go through a service provided by some other third-party implementation. So, I can't really give an honest opinion about that.

    What other advice do I have?

    I would rate IBM MQ an eight out of 10.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Lead Talent Acquisition Specialist at a tech services company with 1,001-5,000 employees
    Real User
    Top 20
    Simple to deploy, low maintenance, and technical support is always reachable
    Pros and Cons
    • "This initial setup is not complex at all. Deploying it was very easy."
    • "The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization."

    What is our primary use case?

    Our use cases for IBM MQ involve share markets.

    In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

    What is most valuable?

    The MQ appliance has very good performance.

    What needs improvement?

    The user interface should be easier to use.

    The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

    In general, the user interface should be more catchy, to entice users.

    IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

    If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

    For how long have I used the solution?

    I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

    What do I think about the stability of the solution?

    The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

    What do I think about the scalability of the solution?

    The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

    In my previous organization, our use was more extensive. We had between 700 and 710 users.

    This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

    How are customer service and support?

    The technical support from IBM is always reachable.

    Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

    How was the initial setup?

    This initial setup is not complex at all. Deploying it was very easy.

    What about the implementation team?

    Limited staff is required to maintain this solution because of its stability.

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

    The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

    Which other solutions did I evaluate?

    I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

    If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

    IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

    What other advice do I have?

    Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

    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.
    PeerSpot user
    Manoj Satpathy - PeerSpot reviewer
    Assistant consultant at Vvolve Management Consultants
    Real User
    Top 5
    Good publish and subscribe features but needs a front-end monitoring tool
    Pros and Cons
    • "Technical support is quite helpful."
    • "If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great."

    What is our primary use case?

    There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

    What is most valuable?

    The publish and subscribe features are the most useful aspects of the solution.

    It's not too difficult to set up the solution. 

    It's stable.

    Technical support is quite helpful. 

    The moment you send the data, there is no latency there.

    We haven't experienced any data loss. 

    What needs improvement?

    If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great. While you may not be able to edit your messages, at least if you could look at them, see the queue, and what's inside, et cetera, that would be helpful. We'd like visibility on the health of the environment. 

    For how long have I used the solution?

    I've used the solution for two years. 

    What do I think about the stability of the solution?

    The stability is good. In fact, we have not seen any issues. Only recently have we observed an issue. There was a limit on the number of messages it could contain. We are having an issue now, however, we have not usually seen any issues related to IBM MQ. Therefore, in general, the solution is stable. I'd rate its reliability eight out of ten. 

    What do I think about the scalability of the solution?

    I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

    We handle about 300 to 400 transactions per day. 

    How are customer service and support?

    Technical support is very helpful and responsive. We are satisfied with the level of support we get. 

    How would you rate customer service and support?

    Positive

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

    I have previously used TIBCO EMS as well. 

    How was the initial setup?

    The initial setup is pretty easy. It's not that complex. I'd rate the ease of implementation at a seven or eight out of ten.

    The deployment time is pretty short. It's not a long process. 

    In an integration scenario, like payment processing, where the payment has to go to the backend system, SAP, or talk to multiple applications, due to the fact that it's a lengthy, complex business process, we just decouple it. Some of the information we get immediately after receiving the request, and we pass on the information to the customer. Then, we put the payload into the IBM MQ, and then we started processing from IBM MQ. So there are integrations that sometimes need to be done or worked with. 

    What about the implementation team?

    We have an admin team that does the configuration and setup of the solution. They can do it in one or two business days. 

    What was our ROI?

    We have witnessed an ROI while using this product. For example, we've had no data loss since using the solution

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

    A different team handles the setup, and likely they also handle the licensing. I don't have any visibility on the cost of the product. 

    What other advice do I have?

    I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

    I'd recommend the solution to others. I'd rate it seven out of ten overall. 

    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.
    Flag as inappropriate
    PeerSpot user
    Buyer's Guide
    Download our free IBM MQ Report and get advice and tips from experienced pros sharing their opinions.
    Updated: May 2023
    Buyer's Guide
    Download our free IBM MQ Report and get advice and tips from experienced pros sharing their opinions.