Take a look at SDN, whose main premise is to separate control from the data plane and thereby achieve high agility for its users. Same thing for NFV: abstract the software from the hardware and then combine and deploy software functions at will for high agility. So the operators, at least the bigger ones who have the least agility, are investing megabucks to deliver on the twin promises of SDN and NFV. What’s frustrating for them is that they are doing so with inter-locking handbrakes on and in a decidedly non-agile manner.
In a sense it’s not so surprising. In effect, the operators are trying to re-engineer 15 years of painstakingly built managed services processes in a very short period of time. And they are doing so using a combination of new operational and management techniques, new (albeit commonly available) hardware, re-packaged software and co-opting their existing set of waterfall processes and organisational silos. This is like pressing on the accelerator with the handbrake on. Some, e.g. Verizon and belatedly AT&T, are trying to loosen the rigid structure of their organisations to create a more agile decision-making process and a Devops culture where network specialists and IT folk combine to break down internal barriers and loosen their internal disk-brakes.
SD-WAN, however, took the operators by surprise. SD-WAN vendors position their wares to enterprises with self-select portals, centralised policy control and the ability to take advantage of cheaper Internet links to deal with all the Cloud-based, Internet services that are swamping their traditional operator-provided WAN connections. This overlay approach puts control and thus agility in the hands of the enterprises and this is precisely what they want.
The response of the operators to this agility attack by SD-WAN, however, is telling. As opposed to SDN and NFV, where they are re-engineering their processes with open APIs to (slowly) deliver on the promise of virtualization, they have taken a very different tack with SD-WAN. For the most part, they have:
· selected proprietary software technology with closed APIs
· accepted the use of proprietary appliances (the antithesis of NFV), at least initially
· deployed the aforesaid technologies from young and untested companies, prone as we have seen to takeover (e.g. Viptela, VeloCloud).
This seems counter-intuitive at first glance but agility is the explanation. SD-WAN, by putting agility directly in the hands of enterprises, thereby threatening MPLS revenues, has created such a sense of urgency that the operators have been prepared to abandon their normally conservative vendor and technology selection process to prove they can also play the agility card. Sure, they are kicking the SD-WAN vendors to mitigate the risk of vendor lock-in but two big questions remain though:
1) Will co-opting SD-WAN technology allow the operators to compete effectively with do-it-yourself enterprises and system integrators who can also distribute connectivity risk across multiple lines from different operators?
2) The real conundrum though is how to tackle the price problem. What is the package of MPLS plus Internet connectivity that can deliver additional value to enterprises at an affordable price?
Tackling these linked problems is going to be critical for success. It seems the handbrake will also have to be released in the Marketing departments of the operators if they are going to achieve a market-competitive response to SD-WAN.
