We have been looking at some competitors; for example, TIBCO Messaging and MuleSoft from Salesforce. One difference I have seen is that TIBCO is already a containerized edition. I have yet to discuss with IBM MQ if it is available on container. Another thing TIBCO has is that its messaging framework comes with a package for Kafka support as well as plugins for MQ connectivity. It allows you to connect to MQ or to Kafka for messaging.

We are also going to look at the IBM API-led integration. We have been running IBM products for some years so we may want to compare & see how these gets compared with their counter-parts.

We are exploring other solutions, including the Kafka platform. There are other services that can do the same thing but maybe offer some additional features, especially on the monitoring side. It may be faster as well.

We are using Confluent Kafka for some other services, and it's a good event-streaming platform. It does almost the same thing as message queuing, but we it has some other features and can do some things better than MQ.

I have evaluated Rabbit MQ.

I have only really been into IBM MQ. It's a good product at the moment. I didn't get an opportunity to look into or work with other products.

I didn't look into other options. When I arrived at the company, MQ was already there. They've used it for even longer than I have - for maybe 15 years. 

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.

We did look at alternatives, but our main platform is from IBM. We were thinking about other vendors but they are smaller, such as Compuware.

IBM was on the top of our short list. I didn't even look at the others, because I am biased.

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

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.

We used all the big players and we chose IBM just because of the fact that we've used them before with other solutions. We know their capabilities. Their delivery solution team has helped guide our solutions across the board and has delivered high availability, high quality to our members.

We also used Oracle, and we also used the Tomcats and JBoss product lines.
The most important criteria when selecting a vendor is reliability; knowing that they're going to be there to support you when you need them; the ability to bring solutions to an issue in a quick manner that allows you to keep your business going.

AMQ is one of them, Kafka is the other, and of course IBM MQ has always been on the list.

We chose IBM a long time ago from all the criteria I mentioned and then at the time other players were not evolving yet. IBM MQ has been an enterprise solution for many companies and the stability's there. It made a lot of sense for us to use IBM MQ back then.

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.

We did not really consider any options other than MQ.

MQ's features are very extensive compared to SQS on Amazon or messaging from Microsoft. Those solutions have basic features in there. They say, "This is what 90 percent of the use cases will use," whereas MQ is very robust in the way it's set up, in the way it works, and in the way it can be tuned. You have a lot of connections where you can connect thousands of users to the bank and thousands out of the bank as well.

It is definitely way ahead of all the other messaging platforms. It's like the "BMW" or "Mercedes" of messaging. The others will still do the work, but they're fairly average in what they do. They're very basic compared to what we do. Because we are a major bank, we have many different platforms and many languages, so we use it very extensively.

We looked at a couple others, such as RabbitMQ and Sonic. They just didn't have IBM’s weight behind them. I love it.

When looking for a vendor, I look at their reputation, reliability, and a recommendation from the industry like a Gartner report. The Magic Quadrant is huge for us. We look at quadrant leaders all the time when we're taking solutions.

I have been asked to do a PoC for one of our use cases, and we used RabbitMQ for that. They wanted to assess RabbitMQ in comparison to IBM MQ.

Obviously, IBM MQ has more advantages when compared with RabbitMQ. The main reason for doing this PoC was that RabbitMQ is an open-source product. Cost-wise, it looks effective, but from a technical point of view as well as from the point of view of scalability and features, IBM MQ is very enriched.

I am familiar with a couple of similar solutions, including Red Hat AMQ. In fact, I am trying to migrate to Red Hat. It is very easy to install and get it running. All you have to do is get your API and you're done. Stability-wise, however, with Red Hat AMQ, I have seen cases where some of the messages were lost. IBM MQ is definitely more stable.

We did not evaluate any alternative solutions.

I don't know the names of any alternative vendors.

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

Before choosing this product, I did not evaluate other options.

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.

I don't have information regarding which vendors were considered before we chose IBM MQ.

The features and the reliability of the product are important considerations when selecting a vendor.

We did not evaluate any alternatives.

Usually we just go with the IBM products, so I don't think we've looked outside that much for another messaging solution.

There are quite a lot of competitors of IBM MQ who have high capabilities.

I choose IBM MQ over other solutions because of personal comfort.

There are other products available, such as TIBCO ESB, and we have many
clients who are using that.

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

We probably looked at IBM and Red Hat solutions. The reason as to why we chose IBM is because they are more mature in that area.

Longevity, deep support and technical depth are my most important criteria in selecting a vendor.

We didn't look at many alternatives. We considered the Microsoft platform for a little bit, but we almost always knew we wanted to do this with MQ.

Our environment is 60% IBM. We did not shop to search for another solution.

In general, though, the most important criteria for me when selecting a vendor to work with are support, response time, credibility, to be near to us, and that they are not working from the cloud.

At that time, there were no other vendors on our shortlist.

The most important criteria for you when selecting a vendor to work with is obviously that it is a stable company; a vendor that will be around for a while. Those kinds of things.

We didn’t look at other solutions.

We did't look at other vendors, because, at that moment, IBM was our preferred partner, and still is, so we first looked at the IBM solution.

MQ was, to me, pretty much the gold standard in regards to what it does. To me there's really no point to look at other vendors.

We are currently evaluating other options. We are starting the comparison now and we are starting on the technical scope, not on the budget. However, we will also consider pricing as we evaluate other potential options for our company.

We are also slowly moving forward into using Kafka.

We calculated the costs for our total environment of going with RabbitMQ, and if we went with priority support for RabbitMQ versus the cost of IBM MQ, there was almost no difference in the costs. Unless we went fully open-source, we would not save anything with RabbitMQ.

We are also using Kafka, which is an open source tool, extensively in our projects. 

We did not evaluate other options. This was recommended to us by SARS. This currently is their standard of integrating with SARS.

I like Kafka more. MQ is number-two compared to Kafka.

We work with Proficient Solutions, Inc. and Prolifics. There are others as well, but these are the two major ones.

The number one criteria while selecting a vendor is availability. The other factors that we look for are proximity, their technical knowledge, market reputation and of course the pricing policy.

We evaluated Active MQ also.

Actually, we looked at IBM and Microsoft. However, IBM had a wider scope of the product, and compared to it, Microsoft provided limited platform support. That's why we chose IBM.

The factors that we look at before selecting a vendor, are how the product supports integration with other companies and the overall support they provide to us.

We were already using WebSphere MQ, so we didn’t look any other solutions.

As far as MQ, we only looked at IBM. There are many open-source products available now, like IBM MQ Plus. IBM is coming out with something called IBM MQ Plus Plus. Obviously we have not gone for it, but those are the competition.

MQ is also closely integrated with the broker; internally, it is now an API. There is a close connection.

When selecting a vendor, full scale support is important and technical acumen. If I'm asking a new question, he should be able to resolve it or at least give me direction. I also want timely support. If my production goes down at 12 o'clock in the night, there should be someone to talk to me. I think IBM has very reasonable support, so it helps. Worse-case scenario, you could call and expect an answer within the next one or two hours.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

I like RabbitMQ more than IBM MQ.

I wasn't involved in the selection of the vendors.

I'm not sure about alternative solutions considered.

We looked at the Microsoft solutions, as well. However, IBM was most important.

There were other vendors that were on our shortlist. We work with other vendors as well, but IBM is one of our premier vendors. The reason why we chose IBM was because of its stability and they've got the products that we are looking for. They partner with most of the partners that we're dealing with.

When selecting a vendor, the most important criteria are it's stability, helping us to grow forward and how can they help us get to the market faster.

N/A

It helps to plan, and it helps to understand the product. Sometimes management doesn't understand the project, they just go, "Oh hey, it sounds nice. Let's use it." Then they try to slap it on things they don't understand.