Evolution Beats Revolution in the Software-Defined Data Center
Last week I participated in the Software-Defined Data Center (SDDC) Symposium and there were a number of interesting conversations generated from the presentations and panels. Topics included thoughts on SDN architectures, how applications are driving changes in the data center and where the money/budgets will flow from with changes in the data center. Craig Matsumoto of SDN Central covered some of the highlights in his piece on “What the SDDC Good for Anyway?”
One topic of discussion that got a strong reaction from panelists was around whether significant organizational changes are needed to build and support an SDDC, and more importantly, how to go about making those changes. Everyone agreed that changes should come, but as Craig pointed out in his article, several speakers advocated a “rip the Band-Aid off” approach to breaking down silos. I can understand why one might think getting changes made all at once makes sense. However, the Embrane team has spent a lot of time thinking this through and speaking to customers about their SDN and SDDC plans, and it’s just not realistic.
While it’s good for enterprises to have a long-term plan for redesigning organizations and operational procedures, a phased approach delivers many benefits and is infinitely more manageable. Trying to change out teams, reorganize reporting structures, redistribute budgets, retrain support personnel on new functions, redesign processes, layoff people and hire new people all at once is a recipe to stall any chance of adoption. It’s just not going to happen. No one wants to cause that much upheaval and disrupt day-to-day business.
I realize that many of the new architectural changes in an SDDC require significant changes to support them, but that’s not a reason to blow up your current structure and best practices. Part of the reason “turf wars” exist is because many products being proposed by vendors are not enabling current teams to deliver more agile solutions.
Look no further than the network and the networking team. Many of the proposed overlay solutions, particularly those where network intelligence is pushed to the edge (hypervisor) look good on paper. I mentioned this in an earlier blog I wrote coming out of VMworld when VMware announced their NSX Platform. These overlays are trying to solve the correct problem, a lack of agility in the network, but will cause more problems from an operational point of view. No wonder there is resistance. If I’m lacking the tools I need to do my job better and my company’s reaction — rather than fixing that problem — is to have my counterparts start doing my job in ways that aren’t as good, efficient and/or secure, I would be pissed too. It’s not that I don’t want to make changes. I just want to be able to do things in an evolutionary manner.
What’s wrong with building a long-term plan, but solving smaller, current problems that allow a company to make these changes at their own pace? If my immediate problem is network agility and I can start fixing that today without overhauling everything I’ve done and the best practices I already employ, why is that a bad thing?
It reminds me of what happened in terms of the migration to voice over IP (VOIP). During my days with a previous employer some 14 years ago, we were trying to sell VOIP solutions because it was clearly the direction people wanted to go as they looked to improve efficiencies, get better network utilization and save money. We tried to work around the voice team to sell voice to the network team. Clearly the voice team, which was stuck with the legacy of PBXs, didn’t have the tools they needed to meet the ultimate goals of the organization. However, by trying to go around the voice team and forcing organizational and operational changes, adoption was delayed. It took 10+ years to get to a point where VOIP is now in the mainstream.
For me, the bottom line is this: Technology should enable changes – both organizational and operational – but it should not require it. Giving tools to the right people and allowing companies to evolve at their own pace while still solving real problems they have right now is the better answer. As Embrane CEO, Dante Malagrinò often says, while we love thinking about taking a revolutionary approach, revolutions tend to be bloody with a lot of casualties. Evolutions are natural and are less likely to meet as much resistance.
Let’s start enabling change. No one wants to wait a decade for SDN and the SDDC.