Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cisco And Deloitte Wrong: Good Practices More Impactful Than Vendor Choice: Page 2 of 2

The buyer's market itself also seems split between single-vendor and multivendor networks, according to our own survey data. We've asked our readers this question many times (IT Pro Ranking: Data Center Networks and IT Pro Ranking: LAN Equipment--free, one-time registration required), and the responses remain about 50-50 either way.

Jim Thomas, director of IT operations for Pella Windows, prefers a single-vendor approach. "If I buy all of the my network products from one vendor, the vendor has probably tested these components together in a lab, likely put the same set of products in the field and should have experience with that particular combination of products," he told me in an interview. "That means the products will likely work well together and, in the case of a problem, we'll get quicker resolution."

Greg Ferro, a network architect and designer based in the United Kingdom, takes a different tack. "Single vendor or multivendor is in the eye of the executive that thinks if he has one less vendor or supplier that his life would be simpler. The reality is that all of the product divisions within big companies are individual entities anyway. You aren't going to be dealing with a single person on a problem or a product--you will deal with the product specialist from each business unit. The problems and their solutions don't change when you have a single-vendor policy. It doesn't change anything at the operational level. "

Deliotte's report estimated that the cost savings of a multivendor approach could be wiped out by a single networking catastrophe. That's a silly scare tactic based on a set of cascading assumptions and dependencies. To be true, there would have to be a failure that is catastrophic enough to affect a large portion of revenue generating apps, and the failure would have to be due in whole or in part to a multivendor environment.

Finally, the resolution would have to made significantly more difficult due to the a multivendor environment. That is a whole lot of dependencies that have to fall into place to lay the blame on a multivendor network. Good engineering and operational management can mitigate the likelihood of an outage and reduce the severity and length should an outage occur.

There's no rule of thumb to go by. The decision to go single vendor or multivendor should rely solely on what you're trying to do and what fits best for your technical and business objectives. Neither a single-vendor nor a multivendor approach is inherently better or worse. You have to assess the benefits and drawback of each.

If you go single vendor, you get one account representative for sales and support, hopefully better buying power and the comfort of knowing that you have one throat to choke. However, you may also end up with inferior products that don't fit or perform as well as others. If you go multivendor, you may end up with more integration work and fewer discounts, but you are more likely to build an environment that is closely aligned with your objectives. However, if products from different vendors don't work well together, you have to lean on them.

Only you know the right answer for your organization.