IBM MQ Reviews

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.

It's wonderful and is our primary backbone for moving data across different applications, within our company. Especially when we're talking about the healthcare and pharmacy industries, where we have patients' critical data, this is what we use to move data across. It's our backbone for data transmission.

The important thing for us at this point is the amount of data that we move, the guaranteed delivery and message affinity that it offers. These are very critical features when you talk about patient data.

It has definitely brought a lot of benefit into our organization, especial when you talk about applications talking to each other. For example, when you look at a patient's experience, i.e., from the moment the patient comes in, sees the doctor, the doctor makes a lab/pharmacy order and by the time a patient goes through the lab, the data needs to be there. It provides a lot of value in moving the patient data from the entry point until the patient gets out of the building.

One of the features to pinpoint is migration. When we want to migrate from one version to another, it takes years. So, definitely, we want to see some solution for IBM's standpoint, in order to make it easy for the customers to migrate from one version to another.

There are some operation challenges; however, it could be not because of the product but instead in terms of how we use it. We might be looking for improvements by adding some self-service capabilities, in order to go through the hoops of different teams to get the objects created. Thus, this will make it easy for the developers to access some of those things.

There were no issues in regards to the stability or scalability so far. Like I mentioned elsewhere, I've been using it for years now and it has really matured, at this point. We are really happy.

Lately, quality of the technical support is not that good, as it used to be in the past. IBM supports us from the infrastructure's standpoint to the part where they provide us product support as well. So, one of the things that we did notice recently was that the qualified people who were supporting all this stuff are not there anymore.

It is important to understand how to implement it and for what exactly you want to implement it. Sometimes, we get into a situation where you may not be choosing the right solution and may not really need MQ to support your product. You may be expecting something that MQ doesn't offer, so it is important to understand your business requirements and the features that MQ offers, in order to see if it is effective in implementing the solution.

The important thing while selecting a vendor is to help the customer go through the implementation phase. One of the typical situations that we run into are the people who you're interacting with, i.e., from a customer's standpoint, the vendor may or may not have the comparable knowledge that is required to make them move to where they want to go. That's the challenge we face across all our vendors. It doesn't have to be an escalation all the time so as to get what you want. The person you're working with should be knowledgeable enough to take the customer from the start to the end.

The most valuable feature of this product is that it provides guaranteed message delivery. This is important for us because we want to have guaranteed message delivery and integrity; we cannot lose that message.

The reliability that it provides is the most beneficial aspect of this product for our organization.

One thing that I'd like to see is that queue-sharing should not depend on DB2. It should have this feature by itself, instead of depending on DB2.

In order to set up IBM MQ queue-sharing, DB2 data sharing is required in multiple LPARs. Thus, to make the implementation easy and straightforward, it will be nice if DB2 is not required for queue-sharing.

In regards to the stability of the product itself, it's pretty good. However, it depends on the configuration as well. Overall, the stability is good.

Scalability is pretty good as well and on the mainframe, we can expand it. That way, we're looking to carry out queue sharing, on the mainframe as well.

The technical support is fine. MQ is very predictable product and it's good.

I was involved in the initial setup, but not in this company; at a different company. I found that it was easy to install.

This product is from IBM which is a very well-known company.

MQ is a reliable, easy to understand and install solution.

The most important criteria while selecting a vendor are that they should be well-known and the product's reliability. These are the main reasons as to why we chose IBM MQ.

It allows data transmission from multiple platforms in a fault-tolerant manner, that's the biggest feature. It is important for us because we do a lot of data transformation and data transmission between different systems; that's one of the biggest things that we do.

It's the backbone of all our data transformation and integration. Thus, this solution is our main integration platform.

Maybe, there should be a containerized version of the application, that can be deployed on the enterprises. So, there is need for a Docker container version of this product.

They need to do a better job of getting it into the open-source world, so that other people, who are more dependent on open-source technologies, start using it as well.

We've been using it for ten plus years now, so it's been good.

It has scaled to all our needs.

We have used technical support. I can't think of any issues with technical support. We've received the support that we needed, on time.

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

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.

You should take a look into this solution.

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.