I also have experience with RabbitMQ. IBM MQ has more valuable features and is more reliable in comparison when it comes to servers and applications.

Before IBM MQ, my company used to use normal point-to-point APIs. My company started to use IBM MQ because we wanted to introduce standardization in our processes.

We previously used different protocols like TCP socket connections. Now, most of the services use MQ. 

I have not worked with other products. 

We did not previously use a different solution. 

I have previously used TIBCO EMS as well. 

We did not previously use a different solution. We started with IBM MQ a long, long time ago and we stuck with it.

We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.

We have previously used and still do, Rabbit MQ, which is open-source. It is getting quite popular because it is also stable and it has a good UI. This UI allows us to check the messages with some statistical data.

I didn't use anything before IBM MQ.

Previously, we did not use any other product. I am not familiar with other technologies.

I'm learning and doing some experiments, but we have found a  product for the volume we have.

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

Our support from IBM recommended the solution from the beginning, so this is what we use.

There was not a previous solution. I know because of experience with my other jobs that this is a more robust technology to invest in.

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

We did not previously use any other solutions.

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 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.

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.

We did not have a previous solution. Early on, we didn't have many options to choose from. A procurement person came along and told us that this is the best solution for us.

We used this product to solve our initial development solution about 15 years ago. We were coming on with Java, and we needed to connect our distributed front-end Java to our back-end legacy business intelligence code that's all written in COBOL on the mainframe. MQ was just the perfect way to connect.

We did a selection and instead of going with some of the others, like TIBCO and whatnot, we went with IBM MQ.

As far as I understand, we did not use another solution prior to IBM MQ. Our old strategy did not use this type of technology.

We have always used MQ.

Our first time using a message queue system was MQ, so we went with the IBM MQ product.

Being with a state agency, we actually go through what's called a hub that has a relationship with IBM. We can't directly purchase from IBM, so we have to go send bids. But, since we have quite a few IBM applications, we always you know target IBM since we already have the support that we need and our relationship with our sales person is really great. So, we always choose IBM.

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.

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 did not previously use a different solution.

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.

I think it was always an IBM MQ base which we used.

We did not previously use a different solution. This is something that we started using and it has grown tremendously in eight or ten years. It is one of the most widely used messaging solutions, internally and for external customers.

I did not previously use a different solution at my current firm but I have also used Microsoft Queues. However, there were a lot of issues with it in terms of the performance, stability and security. IBM MQ is better.

We've had MQ for a long, long time. It was something that we've always supported.

We did not use another similar solution prior to IBM MQ.

I have used RabbitMQ and Amazon SQS.

I was involved in the decision process of how we were going to use RACF, and what they were going to set up to do their calls, but they decided they were going to use MQ. I was actually called in as a RACF specialist to help get that interface going.

I have not used another solution prior to IBM MQ.

Not applicable.

This was the first solution of this type and it was the one that was the best fit.

I didn't make the decision to invest in this product. There was someone before me that decided.

We have been using MQ for a long time. In the past we were using a custom-developed framework instead of MQ, however, that was ten to 15 years ago.

We've been using it for a long time. We were not using any other solution before.

We did not have a previous solution. We always knew we needed something that worked asynchronously, something that did the messaging in the background. The reason we knew we needed MQ is, it's one of the integration backgrounds we supported and this was an obvious choice.

When selecting a vendor, the knowledge and the experience that the vendor has is most important. For example, IBM has had MQ for forever. So, that's definitely helpful. It's finding resources that know the product and technology and obviously the ability to support the platform. And, when necessary, be able to guide the customer through various usages and integrations with the rest of the IT infrastructure.

It was too long ago; it wasn't my decision to switch.

We were not previously using a different solution. The business challenged the pattern we used. Using queuing and messaging presented itself as the best solution.

When choosing a vendor, we want support, access to information, solid products, and, hopefully, building blocks where we can build on and use other products and foundation.

I was partially involved in the decision process to invest in MQ. We were not previously using something else. We were actually early adopters, really and truly. We started using MQ back in 1996. We've been using it ever since then.

They were really just doing batch file uploads, downloads; probably a couple different things versus MQ. It was a big implementation from IBM. They partnered with us, also to help us. We also started slow and then used it in other areas as well.

The decision to invest in MQ was made prior to my starting at the company I'm at. I can't take claim for that. I was at another site, and we weren't using MQ at that other site.

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

We had no previous solution.

We didn’t have a previous solution. There was a new requirement to handle asynchronous transactions, and MQ seemed to be the best solution at that moment.

From an MQ perspective, it's something that we've been using for a long time. Unfortunately, when you're dealing with very large companies, it's difficult to transition away from stuff that you built a long time ago, so you have a lot of this stuff that's just hanging around, that's been built a long time ago, and you still have to maintain it. Once something goes into production, it's typically very difficult to get money to update that service five, ten years down the road.

I wasn't part of the decision to switch.

I was not involved in the decision to invest in MQ.

We used FTP/SFTP before. We switched to IBM WebSphere MQ because we needed a robust, scalable message processing mechanism with the ability to integrate with different technologies.

We had a mainframe that had MQ associated to it, so we just kept it going forward.

I previously used ActiveMQ, but I switched to IBM MQ due to the robustness of the solution.

Previous, we were using the Oracle Tuxedo solution and it had a lot of limitations. It was not able to interface with a lot of the other systems, i.e., the interface was only with C-based operating systems/programs that use only Windows. That's why we switched to IBM MQ, since it brought a lot of benefits.

We knew we needed to invest in a new solution mainly because of the issues we were having with the old version; it was pointed out that they were going to be fixed by the new version, so that was kind of a simple thing.

Interfacing is required in any situation when you have two systems talking to each other. So, there are not too many options. One, is that you can have a file handoff. You can have MQ messaging. Or, you can have an API. So, we currently prefer API, so MQ is slowly losing its position.

Actually, when I joined this company, they already had the solution.

We haven't faced a situation where we needed to invest in a new solution, predominately since our clients already have MQ. We are just transforming, upgrading or optimizing those versions; we are only doing this type of work.

We didn't have another solution previously, we have always been with MQ.

Relationship is the most important element when looking for a vendor.

We were previously using a different solution.

N/A