New telecom transformation goals require service automation
Restarting a telecom transformation means putting business goals first and technology choices second, and making the service process more efficient through automation.
The notion that telecom providers had to transform their business models is more than a decade old, and for most of that time, specific initiatives targeted the telecom transformation goal. Positions for chief transformation officers have even been created to get it done. Yet, here we are, watching telecom capital expenditure decline as, unfortunately, profit and cost per bit converge. Software-defined networking was supposed to fix this decline, as was network functions virtualization and even cloud computing. But declining Capex remains unfixed in 2017.
What will fix it now? Since everything old is new again, operators now think the answer is to go back to transformation.
The idea of fixing an old problem by returning to an old strategy may seem crazy, but there's method behind this choice. Telecommunications is a $2 billion global market, with the greatest financial depreciation inertia of any tech industry. While it's likely that every CFO in the industry looks back at the decades-old transformation strategy concepts taught in business schools, they now realize a strategy that approaches a telecom transformation by replacing legacy gear with something virtualized -- or gear that could be virtualized in the future -- is going to take a long time. They also realize that attacking a systemic problem like revenue or cost per bit with selective technology changes is probably not going to be effective. That's why only about 25% of operators that were confident about network functions virtualization (NFV) strategies at the end of 2015 were confident a year later.
The goal of a telecom transformation rewind
The back-to-transformation movement isn't about repeating the past; it's about starting with the business-school approaches of the past and developing them with principles learned from cloud computing, software-defined networking (SDN) and NFV. It's about being goal-driven first and technology-centric second. If you want to stop the frightening convergence of operator revenue-per-bit and cost-per-bit curves, you have to either reduce costs or increase revenues. These goals were apparent in the beginning, but early transformation planners couldn't get past the abstract goals, and no technical path presented itself.
In the technology-driven SDN and NFV period of telecom transformation, the problem was the opposite. People worked out a new way of building networks using virtual functions and software-defined connectivity. Most everyone agreed this was a better and more flexible approach, but it was also totally different, complicated and didn't seem to have any accepted business-value propositions to drive it. The specific benefits were unclear, as was the path to them. Nobody had a good answer, so the technology-driven model didn't work, either.
The big lesson operators have learned is telecom transformation can't be about changing technology; it has to be about improving operational efficiency. The cost of deploying, selling and sustaining services accounts for almost one-third of every revenue dollar, and capital costs are about 19 cents per revenue dollar. The quickest change operators could make to improve their return on infrastructure would be to make this whole operational process cheaper through service automation. The same automation could also reduce service provisioning times and make it possible to introduce new services faster -- both of which would increase revenue. Lower cost, higher revenue: What's not to like?
More on telecom transformation
Assess three primary telecom technology transformation options
Embrace next-gen services for revenue's sake
Taking parts from NFV and SDN leads to operations efficiency
The key to obtaining operations efficiency turns out to be one thing from NFV and another from SDN. NFV offers orchestration, while SDN provides the idea of device independence. Orchestration is the term now used to describe modeling of the entire service lifecycle and using software to drive all lifecycle processes, including responses to changes or failures in the service resources.
The quickest change operators could make to improve their return on infrastructure would be to make this whole operational process cheaper through service automation.
In NFV, orchestration is essential because virtual network functions replace traditional devices, and that deployment process has to be coordinated for every single function in a service if the service is to work. Automated software lifecycle management is possible with end-to-end orchestration, and it brings great efficiency and agility.
The big problem with NFV orchestration is that current infrastructure doesn't use virtual functions, so you can't apply the NFV model. SDN stepped in to help with a specific idea that came out of the project work on the OpenDaylight SDN controller -- the idea of device independence. Yes, an ODL controller can control SDN switches, but with the proper plug-ins, it can also control almost any legacy device or even a system of devices accessed through a common network management system.
Operators and vendors have also provided varying support for legacy devices by exposing the management systems of current network hardware directly to the orchestration layer. In some ways, this is a better approach because it doesn't need the intermediate SDN controller. But not all NFV implementations have this kind of capability. Even where a controller is present, it may require custom coding to interface with some network devices.
If you can use SDN ODL or a customized orchestration interface, then NFV orchestration can drive even legacy devices through software-orchestrated service lifecycles. You can then phase in SDN switches or NFV's virtual functions where they make sense, at a pace that makes sense, while getting the operations benefit right away. In fact, you could get enough benefit from doing model-driven software-orchestrated service lifecycle management to fix the problem of profit per bit, without changing out technology at all. If you then added in SDN and NFV in an optimal way, you could save as much as two-thirds of the Opex costs.
When will telecom transformation technologies benefit the industry?
We're not quite to the point where this transformational goodness can be achieved, but we're closing in -- largely from the NFV side. The OPEN-Orchestrator NFV open source project is extending NFV automation concepts to operational support system/business support system elements to capture more operations savings. Network giant AT&T has defined its own open source implementation of SDN and NFV-centric infrastructure. Both its projects include the device-independence model from SDN and OpenDaylight.
SDN and NFV have so many different changes and additions that it's hard to make sense of them as a whole. But there's a single driver behind all of them -- the new-model transformation theme. We need benefits to match our challenges, and operators are realizing they have to look at everything through the service lifecycle -- from service design to operations and fault management. They also have to address both new virtualized elements and legacy devices. If they can do all of that, they stand to gain as much as 12 cents of each revenue dollar in overall transformation return. That's more than enough to interest everyone at the C level, and to drive new and exciting projects, even under the old transformation label.
Next Steps
Find out what's driving NFV to be better for the business
