Network device command line interfaces

Fri Nov 25 00:16:33 UTC 2011

Doug Barton <dougb at 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