Carrying on from my thoughts in Part 1: It’s time to start deploying purely standards-based infrastructure outside the data center; data center protocols are just starting to be created for a converged and virtualized world. With the amount of tested and deployed standards protocols, there’s no excuse for networks to be locked in to a certain vendor with proprietary protocols when standards-based network solutions provide access to compelling volume economics, flexibility to adapt a much wider array of solutions, and relief from hiring specialized talent to run a science project. Although many organizations understand that standards-based networking provides them with the flexibility to choose from the best available solutions at a lower cost of ownership, they still feel trapped. Listed below are three top shackles and the keys to open them up:
I was listening to a briefing the other day and got swept up in a Western melodrama, set against the backdrop of Calamity Jane’s saloon in Deadwood Gulch, South Dakota, revolving around three major characters: helpless heroine (the customer); valiant hero (vendor A, riding a standards-based white horse); and the scoundrel villain (a competitor, riding the proprietary black stallion) (insert boo and hiss). Vendor A tries to evoke sympathy at his plight of not offering the latest features because he doesn’t have the same powers as the villain and has chosen to follow the morally correct path, which is filled with prolonged and undeserved suffering supporting standards-based functions. What poppycock! There is no such thing as good and evil in networking. If the vendors were reversed in positions, vendor A would be doing the same thing as its competitors. Every vendor has some type of special sauce to differentiate themselves. Anyway, it’s business, plain and simple; networking fundamentally needs proprietary and standards-based features. However, there’s a time and place for both.
With that in mind, I want to let you know that I’m a big proponent of standards-based networking. The use of open standards improves the choices that help you reduce risk, implement durable solutions, obtain flexibility, and benefit from quality. Ninety-plus percent of networking should be leveraging standard protocols, but to get to that point features need to go through three stages:
The other day I was just reminiscing with a friend who works at HP about all the good times I had there with my ProCurve family. When I left for a once in lifetime opportunity, I had so much hope for HP’s networking division. Like many of my inquiries from global customers looking for a Cisco alternative, I’m concerned about the division and its long-term viability. I’m not worried if HP will continue to exist without Mark Hurd. Companies are more than a single leader. There is plenty of research, books, and online debates about the effect of a single person: Jack Welch, Steve Jobs, John Chambers, etc. The issue at hand is the existence of product lines within enormous companies, like networking within HP. One of my mentors always said, “If you look at networking over the last twenty years, no major IT company or voice vendor has been able to pull off being a serious networking vendor if networking wasn’t its first priority.” Fundamentally networking is one of the few technologies where a vendor has to be all in. The networking graveyard is full of headstones: Nortel fell off the face of earth, IBM sold off its assets, and Dell hobbles along.
Ah, you might say, what about HP? That brings me to my three observations that every IT manager should consider when including HP in their network architecture: