Now I'm a big technology fan and it often makes me laugh when I am advised to treat to company's money as I would treat my own…if I treated it like that, we'd have a data-centre full of wierd and wonderful gadgets; projects half completed and strange bits of kit that I liked the look of on eBay. But thankfully for the good of the company, I tend not to buy technology for technology's sake; it needs to meet a need and fix a problem.
So I find it incredibly frustrating that often purchasing decisions are made without defining the problem; the biggest trap to fall into is to allow yourself to bound the problem in the vocabulary that your incumbent has imparted with you. Instead of replication, you talk about SRDF; instead of point-in-time copies, you think in snaps, instead of shared storage, you think in terms of arrays. This all normal behaviour but it limits you.
When a vendor turns up touting their wares, you should be asking yourself; 'What problem does this solve?' Don't let the vendor convince you that you have a problem; it is all to easy for that to happen and once you allow them to do so, you are halfway along the route to purchase order.
Before the vendor turns up, think of the problems you are having and then as your introduction/brief; set the agenda, 'How does your product solve my problem? Not what problem has your product been designed to fix'.
But try to define the problem in neutral, non-vendor specific terms; this is especially important at refresh times because often you have allowed the problem to be bounded by what's possible with the kit you have today; try and define the problem in green-field terms, start with a broad-brush approach before diving into the nitty-gitty.
So what's your problem?
Martin,
Great advice! This is especially true in homogenous shops where the line is very blurry……
Agree entirely.
We define this in terms of :-
1) Target architecture
2) Capability catalogue
3) Functional & Non-Functional requirement interface
4) Category Reference architecture
5) HLD(s)
6) Component Catalogue
7) Reuse Catalogue
8) Category Estate Mngt Strategy
9) LLD(s)
10) BOMs
It’d be a blog in it’s own to explain the subtle but vital details of the hierarchical document set – but suffice it to say that only at HLD do vendor technologies get mentioned or factored. All architectures have to be vendor agnostic, and focused on resolving problems and recording the requirements they meet.
This layering and SOA abstraction can look doc heavy but it’s not too bad, and focuses the mind on requirements not technologies. But it does bring it’s own problems (eg how to factor in game changing innovation, commodity is good but means ‘fit for purpose’ not best possible – both tech & commercial, SOA is a mental/culture change as well as paper).
Perhaps it would be good for people that hate a technology category to be the decision maker in that category – that way something has to be really required and of value before getting purchased?
Oh and I know your waiting for this so…
Of course any technology should only be looked at if it works against and existing requirement AND reduces the TCO / improves the benefit. Sadly very few technologies do this for the customer…
Of course, there is always the problem on how to handle game-changing innovation; the product which scratches an itch which you didn’t realise was there. This is where your peers come in, if you think it’s a great idea, it might be worth talking to your peers.
There is very little competitive advantage to be gained in the deployment of IT infrastructure; this was a lesson I learnt when doing competitive analysis of Retail Banking systems twenty years ago.
agree re peer communication – one of the most valuable tools around for validating many things, and I’ll continue to do it as much as possible within legal confines! And we need to do more of this as an industry…
But not so sure I’d entirely agree with your statement of “There is very little competitive advantage to be gained in the deployment of IT infrastructure” – as I feel there very much is in a number of technology areas (architectures & approaches). Particularly where the tech enables a genuinely more agile & unburdened approach to infrastructure. For example cloud type technologies can allow costs to be aligned to success / failure of the project rather than all up-front, thus the business can try more things with less IT infrastructure ‘write-off’ fear. But agree that for storage area there’s little / no competitive advantage between customers who chose different type of array supplier…
Okay, the window where competitive advantage can be achieved is actually very small. If you deploy something and it is successful, you will find that your competitors follow very quickly. Certainly in any sector which relies on co-opetition and standards this is very much the case.
Simon makes this point in the cloud presentation which is getting referred to a lot.
Martin
I am total agreement with what you say with regards to customers getting stuck using vendor terms and locking themselves in or constraining their options and thinking. When at EMC, I used to try to get people to think in more generic terms. i.e Point in Time Copies, rather than BCV’s, Clones or Snaps. And try to get people to look and thin beyond the initial percieved problem or requirement.
However I do agree with Ian that business can can competitive advantage with IT infrastructure and even storage. Yes the window of opportunity can be small, which is why IT needs to move fast to enable this competitive advantage. Something which I know is not easy within many IT shops !