This isn't just a criticism aimed at the Storage industry, it can be aimed at IT vendors and consultancies in general.
At some point it is useful to have some idea of the real world and how it works, I can cope with the 'La-la Land' world view of sales-men but I think it is important that the vendor TCs/SEs or whatever you want to call them have a grounding in reality and how things work.
It would also help if the support guys/developers that you employ also have a reality-based experience. For example, an appreciation of change control and configuration management would be extremely useful; so that you don't merely expect us to roll-out new code at a drop of a hat.
Vendors also have to appreciate that we do not build environments just using their kit; even the truest of the Blue companies have other vendors on the floor. And it is only really 'Big Blue' which stands even half a chance to be able to do this. Environments are complex and inter-connected; just shaking your head and saying it's not supported will a) not stop us doing it and b) not stop us shouting at you when it breaks. You guys have got to learn to talk to each other!
Let me make a humble proposal; every five-ten years, you encourage your technical staff to take secondments to a customer for upto a year but certainly not less than three months. You will learn so much from this that the investment has got to be worthwhile and you will have technical staff who can really appreciate what customers are trying to do.
You might even get some great ideas for new products. It could be the best market research you ever do.
now there’s a thought… actual secondments though, not simply working on-site… Would need some logisitcs things to be sorted re permissions, info disclosures etc but I could see this being rather useful. I’d also think the the secondment needed to be to a customer they don’t have any contact with during their normal role (ie not just seconded to ‘their’ account).
It always ammuses me (as I’ve simply no other reaction left) when we ask for copies of the partner/vendor’s processes & SLAs for interop, enhancement or change requests – so far (in 5yrs of asking) none of the storage guys have been able to give a document on this… If they don’t think about it internally then frankly we’ll always be on the losing side re this…
My reversal on that is that it would be a good idea for people who don’t build products for a living to try their hand at designing, building, testing, shipping and selling.
I hear a lot of stuff about supporting this that or the other or shipping this that or the other technology and it’s always as the customer is doing their utmost to get the gear for as little as possible.
So we should hire all those engineers to do all that work out of the massive margins we’re being allowed to make per unit?
Well this is enterprise hardware, there are no massive margins and whoever says so is an out of touch moron. There’s just margin and it’s a bit more than the person selling whitebox servers all of which are built by the three or four same companies under contract. Discounts come directly out of the margin before anyone even sits down to haggle a price.
The reason we spend money qualifying supported configurations is so we can take out expensive support costs by shaking down code. In our case we do a hell of a lot more than what others do, and looking at some of their support matrices it looks like they plug in a few cables and see if the lights go green before ticking the box.
But the flipside of that is that we won’t support whatever config someone has pulled out of the air.
How much more are you willing to pay to make that happen?
(I know the answer is nothing)
Zilla, just perhaps a few of us have worked both side of the fence.
Actually, I’ve found EMC often very good about supporting random configurations; sometimes because I think that they are intrigued at how we’ve got something working which never should have.
There are changes that I am aware of which should make the support matrix more manageable from a user point of view.
But hey, perhaps a two-way programme? End-users to vendors and vendors to end-users.
Zilla – sorry for apparently hitting a raw nerve, but as Martin says some of us have worked on both sides of the coin… We know it’s not trivial but we also know the impacts on both sides. And the current model & processes simply aren’t sustainable on the customer side at all.
Re Margins – don’t forget we see the discount levels different customers get (IDC smartindex etc) so we do know that there are vendors getting good margins out there!
I guess what I’m saying is :-
1) Can we have some focus and effort on getting documented processes & SLAs around the interop, RFE, RFC areas?
2) Is there a way to engineer & architect products so that there is less of a requirement or impact within the technology stack? (we now judge on a 5 or 7yr TCO)
3) Remembering legacy support is a key thing
4) Providing more disclosure on interop matricies (ie why something isn’t support – eg failed, not tested, used to be but OEM not supporting either now etc) will help
5) Exposing more of the product & development people to the real world can only help us all (retailers make HQ staff ‘work store hours’ for a darn good reason) – and I’m very sure customers would offer whatever info etc they could to help
Oh and I’d like to see where those ‘expesnive support costs’ have been taken out from, as our annual support bill to vendors could buy a small country… 😉 We often wonder it it would simply be cheaper to buy the partner…
I remember Powergen setting up an IBM reseller just so that they could get better discounts especially on support.
Look, we all know how this game is played. If the price is anything above free customers are going to say it costs too much.
Support? Oh that costs too much. Anything I can think of? Costs too much. I heard a billion of them and they all come down to the fact that customers don’t want to pay anything for anything if they can get away with it.
If I said someone could have a piece of enterprise tin (Any tin) and the best software ever for whatever price they think was fair they’d push a quid across the table and ask me when they could expect delivery.
When it comes to interop I’d love to take an array and say “Stop development” nothing but bug fixes and interop work done from here on out. But how long would that array sell for? Well in that space of time between the next array or even the next new feature.
That is what has happened with the DS8000 after all and anyone you ask will tell you that’s a dead end product
It’s very difficult for me to swallow things like “The dev team should go on sabbatical for six months to get out in the real world” when in the same breath I hear “When are you going to support feature X? That other vendor supports feature X. If you don’t offer it soon I’ll go with them.”
Lather rinse repeat with whatever the technology flavour of the month is.
In this market if you want to be competitive you run as fast as you can for as long as you can.
Of course, end-users never want to pay for anything but at the end of the day; if we see value, we’ll pay for it. But this isn’t only about value, features etc; it’s about truly understanding your customers, truly understanding their business and really ‘grokking it’.
Have you any idea how frustrating it is for the upteemth time having a developer say, ‘just roll out the latest fix’ or ‘bring down the array so we can fully health-check’ or support telling you to go to the latest fix before they’ll help?
It’s not just EMC, IBM or whoever; its the whole sodding industry. The QA is generally appalling, when you get a TC telling you that they wouldn’t recommend you go to the latest release of a product because it’s not really production/enterprise ready but it’s okay for some poor sap in an SMB to risk his business on it.
For all the much vaunted test-labs, interoperability matrices etc; at the end of the day, too many products ship which just plain, don’t work. The beta-culture needs to die!
The problem with software being that it never ships “finished”, it ships when they’ve mapped all the major bugs and know what they need to fix next.
Software people have a very different view of the world than hardware people.
That’s okay then!
It’s fine to ship broken code?? (please don’t take that as a dig at EMC especially).