Is there a new model for telco transformation? According to a Fierce Telecom piece, there may be, and the details in the article match very well with what I’ve been reporting from my own contacts with network operators. The big question may be where this new model will take us, and what vendors, bodies, and concepts it will end up validating.
The leading technologies in transformation, according to popular wisdom, are SDN and NFV. Operators have been griping about both in both conversations with me and surveys I’ve done. SDN, they say, is too transformational in terms of the network technical model. Central control of forwarding, the classic ONF OpenFlow SDN model, may or may not scale far enough and may or may not handle large-scale faults. NFV, they say, is simply too complicated to be able to control operations costs, and its capital savings are problematic even without opex complications.
So what works? BT, in the article, says “If you ask me what’s going to be the most transformational change in our industry it’s not SDN. It’s not NFV. It’s this model-based concept with telemetry and network automation. And yes, SDN and NFV are tools that help us with that, but actually they’re largely unexciting.”
Model-based networking uses a modeling language like OASIS TOSCA to describe a service or service element and frame how it’s deployed and managed. Tools that understand the modeling language can then be used for service lifecycle automation. The use of modeling also provides a framework into which vendors can be told to integrate, as a condition of procurement.
The article, and other stories told in public by operators, shows that the most critical step in transformation is really the standardization of service models. That paves the way for adoption of automated lifecycle management, but also the adoption of SDN and NFV. That BT is cited in the piece as saying that SDN and NFV are “unimpressive”, “unexciting” and “still hard” to deploy is also proof that because SDN and NFV attempted to justify transformation on bottom-up technology shifts without operational support, they now depend on things outside their own control.
This is all about taking an “operations-first” approach, and that makes sense even based on my modeling. That’s been showing (for years now) that you can get a larger reduction in service provider costs, a larger improvement in agility and efficiency, by service automation. Given that service automation isn’t dependent on lower-level infrastructure upheavals, there’s a much lower implementation cost and higher ROI—20 times that of an SDN/NFV approach, in fact.
The impact of an operations-first approach to transformation could be profound, but it also presents challenges at many levels. One obvious truth is that service and network operations have been historically supported in different organizations within the operator, the Operations group for the first and the OSS/BSS CIO group for the second. Even operators who have established ad hoc teams to try to unify planning and adoption of wider-scope operations automation have struggled.
The new model would also tend to pit vendors against each other. OSS/BSS players are often not major players in infrastructure—Ericsson, Huawei, and HPE are exceptions. IP/Ethernet players like Cisco and Juniper are not typically recognized in OSS/BSS, and in fact aren’t always seen as leaders in the new area of service automation.
The standards bodies and open-source groups may also feel the pressure. With the exception of OASIS TOSCA and perhaps (though not in my own view, Cisco and YANG) there’s not much model focus among major bodies and vendors. Even ONAP, which is the best of the current open-source stuff, is behind in terms of the modeling and architecture needed to create effective, open, scalable infrastructure and services. Most work is also confined to either the OSS/BSS or NMS/NOC space, and we really need to transform through virtualization, which demands we bridge that gap.
The tensions created by an operations-centric view of transformation could spread, too. The article I cite and my own discussions with operators show increased interest in promoting an overlay-service model based on SDN/SD-WAN technology. This is a kind of network-as-a-service virtualization that has some very specific benefits, and affinities with an operations-first approach.
One obvious benefit of SD-WAN for an operator is the ability to construct services that transit, in part, infrastructure of another operator, and even to mix technologies under the same service umbrella. MSPs have built whole business models on managing services across operator boundaries, and operators could hardly miss the fact that they’re losing out on an opportunity. Furthermore, since an SD-WAN presents service terminations and can monitor user QoS as well as transport SLAs, integrating it with transport management and service models would provide a better control over user experiences and lower customer care cost.
Service overlay networks are bad news for incumbents because they put the revenue-generating part of the operators’ business into a layer that they don’t control. There is a huge difference between the services of networks and services over networks. The former means that what users pay for is a behavior of infrastructure, and the latter means that infrastructure is simply a delivery mechanism. In effect, it makes traditional connection services into a form of over-the-top services.
What’s most interesting here is that SD-WAN vendors generally don’t have a story in service lifecycle automation, despite the logical connection it has with “service overlays”. Nuage, a partner in BT’s SD-WAN plans, is quite different from the typical SD-WAN vendor; their roots lie more on the SDN side. QoS Networks is another outlier here, a company that seems to have started as an MSP with custom SD-WAN tools and integrated operations as a major differentiator. Will the traditional players catch the wave here?
That’s tough to say, in no small part because many of the traditional SD-WAN players (and even some of the outliers) are venture-financed and so are beholding to the interests of players who traditionally push for quick exits with little or no additional cost or risk. Ironically, many SD-WAN players probably have the right assets, or at least have a set of APIs that could be exposed as part of a specific strategy to integrate the service layer SD-WAN creates with service lifecycle automation. Thus, the real effort would be in positioning the stuff correctly.
Positioning may be the biggest place to look for VC pushback on vendors, though. The specific problem is that operator SD-WAN opportunity is seen by VCs as a long slog, and enterprise positioning an easy lob. Management and management/lifecycle automation are definitely of more interest to operators than to enterprises, so singing that tune would likely seem to VCs as an excursion away from an early and profitable exit. Truth be told, it’s probably a faster exit opportunity, and perhaps even something necessary for survival.