Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

Tue Dec 27 20:10:08 UTC 2016

In a message written on Fri, Dec 23, 2016 at 03:36:10PM -0500, Chris Grundemann wrote:
> If you have a case study, lesson learned, data point, or even just a strong
> opinion; I'd love to hear it!

I think the high level items are pretty clear here:

1 Vendor

Quicker/easier to implement, staff only needs to learn/configure one
platform, vendor can help end to end, usually fewer interop issues.
Spend may get extra discounts or support bennies.

However one bug can wipe out everything, no ability to compare real
world performance with a competitor, vendor may think they "own" you
come renewal or more sales.  Hard to threaten to leave.

2 Vendor

Can be implemented multiple ways, for instance 1 vendor per site
alternating sites, or gear deployed in pairs with one from each vendor
up and down the stack.

Harder to implement, staff needs to know both, all configs must be
done for both, vendors will always blame the other vendor for interop
issues.  Twice as much chance of needing to do emergency upgrades.

More resilliance to a single bug, can compare real world performance
of the two vendors.  Both vendors will compete hard to get more of your
business, but have a harder time justifing bennies internally due to 
lower spend.

3 or more Vendors

Generally the same as two-vendors, just ++.  That is more of the
pros, and more of the cons.  Limited additional upside to having 3
or more active vendors.  Generally occurs as a vendor falls out of
favor, two new ones get deployed moving forward, the old one sticks
around for a while.

Having worked places that were single vendor, 2 vendor, and "whatever we
can buy" shops I'll say it basically doesn't matter.  What matters is
how you set up the org.  Want to be lean on staff, go single vendor.
Want maximum resilliance and/or negotiating power, go 2 vendor.  Inherit
a mess, learn to live in a 3+ vendor world.  It's not that one is better
than the other, it's just they require different approaches to get the
same outcome.

-- 
Leo Bicknell - bicknell at ufp.org
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20161227/55d975b8/attachment.sig>