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's ability to scale, it's ability to do guaranteed delivery and it's ability to do point-to-point of what we subscribe are the most valuable features. And finally, it's ability to handle messages in various formats and structures.
I would like the ability to connect with some of the more recent offerings, such as API Connect; being able to publish our MQ endpoints, the queues, the messaging infrastructure as IT assets. To control them, govern them and manage them and being able to publish non-functional requirements around it. For example, we support this size of the payload, we support this much throughput. Making it known and available to the rest of the organization, because this technology is so technical in nature, business management doesn't understand it. I would really like a business-friendlier or end-user friendly information layer, and some kind of simple ability to communicate what we have with the users.
I want an information layer that I can publish and tell the whole rest of the organization this is what you get.
Stability-wise, it has worked for us. It is an old technology and it has always worked well for us.
You can really have many, many users who use the solution at the same time.
We haven't had to use support much, because we have really good people. So, it has worked for us the way we wanted.
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.
In the latest installation that we are talking about right now, I was not involved. But, for other installations in the past, I was involved in the set up and it was pretty straightforward. I'd consider MQ one of the simplest products to use.
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.
If they're thinking about a solution similar to this, I would say, look at your requirements and not just the business requirements. People often stop at that point. Look at your ability to support and run the platform, and the cost of running the platform, because, depending on your need, it could be very expensive to run a large messaging infrastructure. Also, think about what non-functional requirements you want to support now, but what you might have to support three, five, or ten years down the road. Think about it from the bigger picture perspective. And don't implement the solution for one small single requirement. People often make that mistake. They commit to a big licensing and support cost but what they're running is very small and there is not very much value added. That’s a problem there. So look at whether can you put a lot of solutions on it. Can you use it as a platform rather than a points solution is what I would look for.
