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@ufp.org PGP keys at http://www.ufp.org/~bicknell/