Can Vendors Make Our Lives Easier?

Edit: This application is still handled this way and is still a pleasure to work with.

Originally posted June 19, 2014 on AIXchange

Recently I was listening to a few admins compare and contrast two different shops that run AIX. All of them had worked in the first environment for several years. In this environment — we’ll refer to it as Shop No. 1 — they were constantly fighting problems and fixing others’ mistakes. Bad management and bad change control were cited as the primary issues. Pages would come at all hours of the day. Periodically missing a child’s soccer game — or a full night’s sleep — was the norm. Their jobs were stressful, to say the least.

Eventually, these admins found new positions working in customer environments where a vendor dictates much of their production computing environment. The vendor has very strict requirements that must be met before applications are allowed to run in production. Customers must have adequate hardware to handle the anticipated workload and capacity. Customer hardware must hit very specific IOPS numbers. The vendor requires access to customer systems that host the vendor software, and customers must agree to run vendor-specific monitoring tools on the systems. There are very strict requirements around change control, which means changes aren’t made on the systems without approvals. It’d take a catastrophe — a very rare and unusual event — for an admin to ever get called out of bed to go to work. Understandably, this group of admins was happier, professionally and personally, working with this vendor’s software. We could call this environment Shop No. 2.

Now for the discussion itself. The argument was made that if Shop No. 1 went with this vendor product or a similar solution that led to the same strict requirements being enforced, it would cease to be such a difficult place to work. But is it really possible that vendor requirements can so profoundly impact their customers’ working environments?

From the vendor perspective, being hands-on makes sense. If I can get my customers to agree to run my software on systems that have the capacity and functionality to handle it, if I can get them to properly manage and monitor their systems, my software — if it’s any kind of quality product — should work well. And I shouldn’t have to deal with irate customers blaming me when they try to run my software on an under-capacity system or when their own in-house programming introduces bugs. It’s in my interest to support customers — and only those customers — who agree to my requirements, because I can be confident there won’t be issues. Why wouldn’t I want to do that?

On the flip side, if I’m an admin, why wouldn’t I want to make sure my systems are capable of running the software I’m using? Why wouldn’t I want proper change control processes to be instituted? Doesn’t this seem like a win-win?

When considering vendors and the vendor solutions we deploy on our hardware, besides asking if a given software package will do the job, maybe we should ask how it will be supported. Because I can easily imagine a world where very specific instructions and very specific software support lead to very stable work environments.

How about you? Does your vendor have significant say-so over your environment, or is vendor input largely limited to implementation and support? How involved do you want your vendor to be?