IBM MQ Reviews

We are currently working on the use case. I work as an IBM system admin and part of MQ is hosted on the IBM server. We have a lot of other servers and appliances for IBM MQ that costs us a lot of money so we are currently looking for less expensive alternatives. Kafka is one of the choices on the table. We are looking to migrate to services on Google which is why Kafka was proposed for us to implement. 

We use it to integrate the backend and front end solutions and applications. 

The most valuable feature is the stability. It's perfect in this way. 

We are looking for another solution that is less expensive.

There is room for improvement. The live and portal monitoring needs improvement. 

I have been using IBM MQ for four years. 

It's very stable. 

It's scalable. 

I would rate their technical support an eight out of ten.

The initial setup was average. Not so complex and not so straightforward. 

The deployment itself, not including testing, took a couple of hours. 

It's expandable but it will add costs that should be taken into consideration. 

I would rate it an eight out of ten. 

In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers. 

We use it for file transfer and batch processing. We upload electronic documents to the Chilean government.

We use version M2002 Model B and our clients use version 7.5.

We use it for our factory where we have a system that uploads electronic documents for the entire country.

The high availability and session recovery are the most valuable features because we need the solution live all day.

The product gives us security.

I have been using it for six years.

We are happy with the solution. It is stable and doesn't require much maintenance. Two people maintain this solution: an architect and engineer.

We have two appliances, and that is enough for now.

There are a million end users.

The technical support is good. They respond in a timely fashion when we have problems.

We switched to IBM MQ when we consolidated our software and hardware integrations.

The initial setup was easy because IBM did the installation and integration of MQ with our appliance.

The deployment took a month.

The vendor did the MQ installation. We had a good experience with the IBM consultants.

We don't keep track of return on investment because we offer a public service.

The price is high. 

I did not choose this solution. The company has had it for over 20 years.

If you want high availability with little maintenance, choose this solution.

We don't use containers yet.

I would rate the solution as a nine (out of 10) because it is not perfect.

The most valuable features are the transactional semantics around messaging, and some of the reliability that they have built-in, from disaster recovery and deliver-once, and at most months, schemes for messages.

One of the things we do is, we send SWIFT messages and SWIFT is built on the MQ protocols. So, that's kind of its core features.

I really need more of the API management. It's perhaps the biggest thing. I don't really care that much for the analytic side but in terms of monitoring, we have everything tied in the way we need. However, that involved a lot of work on our side, but more importantly, it is really some of the APIs that allow me to do administration and provisioning the whole time.

The migration from different versions can be very different and difficult. We build a lot of our code around it. For example, we wrap it with the APIs and we embed a lot of things into our environment. We have close to 400,000 lines of code just around that and it has to be a reviewed with every upgrade.

We have a rather large implementation. Perhaps, the largest one on the planet and from a stability perspective, it's very stable, i.e., when it's used appropriately.

We usually always get to the right people, because of the criticality of some of our problems. So, it works very well.

The setup was straightforward and we wrapped it in a very complex way.

You should read the manual.

The way we use this solution, there is nothing else that even comes close to it.

What's important is that we can team up and work together because we tend to drive the products really hard. So, that relationship with the vendor, at the technical side, is really important to us while selecting a vendor.

Specifically for MQ, the most valuable feature is the ability for us to deliver messages between applications using the MQ message queuing.

It's more of a guaranteed delivery. So, even if some of our systems are down at that time of delivering messages, when our systems come back up, it goes ahead and resends the messages, so we ensure that the messages are guaranteed.

I haven't seen any features that we could exploit today that's not currently available. I think everything that's in there today in terms of features; it meets all of my requirements. Everything that were shortcomings in the past, they've already been addressed from different users. The current version 8 is very stable and contains everything that we need to run our operations.

It's one of our more stable products on the CMS platform. We really haven't had any issues with that in terms of severity incidents, at least of what I'm aware of for the last three years.

It's very stable; we've not had to dedicate a lot of resources to support the product and that's a plus.

We have always had some unexpected workload coming in and we haven't had any issues of scaling up or down as and when we need to, so as to handle larger message workloads.

The only time that we have used support is when we do upgrades. We'll talk to IBM and maybe resolve some of the discrepancies in the product. IBM is very helpful. They are very responsive and if they can't answer the question, they find the person that can.

Look at the use case and verify that this product, i.e, the IBM MQ, can meet all of those requirements. If not, then go back and say that this is the feature that we probably may need, because every company may be different in terms of requirements for the product. If they have something that is beyond what this product is capable of delivering, then go ahead, open up a price quote for it.

It has always delivered and met all of our application requirements. Due to this, it has no shortcomings that I've experienced.

The criteria we look for while selecting a vendor are stability, where they are in the market place, what other research firms have placed them for the area we are looking for like Forrester and RAD group. We depend on them a lot to narrow down the number of vendors that we are looking for.

We use this solution locally and work in port authority where we deal with multiple parties like warehousing, containers, customs and Egyptian customs. Therefore we can communicate with each other and achieve middleware goals. We use the MQ Server and MQ client in each party and control it with the MQ server in port authority.

The product has allowed our organization to deal with all parties, like containers and warehousing. As a result, we can deal with these parties, exchange messages, and achieve our goals.

We have found the security and monitoring capabilities of the product most valuable. The product helps us monitor messages with other queues, view duplicated messages and control undelivered messages so they can be stored in pack-out queues and restored. We like more than one feature in MQ as the product is secure. For example, we can exchange messages between all parties with a stake and have control of undelivered and unrouted messages. Furthermore, with a scheme of validation, we can report access.

The dashboard is handy because we use it to monitor the messages and know how many messages are delivered to parties' dashboards. For example, we can notice how many letters are delivered, how many messages are undelivered, and how many messages are brought incorrectly by the dashboard. However, it would be great if the dashboard had additional features like a board design or picture management features.

We have been using this solution for over six years and are currently using MQ version nine.

The solution is stable.

The solution is scalable. Over ten parties, with 10,000 people, are using this solution in our organization, and two employees are required for maintenance. One employee is a system analyst, and the other is an integration developer.

I rate technical support a ten out of ten.

Positive

We did not previously use any other solutions.

The initial setup was straightforward. It was easy to install and configure.

The deployment was done in-house.

The product is good, and our organization has used this product for more than ten years.

The licenses for our company are according to port authority contract sales and we buy a license for six months or one year. I don't know the exact costs of the licenses.

I rate this solution a ten out of ten because we have no issues with it. The solution is good, but improvements could be made to the dashboard.

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.

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.