Forums
About 15 years a go, I had this job where I was requested to set up and administer an MQ connection from our company to the Depository Trust & Clearing Corporation (DTCC). Since I had no prior experience with MQ, I picked up the manual, learned a few commands, and in a day or so, had a script to create queue managers, queues, disk backing stores, etc. I got the system analysts (SA's) at both ends on the phone and in ten minutes had connectivity to their test and production environments. Access was applied for and granted to relevant individuals and applications, and application coding could begin.
By Torquatus - Own work
I didn't know the full and complete way to manage most of the features of MQ, but I had figured out enough to properly support what we needed. Total time was 2.5 man-days of effort.
Fast forward to the next job, where file-drops and cron job checks for file-drops were the way interprocess communication was implemented. At some point, they decided to use a third party vendor to communicate with DTCC via MQ. Since I had done it before, they asked me to set it up. OK, easy enough. All I had to do was install it, set up a queue manager and a couple of queues to test things. Easy peasy. I put MQ on my laptop and created the queue managers and queues. Then I introduced myself to the SA at the vendor (who was in the same position I had been in at my previous job) and explained to him what I had done in the past and that I needed it set up at the current job. He agreed it was a good way to go. I then got our SAs and my counterpart at the vendor on the phone and asked them to hash out the low level connectivity. That's when I hit the wall of bureacracy-run-amok™.
It turns out that our SA's wouldn't talk to SA's outside the firm. That's what the networking team was for. OK, get them in the loop. We won't set up connectivity with outside entities without security approval. The networking team also informed me that they wouldn't support a router with connections outside the firewall, but that they would allow a router physically outside the firewall IF the vendor would support it (that's like saying I want to connect to Google, so I'll pay Google to support a router outside my firewall to connect to them).
The security people wanted to know whether hardware had been purchased yet (is the hardware "appropriate" for connecting to outside entities). The fact that it was just for a test queue to send one message fell on deaf ears; proper hardware must be approved, funded and in-place first!
The hardware people wanted to know if the hardware had been reviewed by the capacity planning team to be sure that it supported future growth (our plans were to replace a task that moved 4 (f-o-u-r) 2MB messages per day, and if successful, add 5-6 subsequent tasks comprising 10-20 similar messages each per day; a ten year old laptop would have been overpowered for this task).
This lunacy continued until we had 33 teams involved in a 342 line project plan comprising multiple man-years of effort - to set up a queue manager and 2 queues from a laptop to a vendor, to send a single test message.
At this point, everybody at the vendor was enraged at the stupidity to which our various departments were subjecting them (e.g.: you must program your firewall rules like xxx, you must provide and support a router outside out firewall, will a message sent from your hardware be able to be received on our hardware (seriously, MQ supported both platforms!), etc.), and ALL of them got on the phone to try and force me to change my mind (it wasn't coming from me: it was the other departments).
I was finally forced to say the stupidest thing I've ever had to say: Yes, I agree that the way you are proposing that we set things up is well understood, redundant, reliable, easy to set up and support, cost effective, efficient, secure, reasonably simple and generally accepted as the right way to do this, and our company will have none of that!
I then had to tell them yet again that it wasn't coming from me, and to beg them to just do it the way the bureaucracy wanted it done, or said bureaucracy would never let it happen.
At that point, I convinced my boss of the stupidity that was being inflicted on this vendor, and so he agreed to sign a five year contract, at premium rates, to get them to do it the way that our company wanted, even though we knew it was idiotic, wasteful and just plain wrong.
This went back and forth for a year. Long story short: we paid the vendor a crapton of money to supply, configure and remotely support a router at our location outside the firewall, we paid them a fortune for five years of capacity to push 10 million messages per day, and we spent more than $750,000 on super high powered redundant hot/standby hardware across dev, test, qa, pre-production, production and DR environments, all before we were allowed to send one test message across a test queue.
Our company then decided not to move to the more modern messaging technology because it was too difficult to set up and that they would continue to use cron job checks for file-drops as message-ready indicators. I pointed out that the difficulty was from the internal bureaucracy and not the vendor or the technology... <crickets/>. They never sent another message down that queue, and left all that iron - dedicated to the cancelled project - unused, fully supported and running in all the environments for five years, after which the process of decommissioning hardware was triggered (I'll leave this for your nightmares to imagine).
I later found out that I was the 5th person (out of 8 over 10 years) hired to perform this same migration. Apparently each of us ran into the same impenetrable wall-o-bureaucracy.
To this day, they are still doing interprocess communication via file-drops and cron jobs to check for the dropped files.