I’ve been using the phrase “SDN consumability” here and there of late, assuming that there was nothing particularly revolutionary in the idea. The response, however, is typically a cocked head, an interested look, and a question: “What do you mean by that?”
So here’s what I mean by that:
In order for SDN to see mainstream adoption, SDN solutions need to be/have
- Simple to operate – easy to deploy, low-to-moderate learning curve
- Safe and reliable – tech is stable, nothing blows up, no one gets fired
- No blue-sky requirements, limited DIY – tech and process migration support available
This isn’t rocket surgery. It’s an intrinsic part of the classic Chasm model, as shown below.
(By the way, here’s an even more true-to-life representation of the innovation adoption curve.)
The OpenDaylight Project recently found that 76% of network engineers want “open source SDN” (the, um, open definition of “open source SDN” may account for some of that exuberance)…from commercial suppliers. That doesn’t necessarily mean, of course, that incumbent networking suppliers should necessarily assume they automatically get to keep most of their business if and when the networking world goes all-SDN-all-the-time. The market is open for anyone—or combinations of interests—who can meet the following “Open SDN” requirements, according to the ODP survey:
Created using formal design and development practices
Validated by strict integration and testing procedures
Delivered and deployed via proven tools and techniques
Supported by trusted programs, processes, and people
If by “open SDN” we assume the use of an open-source controller, then clearly OpenDaylight has a critically important role to play in helping move SDN across the chasm, specifically with regard to those first two bullets.
The second two, however, are where ODP partners come into play. And here, it may be interesting for leading-edge SIs and consultancies—in addition to the obvious open source-focused “product” players–to actively engage with ODP on an ongoing basis. Services firms are not currently represented in the ODP member ranks, but are as well-equipped as any networking vendor—and better than many—to deliver on the latter requirements.
In the end, I suspect the leading “open SDN” implementations are likely to be delivered by triumvirates of classical network vendors (including SDN startups) and services/open-source firms, anchored by ODP. The three ODP controller “flavors” (Base Edition/Virtualization Edition/Service Provider Edition) incorporate various modules of interest to different market segments and are designed for easy optimization by downstream commercial parties providing their own distributions and related services. And surely there will be many more variants on these three base editions as users begin to seriously engage and experiment with SDN and specific new use cases emerge. (You might suppose that these enhancements would be delivered as value-added applications atop a basic controller…but I suspect there will be some that inevitably require some further work to be done within the controller in order to run higher-level functions. The best-laid plans, etc.)
The most interesting thing about technology adoption is that it’s never just about the technology. Revolutionary innovations are just the starting point in a much longer process, the ultimate shape of which could never be predicted by the original innovators. I’m immensely looking forward to the long game that’s about to begin.