Doug Barton <dougb@dougbarton.us> writes:
On 11/24/2011 11:58, Jonathon Exley wrote:
That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with".
That's where you get a chance to impress the business folks by using terms like "total cost of ownership." You make the case that while product X may have a higher capex, that's a one-time expense that can be amortized and/or depreciated. Whereas the opex for product Y is going to be higher for the life of the thing. Make sure to tart up your estimate by including the developer costs of the tools you will need to verify that changes are correct and/or disaster recovery because everyone is human, and the horrible UI magnifies the likelihood of an "innocent" fat-finger mistake turning into a complete meltdown (or worse, a security hole that no one sees until it's too late).
What Doug said. Also, don't forget the value of letting the decision makers know the worst-case. It's not really FUD if you're just opening their eyes to the consequences of their buying decisions. For instance, if you can't back the config of the device up in a human-readable/mergeable format (or worse yet, can't back it up _at all_), consider the cost per hour of downtime on a 24 port switch with a bunch of random office workers connected whose fully loaded hourly cost (including cost of office space, health insurance, employer part of FICA, etc) is, um, let's be cheap and say $40/hour. Funny how this puts the cost of both CLI-based stuff *and on-site spares* in perspective. "We can't buy it if I can't back it up with RANCID because of the negative impact it has on our business continuity" is a good way to put this into terms that the folks who hold the purse strings can understand. -r