People have started using the likes of Kafka, Spark and other new messaging technologies. But when you take the likes of banks into consideration, which mostly are running on mainframes and AS/400, implementing advanced technologies are not an easy job. Getting an MQ-certified guy is not that difficult in the ASEAN market. There are a lot of certified professionals. That's one of the reasons we still use MQ for most of our messaging. We are still looking at open-source deployments but we have not yet implemented anything like that because of the knowledge GAP & dependency on the existing products. We do not have a dedicated team to take on that task yet.

With IBM MQ still in the bank, and a dedicated team which has expertise in it, we really cut down the time-to-market, from a few months to a few weeks. The development framework is already there. If business comes up with requirements, technology team already know what needs to be done. And by building the in-house team, it gives us the facility where we don't need to ask the IBM guys or other vendors in the market to help us every time we have a new requirement.

Another way MQ has improved the way our organization functions is customer notification. Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. There are requirements for notifying customers on a real-time base & also for each and every payment sometimes, once a day. These are be enabled with the help of MQ.

In addition, there are fewer failures during the end-to-end payment process. MQ comes in very handy because we don't lose messages in transit (message persistence). It gives us the ability to store and forward messages when required. We heavily rely on MQ for these kinds of requirements.

Also, we have certain applications that want to receive the messages in both production and the disaster-recovery data center at the same time. Without MQ in the picture, it would have been very difficult for us to configure that. MQ Publish subscribe capability is very helpful in that scenario.

MQ has helped to reduce integration costs, mostly by acquiring the enterprise license of MQ. We can actually set up multiple MQ servers in the same environment and each MQ server is dedicated to a particular application. We also use MQ up to a level where the messages are coming from multiple host systems and they go back to a single channel. When written back, the response goes to the exact host that had sent the request (Message Affinity). Without a tool and without a messaging architecture that is as good as MQ's, it would take a lot of time in hard-coding to achieve that. Prior to the team being set up and having these frameworks in place, it took roughly two to three months to deliver any of these integrations. Now it takes three to four weeks. It has helped reduce the effort and man-hours by half.

It was the main messaging bus for us for a very long time. Therefore, we have applications connecting, and even some of the modern applications are still using MQ. From a company's productivity perspective, we see a lot of benefits. It's all point-to-point connectivity. For any point-to-point messaging needs, MQ is very good.

IBM MQ is good for system integration within our organization. 

If we need to do batch metadata transfers – involving APIs and MQ – we can do that as long as the source and target systems support MQ. 

However, for anything without MQ, especially when we need asynchronous communication, we have to rely on custom-developed services. It's like that.

The performance is good.

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.

It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.

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

We use MQ for our insurance claims and use it heavily for CICS in the IBM Mainframe and use the IBM IMS for our applications.

We're an IBM mainframe user. It folds into our hardware very well. Our support is covered that way. It's kind of an end-to-end type solution. It works well with the distributed partners. We use WebSphere, so we can go ahead, plug things in and they work.

From the infrastructure point of view, it's a great improvement and it's more flexible to the latest hardware. Also, it is flexible for whatever is coming or whatever is available for on-premises and cloud integrations.

This is the main component of our systems for delivering service to our customers. Without MQ, we would not be able to work or offer our services.

It provides scalability and it also provides secure messaging.

It gives us flexibility when it comes to offering different projects or different types of solutions to customers. Instead of somebody having to sit back and wait for something, we give them the option now to be able to say, "Hey, we can give you these 10 things, and you can get all 10 back," without having them get six now, and come back later to get something else. They can get everything at one time and it looks like one portfolio of stuff versus it being six or seven different things at one time. MQ gives us that feature.

We use it for our factory where we have a system that uploads electronic documents for the entire country.

One of the things we do is, we send SWIFT messages and SWIFT is built on the MQ protocols. So, that's kind of its core features.

It's more of a guaranteed delivery. So, even if some of our systems are down at that time of delivering messages, when our systems come back up, it goes ahead and resends the messages, so we ensure that the messages are guaranteed.

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.

Most European companies have MQ, though we just added it four years ago. MQ changes the way people think about their applications. E.g., they are more integrated. We see synergies with the tool, but there is a long path to changing people’s minds.

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.

The benefit is that we are in an industry where we cannot lose any piece of data, so MQ gives that reliability. In terms of security, like I mentioned preciously, you won't loose any of the transactions at all, even if you have a failure. It's very important to us, especially the FIFO feature (first-in, first-out) and that kind of persistent messaging. We have a billing system where whatever messages drop first need to be consumed first. Thus, these features are really good. It helps us flowing all the MQ messages.

The time to deployment is quick and easy. Again, it is stable, auditable, and uses automation to deploy products and keep the systems up and running while the business is still functioning.

It helps us to make sure that every time you do a swipe on your credit card, the credit card transaction is guaranteed to transact.

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

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.

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.

We initially went with a single server or two servers. We used a lot of the mainframe and we used it on the one server. Then we realized that we were down to a single point of failure. What we did was we enabled something called queue sharing where you have multiple landing platforms, which lets you execute multiple applications in the background. And we're now able to use our HA failover quite extensively. It previously required one server to be down and there would be an effect on customer business. Now it requires at least three servers to be down before we start feeling the workload. And even then, we're hardly ever down because we have now spread the load using the queue shared clusters.

In terms of the solution helping to reduce the cost of integration, we're using what is called the MQ Appliance. Because the appliance connects multiple solutions in our bank to this platform, we don't need to procure more licenses or more servers or more infrastructure. So at the moment, we're using a very cost-effective model, compared to two to three years ago, which is when we started to consolidate servers. We had about 400 servers but we've reduced their number by moving them to the appliance. We've consolidated all of those server licenses and server infrastructures.

For example, we took a server that was front-end, using Java, and connected to the mainframe. We have that entire server's application queue, entry queue, and all the objects moved onto the appliance. And there is no cost to it. It's just a box. There's no operating system on it. We have MQ on it and MQ then connects things to the rest of the bank, so we save on the infrastructure, on server licenses, and MQ licenses. We've created a setup like that a few times already in our bank.

This process of integration has saved us a lot of time. Previously our projects would take at least three to four weeks. Now, once we have firewalls and security in place, and once we have an acceptable solution design in front of us, they take three to four days. From the time we design the solution until things are connected to the appliance, it takes a week. It's only fast because most of it is scripted. It's almost like a container.

It's easy to install and it's bulletproof. We never have an issue with it. The upgrades are easy and IBM support is fantastic.

The amount of transactions: You don't have to send a file down. You just send the messages; whatever the transaction is. It's going to be much more effective and more trackable.

My organization has used MQ for a long time. It is a very scalable, common platform that we can use for sending messages. We use MQ in terms of messaging, MQTT, and MQ FTE for file transfers. It's versatile; it's very functional; and it provides us with a common messaging platform. It eases our integration.

With the introduction of MQ FTE, we've been moving away from other file transfer options, and standardizing the actual large file transfers with MQ FTE versus the previous product that we had. We've standardized on MQ FTE, in terms of shutting down basic transfers like FTP and other basic ways of transferring large files. Adding the MQ FTE functionality, on top of the MQ backbone, has been nice.

We have clients spread all over Africa and they have to process different types of requests, such as credit requests and debit requests. We use the Queue Manager to handle these requests. Our MQ server will accept the request and send it on to our core banking application.

If you imagine the order from left to right, the application is on the left, then the enqueue server is in the middle, and the core banking is on the right. In between the queue server and the banking application, we have APIs and systems in place to understand the XML files.

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

It provides faster interaction between the applications. It makes it easier to integrate the applications.

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

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.

It's the transport tier that connects our systems. Without it, we would be very disconnected.

We're using it entirely for our transactional systems right now.

We're not really using MQ to better connect across cloud, mobile and devices, and the internet of things. I imagine that will be the tool that we will utilize that will help bring that next level in. Right now, we're not utilizing it.

IBM MQ's flexibility has sped up our active communication. 

Basically, we are using the messaging part of the solution, collaborating with other technologies on the WebSphere platform. Once you do everything, then you don't really need to worry if the network is available or not. Once you are delivering the message, it's going to be sure delivery for you.

These files are critical. They have to reach the whole file. Sometimes, a half file gets the same name and gets processed as a half file. The result is like replenishing all those files. The results are really screwy if you get half files. Since started using MQ, we haven't seen this.

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.

It provides seamless integration with the enterprise and any enterprise data changes. Also, the reliability is important for us.

The biggest advantage about us using messaging is that we can connect to most of the financial customers across the globe securely and data is always sent only once, asynchronously as well as synchronously.

The benefit is, it is easy to use. You subscribe to your queue, they get the message and then they do what they need to with it. It goes on or it ends, either way; it is very easy to use.

We are using it to integrate systems. It's an asynchronous system and there are a lot of benefits of this method for us, so we are using IBM MQ.

If one of our servers or systems fail, MQ will store the messages for a long time, so we do not lose any information or messages. That's why we are using MQ.

It makes it much easier to have people from different experience levels be able to interface with one another, without having to be cross-trained on many different platforms. A business benefit is, it can take somebody who's a Windows guy or a Linux guy, and he can fully communicate with the z/OS system, or vice versa, without having to have that extra knowledge of those other systems.

It's incredibly flexible. It's not software that people get into a religion over; where it’s mainframe or distributed. MQ runs; you don't have to worry about what platform it's on. I find that to be very, very useful. It recovers extremely well in disaster recovery, which is very near and dear to our hearts. High availability options are outstanding.

Support is excellent. The team in Hursley are outstanding, very responsive. They listen to suggestions, and they deep dive into problems.

Our clients complain about the price of this solution but otherwise, they have not had any problems with it. They are very happy with the quality of the product.

We work with an organization who has only one product and that works with IBM MQ. Combined with IBM MQ, this product is our primary data store.

The product was already installed which is not surprising as it was first published around 1993.

Our organization uses it a lot to interface applications that are outside the mainframe with applications on the mainframe, or to CICS, items like that.

It helps meet that threshold between what do the application people want to do – because they want to do everything now on GUIs and outside applications – and be able to have the security of the data living on the mainframe and how they get to it. It's the go-between between those two worlds.

There are probably dozens of ways we are using MQ to better connect across cloud, mobile, and devices, but it's mostly the fact that they are setting up stuff and then they use the MQ as the go-between between the distributed world and the mainframe. That's mostly what it's being used for.

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.

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.

It has allowed us to take applications that would not normally be able to communicate, to be able to talk to each other.

It allows different applications to communicate with each other.

It's multi-platform, so we can go between mainframe, Unix, Windows, different platforms, and we can have applications send data using the messaging.

It allows us to observe the status of our applications in real time; basically, very quick.

I would say it makes the organization more efficient, more reliable; and whenever there is an error, I guess resilient is the word I'd use.

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

The benefit would be scale. Because of the way it works, you can really have many, many users who use the solution at the same time. Other benefits would be the ability to send messages between systems and do systems integration, without interrupting their run-time behavior.

It is hard to say how it has improved the way my organization functions because it's been here since the beginning. I'm not sure I have an answer.

It has improved the way my organization functions by just being less paper, and more efficient with timing; again, going back to the customer service, with clients being able to close their work orders within a shorter time frame.

We had to integrate different systems and MQ allowed us to send messages between systems and guarantee delivery. What that did is allow us to more easily integrate those systems and feel 100% trust in this solution.

The whole integration channel between PowerVM and third-party applications goes through MQ. This is why MQ plays the role of middleware, of integration, and it helps us to quickly integrate all applications around PowerVM.

It's reliable. It's a solid foundation. It’s always up and running. MQ doesn't crash on us. It gives us the stability of the platform to be able to do all of the integration between our applications.

Before we used MQ, basically it was more of a batch job, sending and receiving messages; kind of like an upload, download type of thing. Now, it's real time, where we can effectively handle millions of transactions an hour, once we implemented MQ.

In conjunction with some other products we use, such as IIB, it does a lot of the transformation. It cuts out a lot of programming that has to be done for transforming data from our carrier customers into the format that we need it to be. That's really one of the big benefits.

The benefits are the same as the most valuable features. Close coupling between different domains, which reduces your total cost of ownership by not inter-tweaking everything.

It allows us to do point-to-point integration in an easy manner. It allows different applications to talk to each other; applications that may speak different languages. You have mainframe technologies, Java-based apps, .NET, things of that nature, and MQ allows you the ability to share the data between those different types of systems.

It is the core component of what we do. We're using it to distribute messages from one platform to different multiple platforms.

Using MQ, because of the speed of getting the transactions, adds the value back to the customers. When you are dealing with a customer in the store, you don't want to be sitting and waiting for transactions to come back on the customer information, the CIF file. Having MQ with the instant response adds value back to the customer's experience.

It allows us to do real-time claims processing through a non-host platform into the host platform.

Actually, we didn't have a choice. If we wanted to speak with IBM SIS, it was the way to do it, so we had no choice there. We had to do it.

There are some part of the business side that couldn't be done without it. It's an integral part.

Integration is a key benefit; it integrates easily. Management is easy. Queue management is one of the key features of it; how easy it is to get set up, get started, get running, look at your queues, look at your workloads, etc., and see what's going on.

We’re not using MQ to better connect across cloud, mobile and devices, or part of the internet of things. It's something that we're looking at for IoNT. We're looking at doing mobile parking, our parking meters. It's something that we're looking at, but we're just doing the road mapping. We haven't deployed that yet.

Currently, it's our connection between our web front end and our back end billing, but that's the next step.

In terms of runtime, we just push data. We have reduced the various footprints of the database and for transmitting the data from one location to another. MQ is reliable and more structured and it's helped us a lot in pushing the data. The data can be pushed and it will be persistent. It helps us and the connectivity between the data as two separate applications and our middleware interactions are much faster and more reliable.

Adding concentrators was great improvement, but it lacks the SonicMQ CAA (continuous availability architecture). 

It is the most reliable product that we have ever used.  

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.

It gives us flexibility to drive a solution on any platform but have a reliable communication network.

Applications are time critical, and IBM MQ has played a significant role in ensuring fast, reliable message transmissions. With IBM MQ in place, fear of messages getting lost in the case of an unplanned failure is almost none.

It helps us, i.e., even if some of the other apps are down, we don't lose any of the customer data, so it's very beneficial from that perspective.

It keeps all of our large systems interconnected, so the MQ is at the base of all of our system integration.

The product encourages the idea of asynchronous processing, which means that the sender and receiver are not required to be active and running at the same time. The message will be saved to the receiver queue until the system starts successfully and pulls it for processing. This is typically used in all internet banking functions that receive their data from different bank systems.

IBM MQ was found to be easy to implement and operate. It became the defacto standard, and integration problems moved from an operational issue to application solutions.

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

IBM MQ has broadened a lot of communication between interconnecting the applications. It's more fault tolerant, since we have the message delivery guaranteed. We have high availability for the application and it's not stateful. It has provided the features such as the application to process messages from the mainframe as well as from the web, so we can increase the throughput of the system.

It helped us with some of our security, on some of our roles, if I remember correctly. It helped us integrating; we’re trying to move a bunch of different things, like trying to move EZMaxMobile into our Maximo and a few other things. Part of that was bringing up WebSphere to the newest version for all the integration.

There is a good user interface. It is a very good way of interfacing two systems. For example, in our case, the central bank clearing systems interface our systems using MQ. It is seamless. I did not face any problems. Initially, when you do the setup, you have to be careful and configure it properly. Once you do that, it is OK.

IBM MQ helps us scale our applications and balance our applications' performance. MQ is quite reliable. In some cases, our application became simpler and more reliable simultaneously.

Technically, it has made our lives a lot easier. Prior to having MQ, we were basically developing these custom in-house solutions, where we were running into a lot of issues. After bringing MQ on board, along with its integration and flexibility that it has provided us with, it has basically shortened the amount of work we had to do in order to get it set up and to get the communications happening in between.

It is easy to use and seamless with our existing technology. It's a trusted name we know that we've used for years. It performs and it has very low downtime, if any.

We've been able to get some disparate applications that weren't originally written to be integrated, but we've been able to make that happen.

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.

In terms of benefits, our customers are happier since we are doing a good job.

The benefits of the new version are greater ease of use and management of MQ.

We are using it for the APIs, beepers, and beeper processes in order to integrate data into the source systems.

The on-premise installation is very valuable to us, since we are working with a lot of companies which have a very high degree of compliance.

Again, we're trying to streamline factory-based speed to market. So, it's improved that.

I have seen in many organizations it has helped in designing great architectural solutions by helping transfer messages between different systems.

It improves reliability and guarantees that messages are not lost. This is a prerequisite for the online payment process.

It's very handy, graphical, easy to use, pretty, and intuitive.

We really haven't had any problems with it. I don't have too many positive things to say because usually, I'm in it when things break, and that's when I form my opinions. And I haven't really had to form too many opinions on MQ because it's been really stable.

It has improved my organization in many ways. As I’ve mentioned, it's sort of the standard in the market. If you use MQ, you probably can talk to anybody in the market. We also use IBM Integration Bus and they integrate well.