IBM MQ Reviews

This product has helped integrate between applications, reduce rework, and costs by reusing working components of existing applications, such as mainframe applications.

At Citibank, for example, they could utilize the already working components in the legacy system and integrate them with web, mobile, and tablet-based applications, instead of developing three separate applications in each of these technologies. This tremendously reduced efforts, costs, errors, and timeline.

• Can process large amount of messages in a small amount of time.
• Integrates between distributed systems: For example, it can help integrate processing between mainframe, client-server, web-based applications by integrating the messages, supporting Service Oriented Architecture.
• It helps avoid rework by using already developed and working features of the application.

Many customers are gravitating towards open source products such as RabbitMQ, or going for a web-based package.

Also, the level of training as well as product marketing for this product are not that great. You rarely find a good training institute that provides training. Many of the architects in several organization are neither aware of the product nor interested in using it. IBM should provide good training on products like this to me and other candidates and post us to the US or UK where we can provide excellent support to the clients using the product.

Not applicable.

Not applicable.

Level of support with IBM WebSphere products, including IBM WebSphere Commerce server, IBM WebSphere Portal server, and IBM Websphere Integration server is fantastic.

For clients such as Target, IBM provided excellent support for IBM CICS Web Services, as well as IBM WebSphere Integration server, by having a dedicated IBM team in the USA that provided support.

Not applicable.

Setup has to be done by the team from IBM. Client just needs to enjoy the excellent support.

Pricing could be better, as with all IBM products. But their performance in production, along with security and scalability, will pay returns in the long run.

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

Middleware family of products such as WebSphere MQ, MB, TIBCO ESB, IBM ESB, and MuleSoft ESB offer excellent choices in architecture and re-engineering of software architecture, and should be the first choice, instead of building from scratch. If anyone recommends rebuilding from scratch, such an architect should not be working for your organization.

IBM needs to protect its products, as well as the engineers and architects who recommend those products.

We use MQ for guaranteed delivery and once only delivery of important business to business transactions.

We use persistence messaging to ensure messages are not lost in case machine is restarted.

We have implemented business to business transactions over MQ messaging. The guaranteed and once only delivery ensures business integrity.

Reliability of message transmissions and ability to replay messages in case message ends up in backout queues.

It needs a User Interface which is better than the aging MQ Explorer. The existing solution MQ Explorer is outdated.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

The technical support is good.

We have always used MQ.

The setup was straightforward for simple usage. Load balancing is more complex.

I think the pricing is reasonable, especially with IIB as a part of it.

We did not evaluate any alternative solutions.

Get a good MQ expert to get it right from the beginning.

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.

Reliability is the most valuable feature. MQ is used to support critical business applications.

The installation of product upgrades and patches is very difficult. It requires the use of the IBM Installation Manager (IM). The original IM data location used for installing the base must also be used for the installation of product upgrades and patches. In the Network Deployment edition, upgrades and patches need to be installed in the deployment manager and node agent profiles. I would improve this area by eliminating the need for the IBM Installation Manager.

We have not had stability issues.

We have not had scalability issues.

Technical support is excellent.

We had no previous solution.

Setup was complex. It requires a lot of components to be configured.

Use the new and lightweight version (Liberty) to lower licensing costs.

We didn’t look at other solutions.

Use the new and lightweight version (Liberty) to lower licensing costs. It is also easier to upgrade/maintain.

The message queue and the integration with any development platform/language, i.e., NET and Java, are the most valuable features.

We are the Companies and Intellectual Property Commission where our mandate is to register and regulate companies and intellectual property (patents, designs, trademarks, and copyrights).

In South Africa, a company that wants to do business with the government or a privately owned company is required to also register for taxes through the South African Revenue Services (SARS).

We have integrated our registration process with SARS to seamlessly register both the company and the taxes upon registration of a company with CIPC using the near real time concept.

We created an interface between two state-owned companies. We replaced the FTP/SFTP process that was cumbersome and often difficult to synchronize the two databases between CIPC & SARS.

Now that we utilize IBM WebSphere MQ, we are never down. Even if the MQ server crashes, messages are queued and can be recovered.

This extends the use of this product to allow seamless integration with all of our stakeholders for data exchange purposes.

I don’t know of any room for improvement.

I have been using WebSphere since 2013.

We have not had any issues with stability.

We have not had any issues with scalability.

We've never encountered any critical issues that required technical expertise except when the server crashed. We had to get an IBM WebSphere MQ accredited service provider to reconfigure the application. We never experienced any other pressing issues after that.

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.

The setup was straightforward. Network connectivity is easy as long as you understand your solution design requirements.

I had to take over the project with limited knowledge about the product. I can safely say today that I support the solution with minimum assistance from the software vendor. I was not trained, nor did I have skills transferred to me to enable me to support the product

Since this was not the initial direction CIPC was embarking on, we had the minimal license requirement. The cost was less than the value we would be getting out of this product. There's an annual license with support and it is reasonable cost wise.

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

IBM WebSphere MQ is robust, scalable, and reliable. You just have to clearly articulate your requirements and understand your needs so that you can realize the benefits of using the product. Our lesson learned is to always plan wide and implement narrow. This is the "phase approach."

MQ is one of the key integrations that we use for the z Systems to the open system connectivity. It helps us to transform the systems from the legacy enrollment to the latest technologies, as well. I'm part of the legacy transformations team and it provides really easy migrations, when it comes to integration with MQ. Any other integrations are a little bit challenging for us.

As I mentioned elsewhere, it provides one of the most seamless integrations that we can do both from open systems to z Systems or vice versa. These are the major benefits that we see. Since we are major resellers for IBM products, we generally look for transformation from z Systems to open systems and this tool helps us in transforming those.

They need to provide more and more platform integrations because I'm not sure what are the latest upgrades, in terms of MQ as of today. The latest integrations are going to take place in different cloud environments. So, I am not quite sure as to how seamless it can be integrated with other environments and I need to check that. This is also part of my job exercise, that I need to do every time.

There were not many stability issues, for sure. MQ is predominately a stable product, right from the z System days. I started out my career with z Systems, so we used MQ with part of the integration and it really helped us.

A long time ago, and not in the recent past, we did experience some issues with the technical support.

Our company has its own IBM center of excellence, where we have all of the required expertise within our organization, predominantly for this product. In addition, we have partnership support that we are getting every time from IBM.

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.

The setup is moderate; it's not that complex. Recently, we are working for one of the Microsoft technologies transformation, i.e., from the legacy Microsoft technologies to the latest Microsoft technologies and that integrates with some of the z Systems.They are using MQ as the integration layer and even there, it was a very seamless integration for us. It's not too complicated nor very simple either. It is at the moderate level, which for integration is anticipated.

There is quite a good amount of documentation that you can get either from the IBM Redbooks or from the IBM support websites. Also, if you are partners with our company, then you will get the required support.

Before installing, I would request you to do a quick analysis and go through the end-to-end process, as to what are your requirements and how to configure this product up-front, i.e., instead of directly installing it and then, trying to configure it on the fly.

In general, when selecting a vendor, we look for more and more support.

The way that we use MQ is just for messaging. We have various systems in our organization and we have various applications.

We use our routing feature when the request is coming from the business application. The request goes to the distributive side and it is routed to the right claim instance.

We use MQ in between for messaging. We process the messages we receive and we send the responses back to whoever sent us the message.

That person or application basically picks up the response and distributes it to whoever requested it. The way we design the environment of that instance can leverage any of the environments.

Because we are a 24/7 company, we always want to have a robust solution where we can keep getting messages. There should be no delays, outages, or blockages. Those messages should be coming in seamlessly, transparently, and efficiently.

The way that we envision the future of our organization is that MQ works well. We have MQ local and MQ distributed and we're leveraging both.

The way that we are using the solution may not be utilizing the full version of MQ. However, what is available right now works well for us. We are not looking to expand.

It's very robust. It's stable. Whenever we have a situation where our listener is down for some reason, MQ has the capacity to put those messages into some queues where we can retrieve them later on.

It has those alerts built-in. It tells our operation that the queues are getting filled up and they need some attention. We have those kinds of features turned on.

It is very scalable.

Our team is very well versed in MQ and they're always able to solve all the problems. In fact, last year we moved to iApps, and they were able to work with IBM. They were able to solve whatever roadblocks we had.

We have our own support team. Whenever we have some situation, we go to them. If they're unable to solve it, then they reach out to IBM.

I'm not aware of the pricing. That's something others deal with, but they do tell me that it is expensive. I don't know how much it is.

We have an ELA contract with IBM and everything is included. It's not like MQ has a different price, and different products have difference prices. Everything is done as part of one big contract

Customers need to look at their design and carefully select the product. They should look at the product capabilities and change the design accordingly to work with the product.

Don't expect a lot of things from the product. You need to trust your design, your solution, and your app. This product just helps you to move around and navigate your data.

Your product has to be solid to process those elements. If I am unable to put the message in a queue, then if MQ sends me a message and I'm unable to pull the message and process it, then I would not blame MQ. It is my product or app that is not working. The solution is just an interface. It's just messaging. It's sending and retrieving messages, and that's it.

We use MQ as part of the core of our enterprise information bus. We started that journey in 2009. We have it both on the mainframe and in the mid-range. For us, by allowing messaging to integrate with some of our third-party solutions, like for web banking and so on, we are able to create an information highway that took in the legacy events, captured ATM and credit card transactions, and integrates that into a digital web dashboard.

It provides a better customer experience and more timely access to data.

There could be better APIs around cognitive analytics, around how the messages are flowing. For example, plugins to Watson. That would be useful.

Stability is rock-solid.

It is highly scalable.

Technical support has been good.

I was not involved with the initial setup.

You need to have the right use case to support that type of data and flight paradigm. If you do, there are third-party open-source solutions that a lot of vendors have embedded into their products that you have to integrate with. This gives you a really good platform to do that. So, if you don't want to put something in that isn't as robust or scalable, you don't have to. You can rely on this to be the conduit and the glue for your messaging fabric.

It's also really good at asynchronous logging. A lot of times, when you buy these turnkey solutions for whatever vertical, they often don't have robust logging and security. So, we use MQ as an underpinning to get that for us and we have written services within our system that take advantage of those capabilities. So, even if the vendor doesn't provide it, we have it.

When selecting a vendor, stability and security are the most important. Price is also important. But, in banking, because it's mission critical and highly sensitive, stability is probably way up there. If messaging fails, we don't make money.