IBM MQ Reviews

Basically 100% message delivery and how easy it is to integrate the system to another system / .NET / Java applications are the most valuable features. It provides 100% guaranteed message delivery, so you won't lose any messages, even in the event of a MQ failure.

The benefit is that we are in an industry where we cannot lose any piece of data, so MQ gives that reliability. In terms of security, like I mentioned preciously, you won't loose any of the transactions at all, even if you have a failure. It's very important to us, especially the FIFO feature (first-in, first-out) and that kind of persistent messaging. We have a billing system where whatever messages drop first need to be consumed first. Thus, these features are really good. It helps us flowing all the MQ messages.

One of the bottlenecks for us is owing to the industry that we're in, we sometimes get the large payloads and the MQ queues that we can increase. But, the maximum payload size allowed is only 100 Mbps. So, I wish to see if it bumps up because sometimes we hit that ceiling and the message won't process. We have to find another way to mitigate one or two instances like that. It's critical, so I don't know if there are any future plans to increase that size to unlimited or at least where you can set it based on your business model, i.e., if your payload is higher, then you can set it higher.

It's pretty stable. We did not experience any downtime. Probably, there's no other product out there like MQ for messaging. It's the most reliable solution. We had our MQ running in production for almost 800-900 days without any issues, i.e., for more than three years, we didn't even have to restart, and still everything runs so smoothly.

It's fully scalable. You can add as many queue managers or queues in there, so it's pretty flexible in terms of scalability.

I have used the technical support around one or two times, but not that much. I did have some meetings scheduled with the architecture guys at a recent IBM conference. I am quite happy with the support that I have received.

We were not using any other solution previously. From the beginning, we implemented it. We always look up to IBM software. We have so many IBM shops with products such as the IBM AIX Servers, WebSphere Servers, WebSphere Liberty, IBM Integration Bus, IBM InfoSphere MDM Reference Data Management, IBM PA and IDMP. We have lots and lots of IBM products, including the WebSphere Portal and WebSphere Commerce, so we got a lot of things from IBM.

It's a good solution and you should go for it!

When selecting a vendor, mainly the support part is very important, especially when something goes wrong in production; you don't want to leave the system down. This could cost the customer a lot of money, so having that level of support is important. Sometimes, we run into an issue where the support is not able to help, then we always reach out to our self-service representatives. After which, the ticket gets escalated and addressed pretty quickly, so that's the kind of attention required.

We develop applications for 20 companies in the insurance industry. We have about 20 different product systems that use the same MQ layout. 

We are also using it for testing and educational purposes.

Our customer base is in the closed market of Switzerland and Liechtenstein.

We just switched versions from 8.0.0.6 to 9.1.

Most European companies have MQ, though we just added it four years ago. MQ changes the way people think about their applications. E.g., they are more integrated. We see synergies with the tool, but there is a long path to changing people’s minds.

The MQ layout is quite easy.

It is very stable. We don't have many issues.

We have had an issue with the migration. Most of our applications are running on Java and WebSphere. We have a project to get rid of an old .NET application since we are experiencing a loss in connection during the migration to 9.1. The problem appears to be more on the .NET side than the MQ side though.

The technical user interface is outdated in terms of the language used. I think this is inherited from the mainframe. This is more of an engineering issue. It is running on a Windows platform, and I don't like having Windows being the backbone of our company.

I don’t like legacy view of MQ.

Four years.

We don't have a problem with stability.

We have not had any large scalability issues. The business that we have is not that big. In Switzerland, we have around 3,000 people working with all our systems. We don't have that many transactions. For our 20 customers, we have four servers in production with two on standby and two that are active. We need scalability mostly to run large printing jobs for MQ, where we need disk space. Overall, we don't have any scalability issues.

This solution has improved and influenced the communication between different applications, then standardized that communication. Before, we had a lot of different interfaces, which were partly handwritten. Now, we have two or three manned technology with MQ that are automated. Therefore, we are focusing and reducing the amount of technology.

For some special parts, we also had something previously in place. We ran around 100 to 1000 PDFs in a batch mode.

We have a standardized way in describing our servers, services and rights because we have our own infrastructure. We just generate the MQSC scripts, then push it to the right server.

The time it takes to deliver a new integration varies. From our point of view, we are really fast, but we do not develop applications on our own. We are a type of project management and system provider company. This means that most applications are written by different companies. E.g., we have IBM as a software supplier.

Two people from our company maintain the solution along with a consulting company that we have. All this is done part-time.

Our costs haven't increased but they also have not improved.

We are happy with it. I would give it an eight (out of 10). 

We are not using containers.

One of the most important features is data persistence. Anytime there is a failure or an unexpected outage, the data is still there. That is one of the biggest benefits of MQ on WebSphere.

One of the things we did not see meeting our need was the lack of integrated monitoring for both IIB flows and MQ's. You have to use different tools for that, i.e. - MQ Explorer for the queues and IIB toolkit/web viewer for IIB apps and flows. If we could integrate the monitoring of both the flows and the queues in one product, that would be great.

Similarly to deploy the flows we need to use IIB toolkit and then to run MQ Scripts – we need to use a different tool. Since IIB and MQ goes hand in hand – it would be nice if the tools were integrated as well.

3 years.

The stability is pretty good, so far. We had some challenges with some of the clustering during initial setup. But once that was done properly, it was quite stable.

That's one of the shining features of MQ, that scalability. It is very scalable.

Technical support is good.

This is something that I inherited. There was a legacy system that was already using MQ.

There are a lot of things that MQ can do, so the configuration setup needs some involvement.

Engage IBM and MQ experts from the beginning on the architecting and the proof-of-concept. There are a lot of configurations and a lot of things that IIB can do. If you do not do properly early on, then it's going to be difficult to find those things, go back, and make those changes.

One of the most important things when selecting a vendor is definitely their ability to meet our functional needs. On top of that, we are looking for partners that are going to be around in 10 years, 20 years, 30 years. We want dependability, longevity, and somebody who's going to be around when we need them.

The most valuable feature is the fact that it's guaranteed delivery; it's conversational. A lot of our transactions are basically transactions back and forth between either rewards members, reservations and even between our databases. MQ gives us guaranteed delivery.

We're an IBM mainframe user. It folds into our hardware very well. Our support is covered that way. It's kind of an end-to-end type solution. It works well with the distributed partners. We use WebSphere, so we can go ahead, plug things in and they work.

They might be able to improve the monitoring features. When you're looking at distributed platforms, you're looking at different breakpoints to it. MQ has a good support structure, but it would be nice if they could kind of fold MQ into other tools to make it more resilient for other tools, other relationships, and other non-IBM platforms.

That's probably the strongest piece: being able to support the other customers. Eventually, if we can support them end-to-end and tell them where their problems are, we can bring them into our fold and make it an IBM fold.

Stability is unrivaled. We've got no problems with it. It's like the mainframes. When you're looking at five nines for availability, it's there all the time. MQ is there all the time. If we have a problem, it's not part of the conversation. It's more of a case of a database on the other end that we're using as a repository is having a problem. You can go out there, store the messages, and guarantee delivery if there are any interruptions. It just works for us.

It's plug and play. If you need more, you can figure it out on the fly; you can add end points to it. The fact that you can add connections makes it very easy for us, because a lot of times we'll run into an issue where we get spikes in connectivity. We can go ahead and define something on the fly. We can go ahead and throw in the extra conversation, and queues aren't a problem at either end. The fact that we can reduce queues by adding extra channels is a great plus for us.

We have only rarely used technical support, because you don't really need it. When we have used it, it's been very good. The SLAs and everything that we've got for tech support is being met. We've also been using it long enough that we've got some very solid support, as far as, we know who to talk to and when to talk to. It's been great for us.

I was not really involved in the initial setup. I was probably around for it, but I had an applications background. I went from the systems side to the applications side, and back to the systems side. It was kind of the interim period. I'm not really responsible for the MQ right now. I'm more of a user of MQ and a supporting group. As a mainframe user, we basically have that relationship with them.

It's actually not a decision to use MQ, but maybe to expand MQ in some cases. It also is one of those places where you can't really go wrong by saying, “We're going to use MQ,” because it's proven.

The most important criteria for me when selecting a vendor to work with is probably stability. Relationships are important, but we're looking at up time. The better the up time is, the stronger we are, the better our product is, the better we are in front of customers. It used to be, when you were basically just facing other employees in the company, that's one experience. Now that you're facing the user with the dot-com boom, the world out there, everybody's on the end of a phone, our transaction counts have gone up exponentially. To have that relationship, and to have MQ being able to service what they service and support that expansion has been fantastic.

Consider the pros and cons. For us, it’s reliability; it’s stability; it’s reputation. Do not get hung up on the fact that it is one of those "legacy"-type connectivities. A lot of people might not want to look at MQ, look at IBM or look at something because “that's the old way of doing things.” It's the current way of doing things. It's a leading-edge way of doing things, and the fact that it's there 100% of the time.

I'm not sure anybody’s perfect. They're very good at what they do. If they can play well with others, that's the real part of it right now. We're using WebSphere; we're using the mainframe; we're using the distributed side. As long as they can play with everybody, they're going to be a strong player. We'll be a strong proponent for them.

MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.

The system integration is good. 

The pricing needs improvement. 

I have been using IBM MQ for six years. 

The scalability is a nine out of ten. 

The initial setup is complex. 

Overall, I would rate it an eight out of ten. 

IBM MQ is the standard for financial industry messaging. As far as I know, it is the best in class.

The most valuable feature of IBM MQ is it has all the features necessary for contemporary messaging, not only for the financial industry but for any application.

IBM MQ has developed into some newer solutions. It has a message broker, it is now on the cloud, it has containerization, that has high availability features

IBM MQ may not be as convenient for Java programmers as Active MQ, for example, because Java programmers prefer Java, even though it is slower.

IBM MQ could improve by adding more protocols or APIs for a standard application, such as MuleSoft.

I have been using IBM MQ for approximately 15 years.

IBM MQ is stable, performs well, and is highly reliable. They guarantee message delivery.

The scalability of IBM MQ is good. There are cluster, container, and broker features available. It scales well horizontally and vertically.

Most of our company is using IBM MQ in my company.

The support from IBM MQ is good. They have always helped with my problems, but sometimes it can take them a while for a resolution. Sometimes you might find a bug in a one-year span of using the solution, but they will provide a fix within a matter of weeks.

Positive

The initial setup of IBM MQ can be straightforward if you have the documentation, it is step-by-step and straightforward.

IBM MQ is an expensive solution compared to other solutions. However, if you pay less you will not receive the same experience or features.

It may not have all the APIs, features, or protocols that the newest systems have, but in performance and reliability, it is the best.

The amount of people needed to maintain the solution depends on the company and how they want to maintain it. When I was working for a bank I supported 300 MQ managers with approximately 150 systems running. However, for the basic use of the solution, you do not need many people. If you add more features, such as broker and clustering you will need more people for maintenance.

My advice to others is this solution is the best there is. For maintenance, you will probably need fewer people to maintain it than other solutions because of its reliability. The features are probably the most extensive in its class.

I rate IBM MQ a ten out of ten.

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

All the features are valuable.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

I have been using the solution for ten to fifteen years.

The solution is rock-solid and stable. 

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Customer support is good but there is room for improvement in their process. Their support is 24 hours so if you are dealing with support in the U.S. and it is passed over to a support person in the UK for example the person in the UK will not be provided with a detailed log of what has transpired. A lot of time is wasted waiting for them to catch up by reviewing the information each time the case is passed to a support person in a different country.

Neutral

If it is a standalone implementation, it is straightforward. If the implementation is the higher availability mode, XM mode, it becomes a complicated process because it comes with a shared disk resource where one instance goes down, and another instance comes up. This means it can not always be an Active mode, you require an Active-Passive mode all the time. This can increase the setup cost and complexity.

Implementation was done in-house and it took a couple of hours.

Within the first two years, you will see the initial cost returned. 

The fee for this solution is on the higher end of the scale. The licensing fee is high.

I rate the solution nine out of ten.

We currently use the solution with 30 to 40 applications across the organization. It requires four to five people to maintain the solution including engineers, application support, an architect, and integration engineers.

For all the cases where IBM MQ is no longer required, we are migrating to a different solution (Kafka). 

The solution requires a lot of work to implement and maintain. I would suggest looking at other more modern solutions depending on what your organization requires.

We have various strips statements, and we use IBM MQ to pass those strips statements to different systems within our organization.

Encryption and the fact that we have not had any data loss issues so far have been very valuable features. IBM MQ is well encrypted so that we are well within our compliance and regulatory requirements, so that is a plus point as well.

I would like to see their cloud feasibility with other vendors. I know that they are very much tied to their own cloud right now, but I don't know how they are supporting AWS and Azure.

With IBM products, there's less marketing. If they do more demos and more seminars on their products, it will be very useful. On a given day. I get seminar invites for many vendors and products, but for IBM, I may get an invite once or twice a year.

Documentation is easily available to people who know about IBM products. However, if you're not familiar with the products and because there are no popups about seminars and product news, you will not be able to easily find the documentation. So, I think that there's a gap in IBM's marketing, which needs to be improved.

It's been a pretty reliable and well structured solution so far.

It's very good and scalable. Currently, we use it within the EMEA and APAC regions, and we have a few regions in the Middle East as well. We haven't had any issues so far in terms of scalability because we started with APAC. Usually, we start with only London and then slowly start extending to Europe and APAC regions. So, it's scalable because we started with one region, and now, we already have four or five regions.

We have a middleware team of 45 to 50 people in APAC and EMEA who use IBM MQ, but the usage is not limited to the team. We have users across all our venous functions everywhere because this is for backend transmissions connectivity. We use Message Queue everywhere.

At the moment, there are no plans to increase usage, but I think we'll soon be looking to do so. By the first quarter of 2022, we will be moving most applications to the cloud. We know that IBM MQ is very well supported in the cloud and that it will be easier. Right now, our infrastructure is very much on-premise dependent, and we have some legacy dependencies there. So to get to the cloud for us is a big journey, and once we are at that stage, then we'll be able to look into increasing usage.

We setup IBM MQ about four or five years back. I think the setup now would be much easier than the one we did then.

IBM MQ was the first product that I got introduced to when I started my journey with IBM. This is my 14th year in this industry, and I see that this application is still very much useful and applicable. So I always recommend IBM MQ, and this is one of the most popular IBM products.

I would rate it at seven on a scale from one to ten.