IBM MQ Reviews

It allows more people to be able to support the application. They have training and we get folks to actually go in and bounce services and update services through IBM MQ because it is graphical. It's fairly intuitive on what's there. It enables us to have better and deeper support as an organization.

What I like about IBM MQ is that the ability to add applications to it is quite simple. There are a lot of extensible options for security, i.e., various things you can do. It's pretty easy to navigate. It's pretty easy to install and use from that perspective. Those are the things that I really like about it. It's our web hosting application of choice over using something like Tomcat or whatever because you can click through it, you can see things, and it's a lot easier from an administrative standpoint.

I think one of the things to improve on could be more administrative profiles which might simplify the experience. IBM MQ has a lot of settings. We're only using probably a fraction, maybe 10%, of the overall settings. Working for a large aerospace/defense firm, we have pretty tight security. There are a lot of settings that we do have but we're still only just scraping the surface of what's there. Being able to get to those sub-menus can be a bit challenging.

So there's the fact that there's a lot in IBM MQ presenting only the options that maybe somebody might do, such as a web application administrator might have to do. They don't need to see all the other bindings that are there, so it could be a little overwhelming trying to find it. So, I think if there's anything, that would probably be it.

Presenting and maybe having some different options for different user experiences based on the administrative duties that you have to do as an app manager or configure the server or security would be an improvement. For instance, in our information insurance organization, we have folks that go in and look at the security bindings that we have with our applications. Having those different roles mapped would be an asset, so you're not having to go through all the various sub-menus to find it would be something that would, I think, take it over the edge.

Stability is really good, actually. We haven't had any issues with IBM MQ .

We haven't had any issues adding applications to it and scaling up from it. So all in all, I think it's been fantastic.

I would say that technical support is average. Obviously, we are going through their PMR system. They are such a large company. I think the availability of somebody on the phone or calling somebody when you need something fixed immediately is a bit challenging for the organization. I think that's an area that they can improve on.

If we have IBM MQ or one of the applications go down, our entire plant is down. Then sometimes, it's 2-3 hours or something before someone calls us back. It would be nice if we can call somebody and have somebody you can actually work with that is knowledgeable on the product right away. That's my only gripe.

For a lot of other things, like lower priority items, working through the PMR system's been fine. I think their system is good. I just think that they need to be a little bit more responsive to their severity one tickets.

Initial setup was pretty straightforward. The more complicated part of it was the actual IBM CLM tools implemented within IBM MQ. IBM MQ itself was pretty simple.

I've heard that there have been challenges with upgrades, but we haven't gone through an upgrade cycle yet, at least in quite some time. We'll see how well that is but we haven't had that challenge yet.

We didn't evaluate any other products beforehand. It was just what IBM recommended.

Typically, what we'll do is, we'll go with the vendor recommendations because from a support perspective, if they're saying that because they support an application, we prefer to do go with that one because we know we can get the support as it goes on. That's really it.

Access to support is the most important criteria for me when assessing vendors. I think support is a key for us being in IT because we are supporting the application, so we need good support.

The second one is the ability to reach the developers on key issues and improvements that we would want to see in future versions of the application. Being able to influence the roadmap, I guess you could say. That would probably be the second thing we care about.

There are a lot of vendors that don't take that seriously. Like, you go in and you might have great features that would really broaden their product base, adoption of their tools. Some want to hear it; some don't. I think the ones that do hear that end up being more successful; they find ways to work that information back into their development stream.

That's probably the second most important criteria but, again, being in IT, I'm looking out for myself a little bit there. Support is number one.

I don't think I'd give anyone any advice at all. It's pretty straightforward to go and implement. The only thing that I would say is that perhaps if you're - depending on what you need to do - like deploying some of the IBM CLM tools, you might look maybe for a lighter-weight solution because of those various menus.

I know there are other IBM products and there are various lighter-weight solutions that are provided as part of the IBM MQ family. Going with something that's not full IBM MQ but maybe one of the other IBM products that's much more suitable for your organizational needs would be a good choice.

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

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

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

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

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

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

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

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

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

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.