Outstanding RFEs and feature requests have been a hot topic on the MQ list server of late. Looking at the RFEs that have been posted and discussed, there’s a general architectural requirement many of them seem to have in common: Better support for administration and auditing.
It’s tough to ding IBM for lack of instrumentation in the product and I remember well a concerted and very public campaign to gather user experience feedback a few years back. There is considerable instrumentation in the product and that’s a Good Thing. Thanks, Hursley team and MQ management!
However, it is only recently that MQ users have been enabling security at scale, and many of the new security features are driving usage pattern changes. Much of the demand for instrumentation stands apart from security, but much of it is directly related and as the security implementations ramp up, previously latent requirements for instrumentation and administration become newly visible and in that light many gaps have emerged. The need is urgent based on rapidly evolving market requirements and both customers and IBM will need to reevaluate their enhancement priorities. We can’t assume priorities carry over from the last release.
Just as MQ approached what might be considered a well-developed set of administrative and instrumentation function, the market requirements evolved to make those look anemic. In light of ubiquitous breaches and more stringent security requirements, MQ needs a lot more admin and instrumentation functionality if we want to do things like prove to an auditor that the system wasn’t penetrated and have any confidence whatsoever when we say that.
Given recent developments with breaches, evolving attacks, and vulnerabilities now being discovered in deep infrastructure code like OpenSSL, that is to be expected. Furthermore, I know the MQ management team are aware that these requirements are emerging, and the reasons why, because I campaigned for them during my time as MQ Product Manager.