As SDN and related technologies slowly trickle into the mainstream, a recurring theme is that cultural and staffing issues are the biggest challenge (i.e., the technology is surprisingly sound, given its infancy). Today’s siloed IT organizations are challenged to address software-oriented infrastructure, particularly in the networking space. In addition, for all the talk of DevOps, we see limited penetration in mainstream IT to date.
We’ve written about these challenges here, and they’re hard to overcome. Culture change takes time, and it’s a chicken/egg proposition: do you use the new technology to foster cultural/staffing changes or do you mold culture/staffing first? I’ve spoken to clients who’ve done it both ways, neither is particularly easy. That said, simply taking that first step is usually the hardest part. To that end, one pragmatic, yet strategic first step is to re-think how to manage your virtual switches. In the vast majority of enterprises I speak with, virtual switches are managed by the server/virtual team, the same folks that manage the hypervisors, typically ESX from VMware or Microsoft’s Hyper-V. There are some folks who’ve installed third party vSwitches, such as Cisco’s Nexus 1000V, but the vast majority of enterprise use a virtual switch from their commercial hypervisor vendor.
So this is a perfect opportunity to take that first step in blurring the silos. First, bring the network team into the virtual switching fold via giving them access to virtual switches. Let them dig around, get comfortable and understand the nuances of the virtual switch. After all, it’s just a switch, with interfaces, VLANs, QoS, ACLs, etc. Next, allow joint ownership of the virtual switching software across both the virtual and network teams (including management, configuration, operations etc.). This helps to bring the networking and server/virtualization teams closer together. It’s a relatively small thing, but goes a long way to getting these teams working closer together. Often, this is initially met with some resistance from both sides, but this concern typically settles after a couple of weeks, even in large organizations. In essence, it is one step back in order to take fifteen steps forward in the march to blur silos, and drive towards a more software-oriented networking future.
And some related research:
Getting Beyond the Hype of SDN: Why, When and How to Get Started (Video – Conference Presentation), http://www.gartnereventsondemand.com/session-video/LSC33/H6
Beyond the Hype: SDN Delivers Real-World Benefits in Mainstream Enterprises, http://www.gartner.com/document/2874018
Summary: Network decision makers must strategize for the networking paradigm shift represented by SDN. This research identifies mainstream organizations that have achieved increased agility, cost savings and/or improved security using SDN-based technologies
Mainstream Organizations Should Prepare for SDN Now, http://www.gartner.com/docshare?resId=2685029
Summary: Mainstream organizations must now strategize for the networking paradigm shift represented by software-defined networking (SDN). This research identifies a pragmatic road map for I&O leaders to leverage the benefits associated with SDN.
Read Complimentary Relevant Research
Top Strategic Predictions for 2018 and Beyond: Pace Yourself, for Sanity's Sake
Technology-based innovation arrives faster than most organizations can keep up with. Before one innovation is implemented, two others...
View Relevant Webinars
Channel Trends 2017: Three Activities to Focus on
Widespread digital transformation and shifting buyer expectations are placing demands on technology provider channel leaders to enhance...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.