Remember from yesterday’s blog that the goal of an NFV business case should be to “make the Street all tingly inside.” That means that NFV’s business case has to be made in two interdependent but still separate tracks—one to justify new capex with high ROI and the other to create an opex-improving umbrella to improve EBITDA for the operators.
Classic NFV evolution proposes to combine this, creating a significant EBITDA gain and high ROI in any incremental capex. That’s a problem at two levels. First, we have no broad model for NFV deployment—we have a series of specific options like vCPE or mobile infrastructure, but no unifying model. Thus, it’s hard to obtain enough mass to get any significant savings to improve EBITDA. Second, if we achieve gains through infrastructure modernization to an NFV form, we necessarily have a large capex if we have a large network scope to apply savings to. That’s hard to reconcile with high overall ROI and harder to manage in risk terms.
My proposal is simple. We first attack EBITDA by attacking what financial analysts mean when they say “opex”, and we do that by focusing NFV principles on legacy infrastructure. We then virtualize functions where we can secure a higher ROI, either because of extra cost efficiencies or because of incremental revenue gains.
We have to start with that opex point. Any discussion about improving “opex” should start with the fact that the word really has two meanings. We in the networking industry think of opex as “operations expense” but the operators’ CFOs and the financial markets think of it as “operating expense”. Network operations is only one component of this broader opex definition. The other two are service payments (roaming, etc.) and service operations costs. It’s this last group that we need to consider.
Service operations or “service management” is the set of tasks/systems that support the retail or wholesale customer relationships of a network operator. It starts with an order and ends when the service contract expires and the associated resources are released. Service operations links with network operations for the realization of the service relationship being purchased. Through the service lifecycle there are events from both the service and network side that are triggers for action on the other side, so the two operations areas are interdependent.
It is highly unlikely that you could do anything in the way of a new service, or change the operating expenses of an operator, without impacting service operations. In fact, in terms of total costs, service operations makes up about two-thirds of total management costs (service and network), which in turn make up about half of opex. Service operations is implemented through OSS/BSS systems and is under the operators’ CIO organizations.
Given that a third of all opex is service management, you can conclude that if we were to modernize OSS/BSS systems to provide full service automation capabilities and simply cut the cost of service operations in half, we’d make an impact equal to eliminating network operations costs completely.
How does this relate to NFV? Well, as I’ve noted in earlier blogs, NFV declared management/operations to be out of scope and it hasn’t generated recommendations either on how to broadly improve service operations or how to integrate NFV with service operations. As it happens, service-to-network operations integration has been a growing problem. NFV would make it worse.
The problem with NFV, or even with packet networks, is that the connection between “service” and “network” isn’t fixed, because resources are multi-tenant. If you can’t connect resource and service management, you can’t automate customer care—and that’s the largest single component of operations expenses, bigger than network operations. The more multi-tenancy we have, the looser we couple services to resources through virtualization, the more we risk operations disconnect that fouls our service automation nest. We can’t let network and service management diverge or we lose automation, so we have to figure out what can converge them.
This makes a critical point in the evolution to NFV. Any NFV business case will have to address service operations efficiency, and thus should apply NFV orchestration principles to network infrastructure (devices or servers) end-to-end to organize and activate service and network operations tasks. If you can’t drive service operations modernization, you can’t make any NFV business case at all because you can’t change operating expenses and EBITDA. At best, you can ride on somebody else’s business case—if they’ll let you.
If you want a tingle from the Street, start by telling them you can cut service operations costs by half by applying NFV orchestration principles to legacy infrastructure and service management. That would cut total operations costs by 17%, raising EBITDA accordingly. And you’ve not deployed any NFV, any servers, at all.
That’s right! Orchestration of service operations, if you can represent legacy devices in the infrastructure model, can operate without any virtual functions. That’s why you can credibly claim a 50% reduction in service operations costs. You might think you’ve just killed NFV, but what you’ve really done is get the second half of that tingle.
A service operations gain like this does two things. First, it offers a powerful collection of risk-reducing measures. How many NFV salespeople spend time telling a prospect that the hosting of functions won’t impact SLAs or increase the cost of customer care? If we have a modern, automated, system for service management we have a solution to these objections. Second, all new services will create profit to the extent that they overcome cost issues. As we’ve seen, most costs like in the service operations side of the organization. Since new services are covered under our new service operations umbrella, they inherit its efficiencies.
What new services? It doesn’t matter nearly as much. In NFV today we have a bunch of NFV islands trying to coalesce into a benefit continent. Built the continent with service operations tools and you have the natural collection already in place. You can now fit individual NFV applications in underneath without having to invent a whole service lifecycle process for them. If you like vCPE or virtual mobile infrastructure, and if you can make a business case for that application alone, you can deploy it. A service operations umbrella could save the whole lab trial and PoC process and transition it to a consistent, operationalized, field trial.
Who wins with this sort of thing? You can come at service operations in two ways. First, you could expand the current OSS/BSS systems to address the necessary service automation processes. Second, you could expand the current implementations of NFV to include process integration.
Most OSS/BSS systems are at least loosely compatible with the TMF’s model—the extended Telecom Operations Map or eTOM. Most also support the TMF SID data model. These are a necessary step for both approaches—you need to be able to map operations processes, which means defining them, and you need centralized service MIBs. For the OSS/BSS systems to go the rest of the way, they need two things. One is to be event-driven, which the TMF has defined at a high level in its NGOSS Contract/GB942 specification. This is rarely implemented, unfortunately. The other thing OSS/BSS needs is dynamic binding between resource and service domains. I proposed to the TMF that they adopt the notion of an explicit binding domain to do this, but they didn’t like the idea.
For NFV, the key requirement is to have some sort of service model, something that like the TMF SID could define a service as an association of functional components with synchronized operation. This model could then record resource bindings and steer events, which combine to make service operations automation possible.
The key for both these approaches is that they have to apply to legacy infrastructure or we miss most of the service operations processes and savings. That means that the best NFV trials to conduct are those with no NFV at all, trials of service orchestration with legacy components that can then be expanded to demonstrate they work with NFV components too.
As far as NFV vendors go, I believe that Alcatel-Lucent, HP, Huawei, Oracle, and Overture Networks could model and orchestrate the required elements, with perhaps some tuning of the interfaces with legacy elements. Of the group I’m confident that HP has the right modeling strategy and that both Alcatel-Lucent and Oracle have the required operations bend. Oracle is involved in some high-level transformation projects that could actually lead it to the service operations conclusion the industry needs.
Why haven’t we done this already if it’s such a good idea? A big part of the reason is the NFV ISG’s scope issues; the trials and PoCs have tended to match the scope set by the early work. However that was never a requirement; you were always able to propose a broader scope. I did with the original CloudNFV project, though the documents were revised to limit scope once I left my role as chief architect, and that was the first PoC approved.
Why not now, then? Because vendors want simple sales value propositions with big payoffs, and revamping service operations is not only a complex process it’s a process that doesn’t sell a lot of hosting. Everyone wants a big, easy, win. There can be a very big win here with NFV, but it’s not going to be an easy one. All that means is that it’s time to face reality and get started.
