SDN: Stop Differentiating by Names

Why does it happen with every technology cycle? First, there’s a period of great innovation, followed by the introduction of new terms and categories, which is always followed by a frenzy of differentiation-by-acronym. Everyone gets caught up in talking to each other and one-upping each other, instead of remembering why there was innovation in the first place. I call it “the yearbook effect,” and the networking industry and those who work in it, watch it and write about it are fully entrenched in it right now.

Think about it. SDN, NFV, OpenFlow, controllers, consortiums to build controllers, control plane separation, overlays, blah blah blah.

The industry has gotten so wrapped up in talking about definitions of SDN, the various technologies and how they get implemented, we actually may help delay adoption. We are supposed to be trying to help customers, but we are focusing on the wrong things and it’s confusing them.

I may get kicked out of the SDN fan club for saying this, but I’ve come to the conclusion after speaking to dozens of customers and participating in various industry discussions, any delay in widespread adoption of SDN is our own fault.

People are rarely, if ever, talking and writing about the one thing everyone should care most about: what problem(s) are we trying to solve for the customer. A customer doesn’t come in and say: “Hmm, I need a controller;” or “boy, wouldn’t it be nice if hardware is commoditized.” They say: “I need to get applications to market faster;” or “if I could automate certain networking functions, I could free up resources to solve other problems I have.”

I can’t tell you how many times a customer has come to me and told me that they’ve heard about the SDN craze, but then they couldn’t tell me what it is and even worse, some were even scared to find out. They go to trade shows and conferences, listen to vendor presentations and read reports from analysts and come away just as confused as they were when they started, if not more.

When you boil it down to use cases that enable IT teams and data centers to become more agile, the light bulb goes on. Most couldn't care less if it’s OpenFlow-enabled, called NFV, SDN, or OpenDaylight.

SDN is about helping customers create self-service environments so they can build better products/applications/services. It’s about dramatically reducing how long it takes to provision a network so they can react faster to changing environments. It’s about virtualizing the network to make the data center more efficient and take applications to market faster. This is what resonates with customers and it’s the right discussion.

At some point you can explain how you make the sausage, but in these early days of making the network as agile and flexible as compute and storage, all a customer wants to know is: do I have the right sausage for my dinner?

The other element that is rarely discussed is how do customers solve these problems without changing either the technology they have in place or the people and process that exist. As an enterprise or service provider, you want to find disruptive technology that is disruptive, but not destructive. The discussion should be about can a customer implement a solution with minimal-to-no need for existing technology or organization upheaval. These are things that rarely, if ever, get discussed today by vendors or industry influencers.

As a marketer, I love it when there is a trend you can discuss or a movement you can create or even draft off of, like SDN. And, I’m certainly not saying a deep understanding of the technology or discussions about architectures are not useful at some point. I just believe, based on my discussions with customers, that an early discussion of a highly disruptive trend or movement must be about what we are solving and why. Not, what is it?

Despite my rant about who is to blame and why, the good news is the potential for software-defined networking, which is so much more than hype. It’s simply time for the industry at large to recognize the need to transition to a customer-first mentality. I know at Embrane we’re challenging ourselves to first talk about what we are trying to solve for the customer today and then where that will take them in the future. I hope the industry will do the same – for all of our sakes.

John Vincenzo