Why Standards Matter…And When They Don’t
The year was 1992, Disney’s Aladdin was the top grossing movie, Garth Brooks had the top-selling album in the US, and I was a freshly minted SE. Being a studious and diligent SE, I read up on all the gear sold by the integrator I worked for, and I decided that the Wellfleet BCN was the product of choice for our customers based on its hardware architecture and the impressive list of standards to which it laid claim.
And, then a funny thing happened…I learned that, while customers value standards compliance, what they value even more are networks that work and do what they need them to do. And herein lies the inherent contradiction of networking standards and the constant tension between innovation and standards.
Ultimately customers look to us to address their problems: “I need my network to _________ (fill in the blank) so I can support the needs of my business–oh, and I’d like that ASAP, please” . Luckily, our customer base is not shy, so when we see a trend, we move to address it and put solutions out there for our customers. This is where innovation is critical–having the ability to continually move the ball forward to ensure networking continues to meet the needs of markets that are themselves continually evolving.
But, ultimately, standardization is the end goal. Without standardization, innovation cannot scale. Time and again, we have seen that if a technology is balkanized, it stalls because no one wants to choose poorly (on a somewhat related note, I have a fine collection of HD-DVDs I’m willing to part with at a fair price).
The folks on the left of the chasm are the ones that demand innovation because they see it as a way for them to create competitive advantage in their industry–they balance risk-reward differently. However, the whole industry benefits because early adopters are willing to test and validate new concepts and technologies so everyone can see what really works. But even with a validated concept, for a new technology to truly take off, the folks on the right side of the chasm are looking for some measure of safety–whether it is the safety-in-numbers of a de facto standard such as VMware ESX or Microsoft Windows, or more formal standard such as the IEEE 802.3 Ethernet. Either way, by mitigating risk, adoption takes off.
So, if standards are so important, why does Cisco have all these proprietary protocols? Well first off, its important to recognize the IT market has always been driven forward by companies willing to take a leadership role–heck, the framing format for the poster child of open standards, Ethernet, was initially defined by three vendors (Digital Equipment Corp, Intel, and Xerox) before the IEEE picked up the ball.
Second, let’s remember the driver for all this: customer needs. Often the reason we introduce a new protocol is because there is an unmet need in the market (oddly, something the critics seem to forget):
- Cisco introduced Inter-Switch Link (ISL) protocol to scale VLAN technology, which was followed by IEEE 802.1Q spec (and now Cisco supports both).
- Cisco added extensions to Spanning Tree Protocol (STP 802.1D) such as PortFast and UplinkFast to support the layer two convergence times required by modern networks. Now you have the those technologies baked into IEEE 802.1w (which Cisco also supports).
- Cisco introduced HSRP to improve network availability which then served as a foundation for VRRP described in IETF RFC 3768 (again, Cisco supports both).
- Cisco introduced VSAN virtual fabrics with the introduction of the Cisco MDS to improve SAN efficiency and functionality and the technology was later adopted by INCITS (ANSI) T11.
- Cisco championed FCoE and DCB as a way to combat data center infrastructure sprawl and validated the unified fabric concept with shipping product. We now have an FCoE standard and we are well on the way to completing the underlying DCB enhancements to Ethernet
- The final example is the development of VN-Link and NIV to deal with interface virtualization in VM environments. Again, we have validated the technology with shipping products. Both protocols have been submitted to IEEE where they will be reconciled with some alternate proposals. The end result will be a standard that Cisco will support.
Of course, not every protocol we introduce makes it across the chasm and we are certainly not the only company doing this. But, in general, everyone benefits when companies like Cisco invest to innovate and create fodder for the standards process. Simply, if companies do not risk and innovate, the market stagnates. For our part, that translates to an R&D investment of 14% of revenues ($5.2B in FY09), which we essentially see as investment in our customer’s future success.
So, what does all this mean as you try to navigate the market place? Well there are a number of folks making noise about “standards compliance” as the idyllic networking end-state. I would respectfully disagree–standards-compliance is table-stakes–its merely the price of admission. The real question to ask is what else are they bringing to the table? What else are they doing to help you understand and–more importantly–take advantage of what’s happening around the next corner. I think, one of the reasons you see some folks desperately cling to standards compliance is because perhaps that is all they really have to offer.