Do You Really Want a Nanny?
If you are a Cisco customer, or thinking about becoming a Cisco customer, that number should help you get a good night’s sleep. Why? Because it represents the percent of our revenue we devoted to R&D in 2009 – essentially towards developing solutions to the business and IT problems that you’re dealing with today or we expect you to see down the road. As a percent of revenue, that puts us in pretty good company between Microsoft (14.6%) and Google (12%) and well ahead of some other IT folks such as IBM (6.1%), HP (2.4%) and Dell (1.2%). Even in terms of absolute dollars, at $5B we are just behind IBM ($5.8B) and well ahead of HP ($2.77B) and Dell ($0.62B). (Source)
The customer benefit to this R&D spend is investment protection (i.e. we can afford to continue to invest in Nexus, Catalyst and MDS concurrently) and innovation with the development of new technologies such as extended memory on the UCS. In short, it reduces customers’ risk and allows us to act on their asks.
So, you would think all this R&D and the resulting products and technologies are a good thing, but recently I have been pulled into a couple of conversations where we were accused of hurting the market for some interesting reasoning.
The current object of our critics’ ire is FabricPath (a technology introduced to help simplify data center networks and better support today’s workloads) and its similarity to another standard-in-the-making called TRILL. Concerned folks are lamenting the fact that we are a) confusing customers, and/or b) subverting the standards process.
So, lets pull this argument apart a little bit and start with the “confuse the customer” part. Over my career I have met a lot of IT folks and as a group they tend to be a) pretty smart and b) pretty opinionated. I am guessing the vast majority of them are not looking for a nanny to tell them what to do and to keep them safe. To the contrary, I find most folks want to understand their options and have the freedom to make the best choice to suit their purposes.
As far as the “standards” angle, in this case, we actually co-chair the TRILL effort and have stated we will support TRILL and the hardware we are shipping will support both technologies, so I am not really sure how that subverts TRILL. There is not even a lock-in angle, since the Cisco hardware in question supports both FabricPath and TRILL.
The argument has been made that since FabricPath offers a superset of TRILL’s features, folks might choose FabricPath instead of TRILL. I guess, I don’t see a problem with that. If folks are focused on standards compliance, they can choose TRILL. If folks want certain functionality, they can use FabricPath. Net-net, folks should be allowed to choose what works best for them instead of their choices being artificially limited. In this case, there is also a time component, since if they need a solution now, FabricPath is their only option. But again, nothing precludes folks from implementing FabricPath to meet immediate needs and then migrating to TRILL once the standard is finalized. And, if the features in FabricPath are broadly compelling enough, they will probably end up in some future version of TRILL anyway.
At the end of the day, the fate of FabricPath and TRILL lies in the hands of our customers–they will succeed on their own merits, which is how it should be.
Finally, don’t get me wrong about standards. They are an important and intrinsic part of networking, but being open to innovation is just as intrinsic and what allows the networking market to grow and evolve instead of stagnating–I wrote about the balance between the two forces a few months ago.
So, dear readers, how do you strike the balance–when do you pick the functionality you need and when do you hold the line for standards compliance?