Light Reading posted an interesting article on the commitment of network operators to NFV despite uncertainty about how they’d be expected to integrate with OSS/BSS. There are some parallels between the comments made and my own interactions with the operators, but I’ve also had some discussions about the issue at greater depth, and I want to share the results of these too.
Operations support, meaning operations support and business support systems (OSS/BSS) are the lifeblood of the business of being a service provider. Banks have things like demand deposit accounting (checking/savings) and operators have OSS/BSS. So the fact is that OSS/BSS isn’t going away no matter what, and I don’t think any operator seriously thinks they are. Operators have been groping at the question of how to “modernize” operations systems just as banks or retailers have been looking at their own core IT applications.
Telephones predate the computer by a large margin (just like banks do) and so technology was first applied to operators’ business largely to record and integrate manual tasks. We ended up with a bunch of acronyms that I won’t bother decoding (AMATPS, CSOBS, EADAS, RMAS, SCCS, SERVORD, and TIRKS) by the ‘70s, and these described computer tools to facilitate the business of telephony.
About a decade ago, operators and some vendors realized that we were advancing computer technology and application architectures faster than we were transforming the OSS/BSS. Sun Microsystems, then perhaps the powerhouse vendor in the network operator space, developed a model for OSS/BSS based on Java. This was taken over by the TMF (as OSS/J) and also became a program supported by a variety of vendors, including Oracle, who bought Sun. Most of my operator contacts and most OSS/BSS experts I’ve talked with would agree that the initiative had great promise but didn’t develop into anything particularly influential.
The goal of OSS/BSS evolution from this point forward was threefold; first, to modernize OSS/BSS interfaces to be based on modern standards, second to open up what was perceived as becoming a very closed software structure and so make it more competitive, and third to support automated responses to service events rather than couple manual processes (“event-driven”). Those same goals are in place today within the operator groups responsible for OSS/BSS, which are under the CIO.
CIOs, as you may recall from some of my prior blogs, haven’t been particularly engaged in the SDN or NFV processes, and so you could reasonably expect that they’ve pursued their own missions in parallel with the transformation tasks of SDN and NFV, which have been under the CTO. On the face, then, it’s not surprising that operators today aren’t relating the two activities much, and totally unsurprising that they’d pursue SDN and NFV without a complete OSS/BSS strategy—different organizations are involved.
But a deeper question is bringing the topics together even if the humans involved are still doing their own quasi-political things. SDN and NFV both inherit from the cloud a notion of translating a “model” of something into a deployed and operational system. The modern term for this is “intent modeling”. The MANO (management and orchestration) process of NFV and probably the MANO-to-VIM (virtual infrastructure manager) relationship should be seen as operating on intent models. The goal is service automation, of course, and this is where the issues with OSS/BSS arise, because services are what OSS/BSS systems are about.
You could create two models, broadly, for combining modern MANO-like concepts with OSS/BSS. One is to use MANO entirely below OSS/BSS, as traditional devices and network management systems tend to be used today. I’ve called this the “virtual device” model because old OSS/BSS practices work with devices, so you could make them work with SDN and NFV if both these new technologies were presented as though they were devices. The second model is to make MANO the center of the universe, orchestrating the entire service lifecycle including operations processes.
This, in my view, is the operator dilemma and what they’re really debating. If you elect to follow the virtual device model, you retain compatibility with the operations systems of today, but you now either have to forget orchestration at the OSS/BSS level or you have to build it there separately from whatever you do to model and automate the fulfillment of “virtual device intent models”. The OSS/BSS community, meaning the people in the operator organization who run OSS/BSS and those in the vendor community who provide the products, are largely in favor of staying the course, and those outside (and a few mavericks inside) favor a complete transformation of OSS/BSS to be an element of intent-modeled systems orchestrated by MANO-like principles.
This is the sort of “how-many-angels-can-dance-on-the-head-of-a-pin” question that most people outside the politics of the process get pretty frustrated with, and it’s easy to dismiss the question completely. The problem arises because operations efficiency is the most critical benefit that either SDN or NFV could present. You pretty much have to be able to automate service operations in a virtual world, or you have a bunch of humans running around trying to fix virtual machines (maybe virtual humans would work?) In financial terms, you have as much as about 18 cents of every revenue dollar on the table as a displaceable cost if you can fully automate service/network/IT operations.
Even “capex” is impacted here. Not only does the ability to substitute virtual resources for real appliances depend on efficient operations, operators spend a lot of money on OSS/BSS. For years and years their spending on capitalized operations software has exceeded their spending on the devices on which the software is run.
Because operations efficiency is such a big piece of the benefit case for both SDN and NFV, it follows that it’s going to be difficult to make a broad case for either SDN or NFV without drawing on it. To do that, you have to find an approach that unifies operations and reduces costs overall, which means uniting the political constituencies of NFV.
There is a ton of money at stake here. “Orchestrable” OSS/BSS would let operators do best-of-breed shopping and integrate components easily. That makes it anathema to current OSS/BSS vendors. It would also facilitate the substitution of network resources and IT elements, making it less desirable to vendors in those spaces. But it could make the business case when it’s very probable that without it, neither SDN nor NFV can succeed on a large scale in service provider networks.
So this is a deep issue, a deep division, an example of how an age-old organizational separation could become a barrier to facing the future correctly. Right now, the core problem it creates at the technical level is that, lacking a unified force to change stuff in operations overall, we’re not addressing how the changes could be made or coordinated. I hear stories of the right answers out there all the time, but you have to dig them out of a mass of vendor material and PoCs and demonstrations.
I’m glad we’re talking about this issue because it’s the most important issue in both SDN and NFV. Fix this and we can fix everything else in time. Fail to fix it and we’re out of time.