This is a topic I’ve been wanting write about for some months, but never got round to it. Why the title “Beyond The Matrix” you ask? Well, this article concerns the habit we have in the industry of making tables or matrix that compare one vendor’s product to another. You know the sort of thing I’m talking about are those that have the companies name at the top, followed by a big list of features going down a left hand column. Some of these will merely use an X to indicate a feature is present, and N/A to indicate that feature doesn’t apply.
Now. In principle I have nothing against these sorts of comparisons, and in a crude way they do help technical people quickly see who has what features and who doesn’t. Of course, on the vendor side we love it when VendorA doesn’t have feature X, but of course VendorA will endeavour to show that they have feature Y. Customers however must look at these range of features, and ask themselves if FeatureX or Y is show stopper. If they don’t use the feature its not important to them. Right?
Well, yes. Except I have a problem with this. Firstly, it assumes that product will always be used in same way for all time, and that nothing will change in the next 6/12/18 months that would make the absence of feature important. This I think is an argument to opting for the “top of range” or “best of breads” approach where the customer CYA their organisation by ensuring that they don’t hit a brick-wall or an upgrade-wall to access a feature they later need. Secondly, my problem with these sort of matrices is how they are used by people (not the folks who generate them – who I think in the main do sterling work often for free…) – there’s tendency to treat the Yes/No/X box as if it some definitive statement. So just because VendorA and VendorB have the SAME feature – that doesn’t mean its been equally well implemented; easy to configure; reliable. In short the problem with the Yes/X it doesn’t go beyond the matrix to tell you how good the technology is.
I think this is one of the classic scenarios we see in the world of technology. VendorA steals a march on its competition – and then there’s this mad “Me To” scramble to close the gap by the competition. Thus the competitor sales people have some ammo in meetings with customers to convince the customer that they have the same or better features. The same happens when features become “free” or “waterfalled” into lower SKUs. This has the disruptive effect of triggering competitors to match on price/function. That often works to the customer’s advantage – its called competition.
If I had my way I’d dispense with the X/Yes – and have it replaced by pint glass. The VMware pint glass would full or almost full, the also-ran competitor’s glasses would look half-empty, or show some dregs at the bottom. 😉
Of course, I’m joking – but only slightly. I would like to see these matrices go beyond a comparison of features. Perhaps adopting a scoring system (9/10 etc) or a traffic light approach – where green is an outstandingly implemented feature; amber medium quality and red when a feature is less good than a competitors. To be far I think the virtualization matrix is quite possibly the closest to this ideal I’ve seen so far.
But more than that I would like to see people really kicking the tyres on various products. The problem as I see it is that lot of people don’t have the time/money to devote to their own comparisons and that they are left to use resources on the net.
Perhaps there’s a big problem/challenge with the matrix approach. Does it actually influence peoples decision to adopt one technology over another? Probably not. Here’s why the folks who make the decision to adopt one strategy over another are NOT techies. They are extremely senior management people, who’s key concern is to drive down costs (to drive up profit). That, of course is alway filtered thru the prism of risk. Selecting one solution over another may indeed save money – but it does so at the risk of introducing a potentially substandard product into the infrastructure. In my view any potential cost savings have to balanced against introducing a new piece to the infrastructure which could buckle under the weight of demands it was never designed for…