Preventing Vendors From Playing The Blame Game? 148
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?"
Easy (Score:2)
:-)
Don't compromise (Score:2)
If you understand exactly how you are using each of these components, it will generally be self evident which one is to blame for any particular problem. Convincing the vendor can be another problem, but if you come armed with clear facts about the situation, it shouldn't be that bad.
Know your system, and how it interacts with each product. Convincing the correct support department that it's their issue isn't as bad as people would have you believe, as long as you are insistent and persistent.
This is obvious (Score:1)
Certification (Score:1)
Simple solution (Score:4)
--
Understand fully your problem (Score:1)
Preventing Vendors From Playing the Blame Game? (Score:2)
Political cooperation (Score:1)
Make them agree (Score:1)
Re:This is obvious (Score:1)
Bah! (Score:5)
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.
Re:Don't compromise, be an adult (Score:1)
When you put together a mish-mash of best technologies as you're proposing, you're telling your boss that you're man enough to make it work.
That's why they pay you the big bucks, honey. Aren't goals fun?
Celebrate Adulthood - Bush/Cheney in the New Century
There is no problem (Score:5)
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
Spend loads of money, be vocal in support groups (Score:2)
Being vocal in support groups (online, real-world, etc) that give you an option to make support statements in front of other users is really helpful. Its one thing for the vendor to lie to you in a private conversation, "We think AIX sucks and Oracle should really be run on Sun.." It's quite another for you to say in front of Oracle and other customers "Why does Oracle have these bugs on AIX?" If your claims are true, they'll have to address the problem in a more constructive manner, especially if you've brought up this problem publicly before. They're much less adept at finger pointing in public.
In a slightly simimlar manner, I had a problem with my home DSL service. My ISP for DSL was also my business ISP. The ISP kept giving me a rash of crap and foot dragging about their inability to deliver advertised bandwidth. Finally I sent a message to the technical suport mailing list for corporate customers asking why DSL bandwidth was so lame and why engineering was too lazy to look at it (not those exact words, but that exact meaning). Within six hours I had an email from a senior engineer and two phone calls from the director of operations and the director of engineering. The point is that public humiliation is a powerful tool..
The downside to buying everything from one shop is that they might tend to look at you as a bit easy. If you were willing to spend all your money with them, why won't you believe everything they say?
What's the problem with Websphere (Score:1)
You buy it (Score:2)
You buy single vendor support, usually from one of the big systems integration houses:
The above is obviously a sale blurb (and not directly relevant to your problem at that) but you get the idea: Pay somebody lots of $$$ to make them own the problem. I'm sure there is a growing market for this type of services.
I can't really recommend anybody for your particular problem.
---
"Where do you come from?"
IBM will support any 3rd party component (Score:4)
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 :-)
Re:Preventing Vendors From Playing the Blame Game? (Score:1)
Re:Simple solution (Score:2)
Re:There is no problem (Score:2)
As for the original question, there is no way to prevent one vendor from blaming another's product. The easiest way to get the problem resolved is to submit a detailed, accurate description of the problem, preferably with a test case, that demonstrates that the problem lies with one particular vendor.
I've done a lot of support and I can't tell you how many times people call and say "x is broken" and they don't describe the problem or provide any diagnostic data to support it. The first thing a support person is going to do is to throw it back at you and say "give me more detail." It's no wonder why people complain so much about support when they don't even help themselves in the first instance. In my experience, ore than 80% of the questions are answered in the documentation (for the stuff I support). Of course, no one reads it, they want the answer spoon fed to them. Pathetic. If you're using complex software you damn well better read the documentation (yes, a lot of it is poorly written -- that's another thread).
Web app servers, networks, different databases -- all these make the problem that much more complex.
Another poster said "tell them to certify their products with the other software you want to use." This is a nice idea but if there's no business case for it it won't happen. If IBM is pushing WebSphere there's no real reason for them to bother certifying that Weblogic works with DB2.
The answer is: read the documentation, keep up to date on the fixes and patches, and, when there is a problem (and there will be) send everything: the steps you took, the documentation you read, what you thought would happen, what did happen and provide data to back it up. More is better than less.
It's the developers that make the difference (Score:2)
You cannot escape (Score:5)
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.
Re:Don't compromise, be an adult (Score:1)
"For the children!" - Vote Republican!
Re:Simple solution (Score:1)
Portability (Score:4)
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.
Sun Microsystems Ultra Sparc Systems and Solaris. (Score:1)
Don't worry (Score:2)
Finally! A halfway decent "ask slashdot" question.
--
Still and blame game (and one flamebait item) (Score:1)
*spit out milk* HAHAHAHAHAHA!
*wipe tears from eyes* AAAAaaanyway, you'll still have a blame game problem. When you call up with an OS problem (and you will) the tech support guy will say "that sounds like a DB problem, here's the number". It's not going to matter that it's nominally the same vendor--from IBM's point of view it's a different business unit.
--
Give us our karma back! Punish Karma Whores through meta-mod!
an excellent OS? (Score:1)
If you think AIX is an excellent OS, you're so bug-tolerant you're never going to need technical support.
;-)
Know what you don't know (Score:2)
It would be simple, if you (or your staff), knew ALL the ins and outs of ALL these parts. In the real world, this is not likely to happen. But, if you can isolate a problem down to being NOT in two out of those three, then it looks pretty likely that it would have to lie in what's left. Hence "know what you don't know." That is, know what areas you are weak, and what areas you are strong. Use that to your advantage in trying to sort things out.
Often, in my experience, have I found myself going down the debugging path in frustration until I step back and realize the problem is not where I thought it had to be. That meant those areas which were not even a consideration, before, now come back for another look. I had again stumbled upon a case of:
But, I suspect the real desire of this post is not improved debugging skills, but to avoid the need for debugging inter-vendor problems in the first place.
Good luck! It's the nature of the beast that bugs tend to occur in the interfaces.
But, there are some steps that can be taken to lessen the challenge... find someone else who has been down this path before and can point out the landmarks and land mines along the way. I commend you for doing so here in /., but there is more that can be done:
When you get that working and stable, take what you've learned and then add capabilities. Build not your house upon the sand.
Consider, for example, your database vendor. Contact IBM and ask for references of customers who have used their DB2 database in a similar situation. Contact those references and find out what THEY learned from their experience. Do the same with Oracle and MicroSoft. Build up a table of strengths and weaknesses.
Yes, it is a lot of work, up front, but it has been well said:
Lean on them a little (Score:1)
I should also mention that since you'll be running AIX, you'll also be using IBM hardware, which makes them a fallback point. They may say that they don't support your particular configuration, but once again, they'll fold under pressure. I've done it before with IBM (OK, so it was a Thinkpad running Linux, not a massive AIX server, but still).
Re:Certification (Score:2)
RTF or RFM? (Score:1)
I work as "tech support" for my department at Texas Tech University. (Nothing quite as complicated as the origional "ask slashdot" submission but I enjoy it.) One morning I'm chatting with my coworkers and one of them mentions that Real player isn't crashing alot, I tell him he can just reinstall it and it would probably work. He then asks when I can do it for him. I think "I'm to important to do some small job like that" and tell him he can just do it himself. He then counters that with his job as a "interviewer" he could just hand someone a list of questions and tell them to hit record on the tape player and just leave the room... I replaced it later that day.
Last night at exactly 12:03AM I got a call from my aunt because she wanted to add her mother on Yahoo Messenger, and wanted me to walk her through it.
It seems like I'm constantly troubleshooting computers (who isn't?). But the worst problem I ever came up with was when I bought an IBM Aptiva, added a slave drive, ran Aptiva's "update" program to be current and all. After tearing my hair out trying to get it to boot, and then doing the investigative work for 4 hours, it turned out to be an incompatibility with my new slave drive, which was the same brand and model (aside from size) as the first. Blimey.
Read the Documentation ;) (Score:1)
As for the original question, there is no way to prevent one vendor from blaming another's product. The easiest way to get the problem resolved is to submit a detailed, accurate description of the problem, preferably with a test case, that demonstrates that the problem lies with one particular vendor.
I've done a lot of support and I can't tell you how many times people call and say "x is broken" and they don't describe the problem or provide any diagnostic data to support it. The first thing a support person is going to do is to throw it back at you and say "give me more detail." It's no wonder why people complain so much about support when they don't even help themselves in the first instance. In my experience, ore than 80% of the questions are answered in the documentation (for the stuff I support). Of course, no one reads it, they want the answer spoon fed to them. Pathetic.
If you're using complex software you damn well better read the documentation (yes, a lot of it is poorly written -- that's another thread).
Web app servers, networks, different databases -- all these make the problem that much more complex.
Another poster said "tell them to certify their products with the other software you want to use." This is a nice idea but if there's no business case for it it won't happen. If IBM is pushing WebSphere there's no real reason for them to bother certifying that Weblogic works with DB2. The answer is: read the documentation, keep up to date on the fixes and patches, and, when there is a problem (and there will be) send everything: the steps you took, the documentation you read, what you thought would happen, what did happen and provide data to back it up. More is better than less.
As usual i've found another link that deals with this matter
I messed up the HTML! (Score:1)
Customer No Support (Score:3)
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.
what timing! (Score:1)
My problem is not finger pointing by IBM support, my problem is finding anybody at IBM who has worked with an environment with more than 2 dozen EJB classes. We have 200+. We finally found a guy yesterday with a clue. Now, if I can only get him on site for a week or two.
No finger pointing. Lots of cluelessness for the size and load that we expect to have.
ciao
Re:Preventing Vendors From Playing the Blame Game? (Score:2)
Nonono. It's actually a good idea. Funny as it may sound.
Such a second-level person, with only a vendor/outsource tie to the company would be getting paid for handling these issues. His SOLE purpose is to get the problem fixed. So he won't be distracted by the boss's secretary and that virus she just executed.
In short. The in-house guys should take first crack at getting the problem rectified. But if they cannot, the trouble ticket's handed off to the external liason. This guy then is in charge of coordinating online/telephone techsup from the multiple vendors (hardware, OS, application/environment). This way other internal issues don't suffer neglect when a major issue comes up with the big breadmaker systems.
Example:
Chas - The one, the only.
THANK GOD!!!
Re:Bah! (Score:1)
IBM.
The S70 is a beauty of a box, and the hardware support engineer really knew his way around inside it.
The real problem is the VAR brain drain. If you're hired and trained on AIX by IBM, odds are the resellers will agressively headhunt you. The result is, the odds of getting someone on the support line who actually knows anything is pretty low.
I ended up figuring a lot more out from my System V background and reading the manuals while on hold for support than I did from support.
Meow
priorities and culture (Score:1)
The culture of the said organisation (or team within) is also critical. Avoid a backward looking, blamecentric cultures if possible.
Rob.
open source (oh well, someone had to start it :-|) (Score:1)
This experience is with service providers (for websites, etc.). And what I really want to do then, is get over there myself and solve the problem with my very own hands: because I experience the problem myself, I won't stop after a minute trying to solve it or declare it as done, forcing the costumer to ring for the Nth time saying "no, it still doesn't work". I will solve the problem instead of making the costumer so tired that he gives up - but I am not allowed to do that.
The problem I have with service providers, is the same as what you have with your soft-/ hardware providers. My advice would be to minimize your dependency on the service of your provider, because they don't really *care* about your problems.
So, open source springs to mind, no matter how boring it is to put the topic up here. You can repair your own problems, have a third party look into it, etc. Vendor independent, bladidibla, go ask ESR anyway.
For those parts that you'll really have to get as closed source (in the cases when the propietary product simply outperforms the alternatives), I guess all you can do is bothering tech support with your problems and keep bothering them, as others have already advised.
Some "IANAL"ish excuses are in place, though: I am not a specialist, but these are my thoughts on the topic.
It's... It's...
It's the econo^H^H^H^H^H support, stupid... (Score:1)
Okay, so what's the point? There are other companies, who because of their market share, or just bad support, will find it easier to blame the other guy, than find the real problem. I've had to point out specifically what was wrong on another vendor's implementation, before closing a case. It's really a function of how good a company's support team is...they represent the whole company. Which is what I keep trying to tell my guys...
So...get a taste of what kind of support you will be receiving from the company you choose...call them with a problem, and evaluate how they react. If it's "too late" and you're already in bed with a certain vendor, learn how to yell. In other words, when you are talking to a support engineer, and not receiving good support, ask to speak to their manager. If the manager doesn't respond, tell your salesperson, and get loud. Trust me, if you shake the tree hard enough, you will get your problems resolved. (Just make sure your problems are legit...don't make these guys send someone onsite to fix a problem that isn't real, etc. -- remember, support are people too...)
Good luck with your project...
Re:DO compromise! (Score:1)
Besides, have you checked out WebSphere lately [crn.com]?
WebSphere Studio [ibm.com] allows you to develop on the Windows platform, and drop your application into AIX.
Re:Don't worry (Score:1)
--
Fear this! (Score:1)
AIX (Score:1)
--
Give us our karma back! Punish Karma Whores through meta-mod!
Re:open source (oh well, someone had to start it : (Score:1)
Anyhow, they already bought the new hardware and such (brand new) and wanted to use the old internal tape drive on the new machine. Now, remember that this is a 10 year old tape drive to get working on a brand new machine... no drivers... no support... no help... I got it working (whoho!) by hacking simelar drivers to reconize the drive, even though they weren't supposed to (a little late night hex editing if you catch my drift).
Anyhow, the only thing that DIDN'T work was their management system (a piece of old crappy cobol code... not that theres anything wrong with cobol, its just this was ms-cobol and was all compiled sans source code). Of course, all of his records for the past 10 years were in this and you think I could get ANY info on the specs? Haw.
So I call their technical support in Vancover (I'm out here in Ontario) and guess what...
TECH: Whats the problem?
ME: Its giving me error code #03-02-somefile.ext-29-3294.2093 (yeah.. nice error code there).
TECH: Oh? That error never happens.
ME: Well it's happening... what does it mean?
TECH: It means that somefile.ext doesn't exist. But that file isn't needed by the system anyway.
ME: So?
TECH: Uhh..
ME: How can I fix it.
TECH: Click on the dial manager icon and I'll log in to fix it.
Okay, he's being nice about it. Calling in long distance right across the country to look at it himself. They spend nearly 12 hours straight working on it.
Next day...
ME: So did you find the problem?
TECH: Well, we downloaded the whole system and got it working here.
ME: Great! So can you upload it to this system and have it working?
TECH: We tried that, but it doesn't work on the system.. must be a hardware problem.
ME: But they bought the EXACT system that you asked them to and had it checked out by a fully qualified technicain several times (yeah, so I'm a measly PFY with lots of technology certifications).
TECH: Oh.. Maybe it's Windows.
ME: You think?
We went through fixing several files and what not.. no success.. they went back to using the old computer. Eventually they sent the HD over, the tech fixed it and sent it back. Happy ending.
Know that in this persons other office (he has two nearly identical offices in 2 seperate locations) I had done a flawless upgrade of his other system (everything is identical except for the records in the system). Nothing wrong there.
Oh well. c'est le vie I suppose.
Sometimes techsupport means you talk to a programmer or someone who has indepth knowleadge of the program and it's quirks. More often than not you get stuck with some secretary with a rolodex of possible issues and possible ways of fixing them. If the solution isn't there it depends on the company policy of handling exceptional errors... and we all know how Microsoft deals with exceptional errors (BSOD).
;P
Operating Systems on a Boolean Scale (Score:1)
It's either good or bad.
It's either Linux or not Linux.
Perhaps he should have said, "...AIX is an excellent OS, though obviously not as excellent as Linux..."
Why is there no spoon?
Re:Don't worry? DO worry! (Score:1)
Not to totally mess up your decision... (Score:2)
Re:AIX ? Great ? (Score:1)
so you people can talk it down all you like. It's my commercial OS of choice (I'd rather run linux) unless we're talking about orable, then it should be slowaris as discussed earlier in this topic.
Re:Don't worry (Score:1)
It's the same everywhere. Show too much initiative and competence, you will be moved up to management and you get to manage a group of morons. Now, instead of you doing what you do best, you end up pushing paper while your squad of morons "help" the clients by telling them to re-install Windows.
Re:Bah! (Score:1)
Actually, it's kind of funny what really happens in IBM. I am working on Websphere at IBM, having lots of fun testing it, developers just love it when I show up with new defect reports. Websphere group never blames anyone else but other Websphere people. There must be a couple dozen different departments working on WCS.
finger pointing (Score:1)
Re:AIX ? Great ? (Score:1)
Specific Config:
8 Processors
4GB RAM
90 GB SSA (Mirrored down to 45 GB)
and most importantly...
2 black cabinets the size of fridges.
This box makes you remember the good ole days in terms of size!
Re:There is no problem (Score:1)
You can tell me that one again, OTOH hand they should be telling you that. I deal with 60 different systems, and probably 30+ Vendors. One of the most difficult things is dealing with vendors who *WON'T* just say " I don't know ".
IBM is very bad for taking on things that are hideously complex, and just throwing a low-level grunt in to maintain and fix it, without any clue as to how it really works.
I've had to deal with more than one problem caused by the newbie IBM guy.
Re:Start Over! FYI (Score:1)
Re:Hah? (Score:1)
AIX has an unmatched volume management facilities, it integrates well with other vendor Unixes and it is sufficiently BSDish for me to feel at home while working on it. Very close to the perfect OS, indeed
Better yet (Score:2)
I dont fear that. (Score:1)
Re:There is no problem (Score:1)
My advice if you're going to go this route is as follows:
- In cases where very specific skills are needed, make sure the support people provided really do have experience. You can ask for business partner support if they don't.
- Understand carefully what the limits of IBM's support will be. Often we will manage the support, but will not be responsible for it if the software really goes wrong. A subtle but crucial difference.
But we aren't half bad at it, if I do say so myself.Multi-vendor support (Score:1)
IF it happens, ask the provider for any additional information that they can give you that will help document their companies position and get their name and a "ticket number" to reference when you call back. DO NOT try to pretend that you haven't called on the issue before, if you get "busted" you will be far less likely to get assitance if you pull that one.
If at all possible, try to set up some sort of conference call between the providers. Getting everyone involved can be a really positive thing.
Consider an alternitive resource for support, there are pay-per-call companies out there that do a great job of troubleshooting and resolving issues.
Don't forget to access the different companies websites for support information before calling! If you can't find the answer, then call but stay armed with the info from the different documents, that way you can quote from them and keep the person on the other end on their toes.
Again, I want to stress that a lazy employee is probably the worst enemy that both the company and the customer have. Just because you get a bad apple, don't assume the entire batch is bad! Of all the calls I've taken, I think those are the ones that bother me the most - because I really do try to help and try to keep my skills current. I know there are others who don't do as well and I am ashamed to work with them but these days sometimes companies have to settle for the help they can hire, not the help they want. I assure you these folks will be the first to go when the labor market loosens up a bit.
Eternal Vigilance is the price of freedom. (Score:1)
An actual answer to the question. (Score:5)
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
Re:Preventing Vendors From Playing the Blame Game? (Score:1)
You can Single Source AND Multi Vendor... (Score:2)
If you can find a Value Added Reseller that supports the combination of products you want to use, of course.
But, be very picky about choosing your VAR, as many are little more than fly-by-night operations.
Of course, most VARs will just try to convince you that what you REALLY need is what they already offer, 'trust us, we know this stuff!'. Don't beleive it unless they can show you.
A truly good VAR will listen to your needs, and try to support your choice of products with a comprehensive support contract. That is, of course, what 'Value Added' means.
--
Re:You cannot escape (Score:2)
You are dealing with individuals -- people who may have a multistate territory, people who might or might not have been well-trained, people who might or might not have natural aptitude for their job. They'll do a lot better if you gently steer them toward the problem and help them be calm and logical about it.
Support people, especially field support, see the worst side of their customers and the products they support. They might secretly (or not so) think that you are a moron and the product they support is a buggy POS. If you're being unpleasant, they'll act to get you off of their desk quickly, which means run through the flowchart looking for interaction with other products. As soon as interaction is found, they'll tell you to go double check it and hope that you call back after their shift is over.
Re:Simple solution (Score:1)
Nice try, sparky. Just keep slugging, champ. =^)
-legolas
i've looked at love from both sides now. from win and lose, and still somehow...
What are your issues with WebSphere? (Score:1)
Have you considered open source Enhydra? Then you can have multiple sources of support.
What about Linux, PostgreSQL, and Enhydra combo?
Re:Don't compromise, be an adult (Score:1)
If you don't want any responsibility in this, then you can outsource the entire effort to a managed service company. But don't be surprised when the CFO starts asking what it is that you do for your paycheck.
Just be prepared (Score:1)
All you need to do is thoroughly narrow down the problem until you find it's source, and DOCUMENT what you did so you can explain to their tech people what steps you took. That way, they can either tell you to test a couple other things to make sure, or they will go, "Oh, you did that? and it did what? Hmmm... Okay, let me get back to you."
Ah, progress! You now have gotten them to realize that it may just be their problem and they can't push it off that easily...
It's all very simple, really.
----
Lyell E. Haynes
Lame posting this as.... (Score:1)
Re:Don't compromise, be an adult (Score:1)
-Bongo
Fear not (Score:1)
Stop worrying about blame, think, and solve all the "problems" as they come. Pick the best technologies with the best track records to keep the problems to a minimum. Sun, Oracle, Bea Systems or I-Planet.
Be a computer engineer, not a blame engineer. Succeed or fail and take your due of the credit and the blame.
Deal with like people and do not fear anymore.
Simular Problem (Score:2)
Fast forward a month, when it comes time to pay the bill, i get not one, but two. The first dealership just dripped with incompetance, and forgot to cancel the initial account. Ok, so i call Roger's tech support to get this corrected... only to find out that want me, personally, to go back into the incompetent dealership to make them fix the problem, despite the fact i had no contract with Rogers on that number, and that it was an internal screwup.
The point of the story... yes, while they kept putting the onus on me to fix the problem their incompetence created, I kept insisting that it was their fault, I had no contract for that number, and therefore was under no obligation to fix it. I kept increasing the asshole factor (asking to talk to the supervisor, etc.), until eventually they caved in, and the supervisor personally called the incompetent dealer that messed up, getting the problem fixed.
The lesson to be learned is that... well, put enough pressure on them when it is obviously their responcibility, and wonderful things will happen. =^)
-legolas
i've looked at love from both sides now. from win and lose, and still somehow...
Entreprise Alternative (Score:2)
1) Human resources.
How many administrators and developers can you bring together with good knowledge of those IBM components (AIX, Websphere, DB2)? Here Linux or FreeBSD clearly beat AIX. For webapplication developers with Java and RDMS skills the scale (for now) is probably a bit more even, due to healthy competition [google.com] between the different webapplication frameworks.
2) Product Continuity.
The basic architecture you lay down now will probably be around for a few years, maybe even more, so having your products evolve in sync with new standards is very important. OSS projects, by their very nature, nearly always tend to more aware of interoperabillity than their closed source equivalents.
3) Security, Robustness, Scalability, Performance.
I think the the OSS models, in general create products that score quite good on each of these points, especially when they have been activly developed on during more than a few years.
4) Product functionality.
The XML and Java features of the Java Apache Project [apache.org] or the entreprise ready Enhydra server [slashdot.org](with commercial support from Lutris) are already more advanced than those of the IBM Websphere modules [ibm.com]. Combine that with an excellent RDMS (with full JDBC driver support) like PostgreSQL [postgresql.org] and I think you got an excellent webapplication platform that is able to quickly evolve with future technology extensions.
- just my Euro 0.02c
Re:Start Over! FYI (Score:1)
Re:Bah! (Score:1)
We wanted to implement an ecommerce site with our main bussines and some e-stores. That's suposedly the use, right? The fact is that we couldn't. We used some base classes and that's it. We ended up taking some of the product data model. But even that was brain dead.
Let's take for example the attributes tables. That's a great idea (which everybody also had) with a horrid implementation. Instead of using a separate table for attribute names, are use as PK! Soy you kill any usefulness to put intelligence in your software. Or you end up setting up a new table with the attributes names (doing what should have been done in first place). You have some sort of object inheritance, But instead of going the whole mile (that's an expression?) they simply left it as a product/item relationship with nothing else shared.
I don't see why te names are all 8 char. That's unacceptable. Particularly when your supported plataforms do support longer names (Oracle and DB2). You also couldn't keep the same name for a FK row and the pointed row? Come on guys?
I will simply say the Catalog Archtech is such an ill concieved application that I spend se least productive day in my life convincing myslef that the're wasn't anything useful in there. Not to mention the fact that precludes te use of the little inheritance that you have.
And the whole model is ridiculous! You only have e-stores and the products are linked to them. You can't have a single catalog. You don't have stocks management. The cart is a the least friendly thing I've ever seen. And there's no way of mixing data from different estores.
But I have to admit that VisualAge is une fine editor. And the JVM is the very best thing ever. We actually ended up buing the database and Java suporting (and enabling) components. And as usual the whole enchilada wasn't availableunder Linux. At least the instalation scripts weren't broken (ejem Oracle, Informix) and hasn't hardcoded path to libraries and applications (Ejem again! Oracle).
been there (Score:2)
In a sentance, nothing beats having skilled employees that know there stuff!
Ands it really does not matter what OS/ DB/ EJB's you use, it matters more how well the people that you are getting to do the job, know what they are doing.
send flames > /dev/null
Re:Better yet (Score:1)
Nobody seriously posts like that on Slashdot unless they're
1) Trying to be funny or
2) trolling
Re:Don't compromise (Score:1)
Re:Don't compromise, be an adult (Score:1)
___
Bingo! (Score:2)
Not that this is purely an IBM thing. I've had support people at several major corporations try to give me the run around, pass the buck or blow me off. Having been on their side of the phone, I can generally spot this and I don't put up with it. If I have to call support, I'm having a problem their frontline has never seen before and I'm not about to put up with some $8 an hour phone monkey jerking me around. I tell them that too, and ask for their manager. I tried to provide the level of support I'd want on the front lines when I was working the OS/2 support desk at IBM Boca and my manager told me that if I didn't get my numbers up, they'd fire me. Most of the frontline drones are idiots, because the smart ones either get promoted out rapidly, quit in disgust or get fired because some fucking bean counter would prefer quality to quantity. I ended up getting promoted out of phone support at Boca, in record time.
Re:It's for the adults! (Score:1)
I deal with this everyday, here's how... (Score:1)
My tips:
1) Pre-arrange response times and service levels with each vendor. Know exactly how long before they can have an expert on the phone with you. Don't confuse this with general tech support response time. The first person that picks up the phone usually can't solve your issue. Know the names and skills of the people in support in advance. Make the vendor supply you with names. titles, phone numbers and written escalation plan for their support group.
2) Do research before calling. Do some basic trouble shooting before picking up the phone. Have software/hardware version levels ready to go. While your vendor *should* have this info, they never do.
3) If you have two systems and you can't decide which is at fault, ask the vendor how to eliminate the other guy as the problem. For example if you can't decide if vendor A or B is a fault, ask vendor A how to prove it's not vendor B. This turns the problem around. Usually they get focused on proving it's not their own gear.
4) Put the involved vendors on the phone together to help them hash it out. I have gone so far as to get engineers from two companies to stand in front of the problem system and we all looked at the RS-422 analyzer together to agee who was at fault.
5) Escalate a problem up higher. If you aren't getting the support you want, escalate to higher levels of both technical support *and* salees/marketing. Never forget how much power(wrath) the sales guys can bring on the support guys. In most companies the management chains of sales & support join up rather high. So if you complain loudly to sales, usually a person fairly high up hears and issues a "fix it NOW, I don't want to hear about this anymore" order.
Good luck.
Dealing with BEA support on WebLogic (Score:1)
First, going with BEA is the right choice on the EJB front. I don't mean to be all conceited, but WebSphere really sucks. In competitive situations, we found that WebSphere couldn't point to a single marquee customer which was using their EJB technology in a production site. Their Servlets and JSPs were okay, and their JMS definitely was better than WebLogic's, but their EJB infrastructure was pretty much unusable. An ironic thing to note here is that one of the largest systems integrators working with WebLogic Server is IBM Services....they don't even pitch their own product for their own customers. That should be a sign of the relative strengths of WebSphere vs. WebLogic on this front.
BEA's technical support people are extremely overworked. It's just a fact of life there after the BEA acquisition of WebLogic that BEA hasn't spent that much on the technical support infrastructure. However, there are two mitigating factors there:
Specifically on your choice of Oracle for the database, I'd recommend that you think again. The Oracle model of concurrency control makes doing serializable transactions damn near impossible for real-world EJB-enabled applications, and you'll find Oracle rolling back your TX_SERIALIZABLE transactions all over the place. Either move to a different DBMS (DB/2 rocks, actually....), mark your transactions TX_READ_COMMITTED, or be prepared for constant rollbacks of far-along transactions at COMMIT time. Unfortunately, there isn't much of an option otherwise, because Oracle does crazy things internally to try to maximize concurrency at the expense of transactional semantics. Think carefully about this one!
In short, WebLogic rocks, DB/2 rocks, AIX rocks, and if you know how to work the system, WebLogic support is the best of the three.
Kirk
Re:Fear this! (Score:1)
One of the best things that the TPC has done is start on TPC-W, which more correctly simulates the workload that you're going to do in a web application infrastructure.
The TPC-C schema and data set are intended to simulate a bank network, and as such there are virtually no transactions which will cross some pre-defined Boundaries, which means that you can partition the data and applications very easily across a cluster. That is NOT true of web workloads.
Web Workloads tend to have a bunch of small transactions, which have some very big SELECTS as part of the transaction (such as integrating catalog data with personalization data). Those things can't very easily be partitioned across a cluster, so TPC-C numbers are irrelevant.
All TPC-C checks these days is how good your TPM (Transaction Processing Monitor) is optimized for TPC-C, that's it.
They're irrelevant, which is one reason why people like Amazon will never switch to SQLServer 2000.
Yes, but... (Score:1)
But much worse, will Enhydra, etc... do to them what Linux has done to SCO? Or Apache to IIS or Netscape?
Re:What's the problem with Websphere (Score:1)
Since the question was specifically on EJB support, I can't believe that he could really want to go with WebSphere.
Re:Certification (Score:1)
Re:An actual answer to the question. (Score:2)
What I hate is when you get clueless tech support people who don't believe the customer can do anything right, they don't believe you when you narrow anything down and at best make you go through every step with them on the phone and at worst, simply ignore your information.
I've talked to a *huge* range of tech support people. One guy, a CS Major, helped me with an interpreter I was writing in C while we were waiting for another machine to reboot. And another guy didn't know that Windows used the
But it's more than the tech skills, both of those guys were helpful because they helped me narrow down the problem, from both ends at once.
Once I called a guy at my cable-co's tech support and he told me to reinstall Windows because I couldn't connect... Idiot didn't listen to me saying my friend on the same segment was unable to connect and that I thought it was a DHCP server... Lo and behold, I call back and the next tech support guy says "Oh yeah, we lost the DHCP server
Anyways, I think the ability to listen to the customer is very important, anything else and you might as well just be listening to an automated message listing the correct settings.
Beating the blame game (Score:2)
Tech's notes on avoiding the run around with commercial vendors:
* Document everything. Every configuration from the Prom to the OS to
the details of your custom application must be in hardcopy.
* Don't call anyone until you have every relevant piece of information
you can imagine (and there will be some that you can't imagine).
* Keep daily tabs on the products you use- Subscribe to the newsgroups,
announce lists, etc., check one of the Usenet searches like deja weekly,
join a users group.
* Train at least two people in your organization on each product
and make them responsible for it. Get backing for a policy that no
closed-source, proprietary, or commercial product can be used unless
there is in-house knowledge.
* Call the sales reps and pre-sales engineers monthly and ask them about
patches, notices, updates, etc.
* Never buy a product that only runs on one platform or with one
back-end. Best-of-breed also means best chance of survival, so don't get
locked in.
* Fight against using proprietary or non-standard anything when
possible. Stay as flexible as possible but don't think for a second that
open-source will save you from a knowledge deficit.
* Always have more than one product of a given type under testing.
* Negotiate with multiple vendors but try not to let on with which ones
you are in contact.
* Get a support contract from the vendor and from a third party. Use the
third-party to hassle with the vendor for you.
* When selecting a product try to get a written statement that the
product works as described and what the vendor's responsibilities are.
Run everything past your legal people.
A Possible Solution (Score:2)
The key to resolving these conflicts, as far as we have determined, is knowing EXACTLY what the problem is, what is causing it, and then contacting the appropriate vendor.
Every vendor product has a well defined (at least, in theory) interface and functionality for their product. For example, an Oracle database will have an API for the embedded SQL library, and an ORB vendor will state their CORBA compliance.
If something is not working correctly between components, it is either user error, or a flaw in the component. (or unsupported functionality, but you should have verified this before purchase right?
At this point, you know exactly where the problem lies, and which vendor owns the problem.
Throwing Money At the Problem (Score:2)
And even when you do get the actual vendor will they even care. Will they speak f*ck'n english? A former tech support person for a major database company once told me that it was standard practice to blame it on the OS first. If the customer was actually able to prove the problem was with the DB then they'd submit a bug. But the point was it was up to the customer to do all the leg work.
I think we as techs are to blame though. It's our way of doing things in IT. You've seen the SNL skit with the bastard tech support people. Sure they couldn't get the terms right if their life depended on it, but the point is we have huge ego's and little personal responcibility. Even played the blame game inside the company when someone left?
BOSS: "Why isn't this project done?!?!"
TECH: "Ahh..yeah..Habib was supposed to do that before he left the company."
BOSS: "Damn that Habib!"
At any rate, it's been said before, quality people. Also, if you have the money, go with a vendor that will offer "internal" classes for the product. HP for example has special "Internal Use" classes they will let customers go to. It might cost a little more. Hell, you may have to send your people to the UK for them. But it's well worth it to know what's going on under the hood.
Re:You cannot escape (Score:2)
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.
That's exactly the key to dealing with this problem. I used to deal with a lot of escalations for a big company that offered services (not IBM). One of the things that happened several times was the client started screaming "we're paying $XXX/hr to you, and we expect it to be fixed now!" So the junior person panics and starts pointing fingers. The whole exercise adds tension, confusion, and bogus data to the mix. To avoid this, ask the person to do two things:
Re:Bingo! (Score:2)
I have a couple Linux boxes that I do all my work on. Once I needed to export a directory through NFS to an AIX box. It didn't work because the NFS version that Linux supports is a version out of date.
I was pleasantly surprised when I called AIX support that they did no finger pointing at all. I was expecting it. Instead, they diagnosed the problem accurately and told me how to get AIX to recognize the older NFS version that Linux uses. No sweat.
On the other hand, AIX has some truly brain dead 'features' such as a grep that chokes on lines over 2048 characters. Duh!
Definitely stay away from Web Sphere, and maybe consider Linux over AIX. But if you do go with the IBM stuff I think the tech support will be better than what you'd get from other places.
One stop shop. (Score:2)
Although this sounded like a good idea, practically it was hopeless. We had to farm all hardware support out to a 3rd party, and finding a competant 3rd party that was aware of our OS was impossible. We also had to learn all the applications and other tools used by the customer, not all of which we had supplied.
One customer was a nightmare. They used us for everything. They'd call us for support on a DOS application that was over 8 years old, wondering why it couldn't handle PentiumMMX processors. They'd call us to download printer drivers for their 5 year old printers. They'd even get us to call hardware engineers to clean a mouse. Yet they wouldn't upgrade their network to even a remotely current release!
Eventually we stopped doing hardware, as we were loosing money.
Re:IBM plays with itself..... (Score:2)
Heh, I had a good experience with their storage group in Austin when I was working for their Internet Division in White Plains.. Had to get a 7135 RAIDiant array working with AIX 3.2.5, but the controller and drive microcode apparently had issues with the most recent PTF sets (thank you fixdist!) loaded on the box, so I ended up being escalated to an engineer who helped design and build the thing, and he FTP'd me the latest microcode fixes that day, had everything working fine the next..
The next best thing to opensource!
Your Working Boy,
How? Use TSANet. (Score:2)
Before you buy, make sure that your prospective vendors are members of TSANet [tsanet.com]. Then, if one of your vendors points the finger at another, tell them to use TSANet to open a ticket with the other vendor on your behalf. As a support engineer at Tivoli Systems, I've used TSANet to open tickets with other vendors in order to resolve customer problems.
Re:There is no problem (Score:2)
But then again, you're no better off going to the original vendors either when it "really goes wrong". The EULA clearly states their limited liabilities in such circumstances. For software buyers it's always caveat emptor and there's no way out of that I'm afraid. On the other hand, when you buy support from a big player like IBM at least they are in a position to exert more pressure on the software vendor to fix problems than you would be by yourself. In theory anyway.
Consciousness is not what it thinks it is
Thought exists only as an abstraction