In my last blog, titled “SDN 2.0 Is Meaningless,” I aimed to counter some of the push in the market to create new acronyms like SDN 2.0 rather than focusing on delivering on the SDN promise. In this article, I would like to focus on some more practical matters of how to embed SDN in the enterprise IT strategy and lay the foundation for a successful implementation.

While hyperscale cloud players, service providers driven by the promise of SDN and NFV, and specialized other environments are pushing ahead and benefiting from their (unique) SDN investments, most enterprises are left wondering how to reap the benefits of SDN and how to embed it in their enterprise IT strategies.

For starters, the challenge for most IT infrastructure organizations is that SDN is part of a broader automation push in the data center or even beyond. That push crosses domains and is closely linked to business problems that infrastructure groups are not regularly exposed to. Consequently, the first hurdle to overcome is a broader engagement between IT disciplines, and then between the business and IT, without applying the “old” and lengthy, formal processes and instead focusing on innovation and agile development as equals.

IT organizations can learn a lot from application developers, who have long been engaged with the business and have applied techniques such as agile development to shorten the development cycles, provide results sooner, and provide better alignment with the business. Application developers have also been successful using ever-improving tools and frameworks for (automated) code development and (automated) testing to shorten time to market and improve efficiency and quality.

As networkers, we have to admit that, generally speaking, we have been slow to adapt and have been stuck in our infrastructure world for too long. Over the past years, driven by a variety of factors, server and storage virtualization has become mainstream and with it, network virtualization a la VMware and others.

Physical networks, however, have at large been based on technology and protocol stacks from the eighties and nineties that we have continued to expand, sticking workarounds on to our existing constructs. And they have been caught out by virtualization vendors, which have taken it to software with virtual switches and routers, thus creating flexible overlays and abstraction but introducing new complexity by adding yet another layer.

These virtual constructs, as brilliant and useful as they are, tend to let us forget the fact that there still is a physical network below this overlay that will ultimately determine the capabilities of the overlay and its reliability as well as carrying the actual traffic and creating the integration with non-virtualized equipment and the wide area. We tend to forget these underlays until things go wrong and we need to troubleshoot or we need to provision a full stack.

Automation in general and SDN specifically require programmability. And, as every engineer knows, complexity slows any initiative, and bringing simplicity to something complex is real genius. Looking back at the roots of SDN, it had simplicity in its DNA – and for good reason. Just imagine having to automatically provision a full virtual and physical protocol stack, box by box and protocol by protocol, to achieve your end-to-end automation goal. Something is bound to go wrong somewhere at some point in time.

What is needed is simplicity in the physical enterprise networking stack, and effective virtualization and tenant separation, security, and effective and simple automation inherently supported by the control plane to streamline programmability as well as providing effective integration with (virtual) compute, networking, and storage for minimal complexity. Furthermore this foundation needs to provide effective OA&M capabilities, fast restore, and high levels of reliability, something our legacy stacks overlaying one protocol on the other don’t. At the same time, a single central controller will not provide the flexibility and control needed in today’s enterprise networks either.

In conclusion, enterprises looking to SDN and wondering how to effectively embed SDN in their IT strategies should first focus on ensuring they have the skills and the organizational capabilities to have a business-led discussion and support more agile developments and deployments. Understanding the business drivers and aligning to them will provide the valuable use cases needed for effective automation. Also, enterprises should look at SDN enabling their infrastructure, not by getting the latest overlay management gadget, but by asking themselves and engaging with their vendors to seek simple, effective, and reliable foundation technology solutions that will far simplify and accelerate SDN deployments while lowering operational cost – even before the first SDN deployment.