Network virtualization -- SDN and NFV -- is rapidly developing into the biggest fundamental change in service provider networking and network management since Internet Protocol and convergence hit the industry in the 90s. At that time, the systems and organizational changes that went with IP were fraught with problems. Can the industry do better this time around?
Moving beyond aspirations
The move to ubiquitous IP forced a rethink in the way that operations support systems and billing support systems worked, which drove initiatives such as Next Generation OSS (NGOSS) from the TM Forum. These promised to leverage the network-level transformation to yield a leaner, more agile business through a step-change in the degree of automation and the breakdown of service and systems silos across the communications service provider (CSP) software stack.
The systematic thinking about idealized forms of the CSP business from that era created a valuable and widely recognized common vocabulary and a top-to-bottom reference model for CSPs. But the corresponding business transformation was never consummated and remains, to this day, largely aspirational, especially in the core of the network and in the delivery of products aimed at the enterprise.
The benefits which were achieved materialized piecemeal, and when transformation was attempted on a larger scale, it often led to a series of now discredited "big bang" projects that yielded far below their expected returns and, in some infamous cases, failed altogether. Examples of this include across-the-board inventory consolidations at several large operators around the world and efforts to rationalize the OSS in operators that accumulated many similar networks through acquisition.
Finding ourselves, as we do, on the doorstep of a second sweeping upheaval, it seems well worth examining what happened a little more closely. SDN and NFV need to avoid similar pitfalls if they are to realize their potential to transform the industry and restore CSPs as competitive providers of value-added services to rival the OTT players that ride on their networks.
Rooting out problems
The roots of the problems that emerged in the IP-driven transformation were threefold. The first was in the top-down, architecture-led design process. It lacked pragmatism, failed to account for the true cost of organizational change and the poor condition of the data in legacy systems, and assumed that proof-of-concepts in lab environments could be used to accurately gauge the practicality of solutions in real-world environments.
The second was a vast underestimation of the complexity of the existing legacy systems, infrastructure, processes and organizations -- and the data on and with which they operated. In hindsight, it's easy to see how this happened: Much of the detail was invisible, lurking in the undocumented "shadow" processes that inevitably exist in organizations with low levels of automation -- and the transformation best practices of the time didn't deliver much advice on how to make sure it was all brought to light.
Which leads onto the third and perhaps most fundamental problem: a failure to recognize that the process of getting to the next-generation architecture and the techniques required to navigate that path were as important, and as deserving of careful consideration, as the systems architecture itself. It is perhaps telling that in the 2005 book NGOSS Distilled, by Creaner and Reilly, which, in its own words, aimed to explain to the reader how to "implement NGOSS faster than the other guy," only one of more than 200 pages is devoted to the subject of transitioning to NGOSS.
Flirting with danger
For SDN in the context of CSP networks, the omens aren't too bad: It has grown from the bottom up, with an operator-led design process founded in a great deal of pragmatism, and has benefited from a number of working, real-world implementations in the enterprise and data-center networking domains.
The technical transition to SDN is reasonably clear: a lot of legacy interoperability is at the protocol level -- although its role in CSP transport networks and how it will interact with existing OSS as it expands out from smallish islands of implementation remains uncertain. This is not to understate the impact that it will have on organizational structures and processes: This is -- and must continue to be -- a focus of discussion.
NFV is in a slightly murkier place, perhaps reflecting its less-developed state of maturity in both standards and implementations. It flirts with the danger of top-down ivory-tower design traps, but is cognizant of this; it has a nascent open-source implementation (OPNFV), an early experimental implementation (CloudNFV), and some field experience in the form of services like voice-mail and provider-side content blocking, and the virtualization of data center IT.
NFV as technological initiative is driven by service providers not vendors -- so more sensitivity is being shown to difficulties of organizational change and accommodation of legacy -- but the discourse still seems to show a substantial overestimation of the degree of automation in the legacy estate. This is especially true with respect to transport, mobile backhaul and complex enterprise services.
There is certainly an acceptance of the likely longevity of legacy networking domains and the need to interoperate with them, but until more detail emerges around management, orchestration and the role of OSS, it is difficult to see whether the road to NFV is being given as much due consideration as the destination.
The telecom industry wants and needs change, and it needs it quickly if it is to restore margins, fight the forces of commoditization and remain competitive.
If there's one thing we should all have learned by now, it is to never underestimate the inertia of the status quo: Vendors and CSPs alike need to keep their eyes on the road if they are not to repeat costly past mistakes.
— Leo Zancani, CTO, Ontology, special to The New IP