IBM MQ Reviews

The most valuable features of this solution are its reliability, efficiency, and the capacity to bring value.

The benefits are the satisfaction of my users (my clients), the stability of the solution, and the availability it provides.

It would be nice for the next release to have better reporting. For example, elasticsearch or ELK. We don't have that with IBM. So we have implemented our own solution.

We have a major application based on DataPowers and WebSphere servers.

We had an main issue to visualize efficiently the utilization of our WebSphere applications (load, who is using, when, how). It’s critical in defining our “capacity planning”.

Actually, we’ve developed our own reporting solution based on Kibana/Elasticsearch. Kibana analyses ours logs in real time. We have done a portal with several graphs. It is really impressive. We are very happy with our solution.

IBM doesn’t provide, by default, a reporting item as efficient as Kibana. DMGR is not as powerful and flexible.

The stability is quite good. It's strong and the performance is important.

Scalability is a bit difficult for us. Since this product is an IBM product, we have to work together with IBM to be more efficient at this point.

We are not really happy with their support. They don't have the skills to very efficiently answer our questions, so our relationship with them is difficult.

I was not involved in the initial setup.

When it's too difficult to have what we want with IBM, we develop our own, better solution and we try to integrate our own solution with IBM.

When selecting a vendor, we look for the confidence, the relationship. We have to share the same objectives and to agree in order to deliver the same value to the client.

I think the most valuable feature is the scale that it can run at. It runs millions of transactions in our environment on a daily basis, scales and works well.

I don't know if it improved my organization but it basically drives communications between a lot of our subsystems and processes. It's kind of the backbone of a lot of our services.

I think some of the management tools could be improved. We've got a variety of different management tools, that we have in place. Having them be more a core part of a product, rather than being add-ons from either other solutions or open source, would be good.

Stability is very good.

Technical support is good. For the most part, we get what we need. We did have AVP for a number of years, which was another level of support. We're reconsidering that maybe we should be going back to that level just for the more timeliness and quality of support.

There are a lot of open-source alternatives coming out now, today. Sometimes MQ can be perceived in the organization as being expensive. Price is an issue.

Where we've deployed other open-source solutions, we're not at the same scale so it's difficult to say at this point whether they do as good of a job as MQ. Obviously, we're very conservative in taking some of our core systems and moving them to unproven technologies.

There aren’t any features that they have that I wish MQ had as well. They actually tend to be a little lighter weight than MQ, in a bad way.

Make sure that whatever solution you have is going to scale to meet your needs and that you have the tooling infrastructure available to you, as well.

The most important criteria for me when selecting a vendor to work with is, obviously, quality. Reliability of the product is number one but it needs to be cost effective, as well.

We haven't really moved into the cloud with MQ at this point.

Integration with my vendor product is the most valuable feature. The vendor strongly prefers MQ. We had a lot of configuration issues when we tried other products. The second-most valuable feature is the stability.

The reliability is a benefit. We rely on it to operate our business. The fact that it's stable enables us to run our business.

With the tooling around being able to see what's in the queue, we found third-party products to be friendlier than the out-of-the-box products, as far as, "Let me see what the content is of the object that's on the queue." I want to actually be able to see what's on the queue, and the tools we were given from IBM or from the representatives were terrible. I guess that would be the thing I’d like to see. I've got the third-party products that I use now and it’s at the operating-system level, but that would be the suggestion.

It is very stable. We’ve had outages and downtime but, out of about 9,000 servers, we'll have a couple go down a month. Overall, that's pretty good.

Scalability hasn't been a problem. We have a highly distributed environment. We run it across a large server farm. Each server has its own instance. I don't try to scale it vertically, so I don't have a vertical problem with it, and it scales fine across.

Technical support is very disappointing. They didn't respond. Then, we nagged them a lot. We basically got, "That's why you should just upgrade to the latest version of IBM. That's a known problem with the stack. You should just upgrade. Why are you still so far behind?"

We had some trouble when we tried to get the vendor product working with the open-source products; that didn't go well. We tried HornetQ, maybe ActiveMQ. (It was eight years ago.) We liked it better than the embedded WebSphere MQ one; better than the one inside the app server.

The vendor had a dependency that their product worked better with IBM MQ. Also, we have an extensive relationship with IBM, so that made the decision straightforward. If you're having trouble with the alternatives, just go with the existing vendor.

Initial setup was complex because of what we were trying to do, as far as the distribution of a number of clones. With the IBM team, there was more internal drama and relationships – more personal problems – than there were technology problems.

We considered other solutions. It was, "Do we really have to?" with this vendor, or could we look at other things? So, we tried other things, and then came back full circle. We picked MQ because we struggled with the other ones. There's a lot of money on the table, so we actually looked at it, we did try it.

Reliability is the most important criteria for me when selecting a vendor to work with.

Look at which features you really need.

It works fine. It does what it's supposed to do. As far as being the best product in the universe, it's a plumbing product; it doesn't have a huge range of functionality; it has a very specific functionality. But it's reliable, so it's a good product.

The most valuable features are content security and content delivery, from a whole network protocol perspective.

It's adapting itself to get into every single component throughout the entire world being Java enabled.

We are able to transport data across any platform in a secure fashion, be it internal or external.

From the send and forget perspective, MQ allows you to – on your own – manage your data, collect your data, and manage your data perspective.

The barrier to success is basically the engine behind the collection of the data.

I also think the administration could be a little more straightforward. Right now, we have to develop our own truly distributed administration system. There's a GUI that's really not manageable; not that easy to use.

It's very stable.

It’s very scalable.

Technical support is responsive; it comes out of Hursley, which is their main support and development location. There is a direct line to their development; it's very good.

We were previously using all kinds of solutions, including SCP, SFTP, FTP and proprietary APIs. MQ allowed standardization to port data.

We decided to use WebSphere MQ because we needed data transport from all kinds of systems.

Responsiveness is the most important criteria for me when selecting or working with a vendor.

Initial setup was straightforward and flexible.

We did not really consider any options other than MQ.

My advice is to lay out your infrastructure in a fashion you can support.

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.

It's predominantly for message queuing, to assure delivery.

Our team manages messaging aspects with this product, among others.

I like the architecture it provides seamlessly for assured delivery.

The monitoring could be even better by building it into the product. The disaster recovery mechanism could also be built-in. 

I would like to see them not rely on third-party tools for everything.

Finally, they have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like.

I have been working with IBM MQ for almost seven years.

It is stable, for sure.

We are facing some issues with the scalability in some of the components. That can be improved.

We are satisfied with the technical support.

The initial setup is straightforward. It takes a few minutes.

We started with IBM but we have recently been looking at Kafka and Solace.

If you have mission-critical applications that rely on an exchange of data, and the data is very valuable, then I would suggest using MQ.

We have a team of people of 50 to 60 people using it, in middleware admin.

It's good for messaging, very reliable, and forward compatible, so it makes our life easy when it comes to upgrades.

It's reliability really enables us to do our interfaces. Additionally, it scales really well, so when our needs grow, it grows with us.

We would like to see more capabilities with MQ over the internet. It would be very helpful to us to expose our API and web services. We want to see that a little bit more and we want to continue to see that it's a secure means for us to protect our data.

We are absolutely happy with the stability.

We are absolutely happy with the scalability.

We did use technical support mostly when doing upgrades. I would say that we have used this solution for about 15 years already. We only encountered production problems two or three times. It is a very reliable, very solid solution.

I've been involved with integration for a long time. When we first talked about our need to do queue messaging, MQ was the first one that came up. It proves itself.

I was involved in the initial setup. It was straightforward.

I don't recall whether we evaluated alternatives. I think IBM was the first and the last one we reviewed a solution with.

Do the same thing we did. Make sure that you give it a small test first to make sure the solution really works well. Then, make sure it scales.

I've used other solutions, but the most valuable features of this solution are the search capabilities, consolidating the data and searching through the data. I think that these are some of the key things.

For this organization, it was the first log management solution. So, it definitely gave us the ability to search through the data when we had events. We could search based on the identity of the person, or the machine, or the IP address. We could do a lot of different searches.

We could also do payload searches and depending on how much capacity you have, you can do quite a lot with it.

I want to see a three-dimensional perspective to the data. I don't want to see just an event perspective to the data. I want to be able to identify a user and within clicks, know the whole activity of the user. I don't want to see it in events. I want to see it in the relevant information.

There needs to be a little bit more of investment for enhancing the user interface. That is the main thing, i.e., to make it represent the state of the actual incident response and how you would troubleshoot an incident. It was a major position by IBM when they bought it. But, we see a lot of things being done around the Cognitive side, around the Watson side, but what we're not seeing growth in, is the actual tools interface and usability.

We wanted to be able to see seamless identification of log sources, seamless categorization, normalizing of log sources and seamless alerts. All those things that are required for solution maturing, it has to be able to take data and make sense of it by itself, without a lot of input. Those are the areas that they can really improve it.

It's been stable. Stability hasn't been a problem, as long as you have enough capacity. It's all about sizing it right for the size of your environment.

We drop packets every day. So depending on how our log volume increases or reduces, you see the impact on the packets being dropped.

We've used it and it hasn't been great. It didn't seem like we could get the answers we needed without having to use professional services. For a solution like this, there are little things like, how to tune it, how to upgrade it and that as a customer we don't feel the need to use professional services for. We want to be able to just find a document on how to upgrade and that has been difficult to find.

We didn't have a previous solution. We inherited it as part of another acquisition, of another purchase from IBM and then we scaled it up to meet our capacity.

I was involved in the setup process. We got the basic functionality working, which is not difficult. It's getting the full value out of this solution that was harder.

From an analytics perspective, it's a good tool but you have to have the resources to own it. It's not only about buying it, nor is it about the capacity, but somebody has to care and feed it. It's not one of those you put it in and you can walk away and just consume the data. If you don't care and feed it, you won't get what you need out of it.