Nokia’s Quarter Adds Another Data Point to the Case for Software Service Lifecycle Automation

Nokia reported a starkly negative quarter, citing slowing sales in wireless in particular as the reason.  OK, that’s true, but it should hardly have been a surprise to Nokia or anyone else in the network equipment business.  For half a decade, operators have been showing their version of the same slide, with revenue per bit dropping fast, cost per bit dropping a bit slower, and a crossover in the 2017 timeframe.  If that was your business description, would you be investing in the same sort of future?  If your buyer had that problem, would you be expecting the same kind of sales as you had in the past?  Get real.  And if this spending issue wasn’t a surprise, then dealing with it should have been a management priority.

Infrastructure has to earn a return or you slow-roll it.  Operators stopped seeing much return on the wireline side, so wireline capex has been in decline for five years or more.  Wireless was still OK, but now it looks like it will also start falling in 2017.  Is it a coincidence that’s the same year as our revenue/cost crossover?   Operators saw this coming, of course, and that’s why they were so interested in SDN and NFV.  Vendors, who realized that controlling cost meant controlling their revenue, were less interested.  Now perhaps they realize that costs were going to fall one way or the other.

Now we’re seeing the clear signals that nothing, not even wireless, is OK.  Return on infrastructure is declining too fast and operators are going to slow capital spending wherever they can.  The initiatives like SDN and NFV, if they’re effective at all, are probably going to help accelerate a decline in capex rather than help things, because we’ve been unable to frame a credible service agility (new revenue) or operations efficiency (lower opex) story so far.  Nokia and every major equipment vendor except Huawei are going to suffer for a couple years at least.  Unless they do something.

The only something they could do is to provide credible paths to service agility and operations efficiency, within SDN and NFV or exclusive of it.  Frankly, I think it’s time for us to separate the service agility and operations efficiency stories from SDN and NFV.  Yes, both technologies could contribute to these non-capex benefits, but my modeling has clearly shown from the first that we could take near-term steps in these two critical benefit areas without touching infrastructure at all.  We could do a top-down service transformation, either by creating a credible path to orchestrated OSS/BSS or by creating service orchestration below the OSS/BSS.

The most we could hope for in capex reduction would be about 4.75 cents per revenue dollar, achieved if we were to totally transform infrastructure.  It would take five years to complete this.  The most we could hope for if we did top-down service orchestration to optimize operations efficiency would be more than double that, and we could achieve it with less than 10% of the investment and in a quarter of the time.  We’d not need to change a single thing in the network itself.

The most important thing that NFV has taught us is that software automation of the service lifecycle is essential.  The sad thing is that NFV until very recently hasn’t worried much about the service lifecycle, only about the VNF lifecycle.  That ties the benefits to infrastructure change.  But if you recognize that a service is going to have to include a lot of legacy technology, then your orchestration processes will have to orchestrate these things too, or you’ll have a half-automated result.  So we can orchestrate an all-VNF service.  We can orchestrate a service that’s half VNF and half legacy if we have legacy interfaces to orchestration, right?  So we could orchestrate something that was only 10% VNFs, or zero percent.  Orchestration/automation, done right, fixes most of operations and agility for everything underneath.  So why not do that now?

Why not indeed?  One problem is that the NFV ISG made a very early decision to exclude operations from the scope of work.  They also decided to call “end to end” only “VNF to VNF” and exclude legacy elements.  Both decisions have largely been reversed, but the whole body of work to date has built on two critically wrong assumptions.

A second problem is that the first problem of operations exclusion largely excluded the operator CIOs who actually run the OSS/BSS.  Even if you now put operations into scope, can you wrestle NFV away from the standards people who have been focusing on virtual hosting of functions and address the comparatively pedestrian issue of OSS/BSS?  Try to get mainstream tech media to get excited about that!  No CIO engagement, no media support, no pressure for OSS/BSS change.

Then you have the TMF.  This body has done a lot of good work, but its response to operations transformation has been totally disappointing.  I did some work on a TMF initiative about eight years ago, and even made some presentations on how software objects that represented service elements could be controlled by a service-level orchestration process, and how these objects could then orchestrate the real elements they represented.  I called the thing that did the lifecycle management a “service factory” and the TMF activity adopted the term but never realized the vision behind it.  The current ZOOM project is aimed specifically at OSS/BSS modernization but it’s not progressed significantly in defining a realistic vision and framework since it started.

None of this can really help Nokia, though, nor does Nokia really need outside help.  They have a strong OSS/BSS position of their own.  They have, in Nuage, the best overall SDN strategy, one that could be added at little cost to any infrastructure to further magnify the benefits of service orchestration.  So why do they risk bad quarters?  Answer: To prevent worse ones and placate their merger partner Alcatel-Lucent.  I blogged before the Nokia-ALU deal that Alcatel-Lucent was underplaying Nuage to protect their router business.  Now Nokia is doing that, IMHO.

A combination of an overlay-SDN model and a modeling-and-orchestration approach to service lifecycle management could relieve pressure on operator spending quickly.  Perhaps it won’t protect Nokia’s inherited router business, but if operators don’t have an opex-driven solution to margin problems they’ll reduce capex, shift to Huawei, or both.  Ericsson had its issues, and now Nokia.  What does it take for vendors to understand they have to do something?  We don’t have many quarters left to apply the right solutions.