Slashdot Mirror
Preventing Vendors From Playing The Blame Game?
Johan asks: "In choosing an enterprise architecture, one of the considerations I have is support. IBM provides a good database (DB2), a bad Enterprise JavaBeans Container (Websphere) and an excellent OS (AIX). If I tolerate the delinquent EJB container I will have the advantage of one phone number to call for support and a single "point of responsibility". However, I dont want to have a mediocre architecture by getting all three components from the same vendor (IBM). I would like to get the database, EJB Container and OS from different companies (Oracle, BEA and IBM). How do I prevent (or at least minimize) them blaming each other when support issues come up? Anyone have a solution for this?"
--
--
We have fought the AC's, and they have won.
My company did the same thing last year. We ended up going with AIX, DB2, and Websphere. _BAD_ choice. We've since switched a lot of what we'd hoped to use the RS/6000 for to a different platform.
The AIX has been OK, but IBM doesn't seem to know their own hardware/software very well. We've tried to order some performance monitoring software and were sent the wrong CD (three times and counting). When we discussed our performance problems (definitely not IBM-related) the senior technical person had 'never heard' of a configuration like ours (internal SSA disks). When trying to buy an extra hard drive we were promised Monday delivery. On Thursday we get a call asking for more detailed information so they can ship the right drive (even though there is only one possible drive to ship for that model/capacity).
DB2 is not a bad database, but good luck finding A: any software that _really_ supports it, and B: any DBA that can support it -- there are lots of Mainframe guys out there, but mainframe DB2 is a bit different than DB2 'UDB'. Enjoy the 1-2 books out there.
For my part I would heartily recommend looking _really_hard_ at Oracle, MS SQL server, Sybase, DB2, et. al. and verify you can: get a DBA, can find developers familiar with the database (DB2 is different enought you don't just develop and pretend it's 'any' database), and that any future software you might use supports the database.
As far as 'no finger pointing' -- getting everything from IBM does nothing to prevent finger pointing. Instead of Oracle blaming Sun who blames BEA, you'll have the websphere group blaming the DB2 group who blames the AIX group within IBM. Unless you're a really big IBM customer (read: have a mainframe or two) forget about getting it resolved instantly.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
The answer is that these days there is no problem. All the old "big iron" companies have re-invented themselves as service supplies. Consider, for example, Compaq who bought out DEC not for their hardware or software but for their large portfolio of nice juicy service customers.
;o)
IBM is no different. All you have to do is tell your IBM rep what 3rd party components you want to run and that you want IBM to support the whole shebang. They'll be glad to do it - revenue is revenue. The one thing you'll *never* hear them say is "Er...I don't know how to do that"
It shouldn't be more expensive than paying for three separate support contracts either, in fact you'll very likely be able to negotiate a discount.
Looking beyond the obvious, you could in principle get a comprehensive support contract from just about any major service supplier, eg Compaq or ICL. But IBM are one of the best these days. They had to get that way to survive (remember how they were bleeding money a few years ago).
Consciousness is not what it thinks it is
Thought exists only as an abstraction
I work for IBM (full disclosure :) supporting a major telco. This telco has Sun, HP and IBM servers with the whole lot supported by IBM. I personally support the HP servers and know next to nothing about IBM servers (ironic I think).
So referring back to your question, simply select the bits and pieces that you want to run with and then get a major service supplier to bid on supporting the lot. You'll find that all of them will be more than happy to support whatever you have.
Just choose IBM since they are the best! (wearing my big blue IBM underwear on the outside :-)
Even with the best selection of vendors, you cannot escape a certain amount of "not my problem; it's him" finger pointing. The reason is simple; when something breaks, you are not dealing with a hive-mentality supplier where everyone in that company knows everything about the company's products. You will be dealing with individuals. And usually, the first person dispached on a problem call is the lowest-ranked, -paid, and -trained. And a large percentage of such, if they can't resolve the problem, will resort to finger-pointing instead of calling their next level support.
As suggested elsewhere, you (or someone in your shop) will need to be learn enough about the entire installation that you can tell when someone is pouring lemonade in your ear and saying it's rainwater. Don't just give some surplus manager the title of "Architect" and let it go. Find a techie who knows how to back off and observe.
Other suggestions:
Getting reps from all suppliers in the same room is a good idea, but not generally possible until you have been down much longer than you want.
Don't be afraid to "escalate" the problem. If the first response body can't / won't solve the problem, ask for a manager. Managers don't like talking to customers, but the good ones like even less having unhappy customers because of untrained employees or employee attitude. Odds are that the manager may not even know about your problem (other than "there was a ticket but we closed it").
If you find a support rep who really knows her stuff, saying "thank you" never hurts. (Lots of customers think it does.) For a really good job, a note to the salesman (to be forwarded to the support boss) will be appreciated.
Sometimes, it is possible to request that a particular support rep be assigned to your account. If you find a good one, do so.
Bottom line: support reps from the suppliers are not your employees and so do not care quite as much about your company's problems as you do. Since you cannot completely avoid getting involved in problem resolution, get trained. Get multiple people trained.
One good way of minimizing vendors blaming each other is making sure your product works with components from at least two vendors. Then you can always substitute the faulty component of the package, and tell the vendor whose software faulted that "when I replace this with , the problem does not occur". Sometimes it's enough that you support several versions of the same vendor's product, but for best results, you need to support different vendors' products.
For some reason, it seems that when you tell a vendor that you are readily able to replace their software with someone else's, they respond much better to requests for support.
The same works other way around too. If you have vendors blaming each other, you just need to replace one of the components with something else, and you are able to say the problem was or was not corrected by replacing that component.
If none of this is possible for your product, then the only real alternative is to prove your point by producing a test driver that only uses one of the products [again replacing other products with something else], but is still able to reproduce the problem.
-- Esa Pulkkinen
Unfortunately, there is no way of avoiding finger-pointing. As others have pointed out, if you go and get a single big vendor, they will keep bouncing you between project groups, who will keep remarking on what a fascinating problem you have or what a strange/nonstandard setup you have.
The best ways to get a problem fixed in a hurry is to keep escalating it. You don't want to be a 'problem customer', but it sounds like you are pumping plenty of moolah into this, so they won't be able to just brush you off.
Ultimately, picking a single vendor will better avoid the fingerpointing between unrelated service techs because you can always find someone who is superior to both of them. But if you pick an inferior system, you'll have to make more service calls.
If it is onsite service, throw a 'tea party'. Get all the techs from each software package which has been blamed, and say that none of them can leave until the problem is fixed. I've had three weeks of back and forth end in two hours that way-- usually the tech isn't going through his whole routine and so is missing something. Once he is in that environment, he will have to do everything, even the stuff he thinks he doesn't have to do.
I guess my answer to your question is to thoroughly explore interoperability before you buy, but then get the best stuff with the best service-- without trying to find the one company for everything. Make sure interoperability is explored before you buy, so the sales reps won't weasel out of it later.
I have just gotten out of tech support, so let me shed a little light from that perspective.
What you have to do to avoid finger pointing is ISOLATE the problem BEFORE you call.
For example, you have a problem with the tape drive on your RS\6000, using some non-IBM tape backup software. BEFORE you pick up the phone, try tar. Now you know who to call. Since it is IBM's tape, in IBM's system, with IBM's tar it is IBM's problem if it doesn't work. OTOH, if it works, when you call your backup (or DB) vendor and tell them their software is goofy. If (when) they try to point at IBM you tell them, "Hmm, works with tar."
See?
Again, from a tech support guys point of view, this is YOUR JOB. Using a single vendor makes your job easier, because you don't have to figure out who to call. But it is not the tech support guys fault if you just call the vendor who's product is exhibiting the SYMPTOM, if it is not the component that actually has the PROBLEM. You will be the victim of finger pointing as long as you don't believe it is your responsibility to isolate the problem before you pick up the phone.
Please don't interpret that last paragraph as "finger pointing is the customers fault." It is not. The vendor should say "It is possible, or even likely that the problem is in fooware. Here is how we can make sure our product, barsoft, is working correctly." Bad support techs don't do this. (Actually, this is a management problem, but that's another thread.)
The point is sometimes you will get bad tech support. Doing your homework is how you avoid finger pointing.
-Peter