Ericsson, Huawei, and NSN have entered into a somewhat-historic agreement to break down interoperability barriers for OSS/BSS systems. OSSii is essentially an agreement to share interface specifications not to cooperate in broader development, or to set new standards for OSS/BSS interoperability (still largely under the TM Forum). The promise is to facilitate rollouts of new services by making it easier to transform OSS processes.
OK, call me suspicious but I’m not much of a believer in corporate sweetness and light, so I think we need to be looking at just why this sort of thing might be happening, and I don’t think you need to look very far. Think SDN and NFV and the cloud.
OSS/BSS systems evolved from what could be called “craft-support systems”, meaning they grew up in a day when a lot of provisioning was running wires and connecting them to racks of gear. As we moved toward using converged networks driven by management interfaces, we moved away from this model and started to see some tension arising between a “provisioned” view of the world (where virtual humans ran virtual cables between virtual connections but kept the processes of service creation largely intact—if virtual) and a policy-managed view in which you set goals for infrastructure overall and forget about provisioning services. Over time, recognizing that services are what get sold, we had to fight to establish a service context for infrastructure that really had to be less service-aware in order to be profitable.
The challenge now is that we are clearly heading toward an age where “service” means something delivered through the network as much or more than something produced by it. Cloud-hosting of stuff, including consumer monitoring, content delivery, and computing services for business, creates a whole new picture of deployment and application lifecycle management, a picture that is very software-centric. Most of you know that the cloud has deployment interfaces for basic tasks and DevOps tools for complicated ones. These interfaces and software-based ALM processes actually bypass a lot of what the TMF and the OSS/BSS community has worked to establish. There might have been hope among some optimists/purists in the space that somehow provisioning the network of the future would still be OSS/BSS-driven. Not happening. The TMF is way too slow, the market way too fast, and the tools of the cloud way too far ahead.
NFV is probably the big factor in this, because if we’re going to host service features in the cloud (as we are, even if NFV as a body isn’t universally prepared to make that leap of faith) we’re building the whole of networking as a cloud application. OSS/BSS will likely play a role in this, but just what that role might be is not clear at this point. Focusing as they are on virtualizing network functions, the NFV activity isn’t looking at the source of orders or the conduit for operations practices. The kids in the TMF will have to learn to play on their own, and so will the vendors.
Ah, the vendors. I didn’t forget about them. What’s happening, I think, is that the players who make a lot of money on OSS/BSS in product or integration terms are now looking at the high costs and high inertia of the processes and saying “This isn’t going to be acceptable to operators”. They believe that if they stay the course and make every OSS/BSS project into something that’s more complicated than writing a computer operating system from scratch, the cloud and NFV revolution will pass them by, and NFV principles applied to network operations will drive even network path provisioning along SDN lines, leaving nothing for OSS/BSS to do and no money available to buy it or integrate it. So you conspire (OK, you join hands in the spirit of public good) and try to constrain one of the costly and high-inertia issues—the OSS/BSS interface integration tasks.
The question, of course, is whether this is going to work—for the first big three or for anyone else who joins later on or even for the TMF. The answer probably lies in how NFV and SDN work. The TMF is a glacier in the tortoise versus hare race, and that’s not a problem unique to the TMF. Standards processes have always been glacial, and they’ve been getting worse over time as vendors try to manipulate them and as old-line standards people fight to control the things they’ve always controlled. NFV and SDN are what most would call “standards processes” even though the former says it will only identify standards and the latter is so far so narrow in its focus as to be market-irrelevant. You don’t win a race, even with a glacier, by adopting the same practices that slowed your opponent down.
I am of the view that there is a high-level harmony between NFV, SDN, and the TMF models. I believe that if that harmony were to be accepted by the TMF guys it would likely be accepted by the SDN and NFV people too, and we’d have a realistic framework for OSS/BSS integration with the cloud, with SDN, and with NFV. But I have my doubts on whether TMF will in fact accept the optimum approach, at least not accept it fast enough to influence deployment. By the end of this year there will be clarity on a complete NFV deployment model, spawned by people who take NFV goals and apply them along cloud/SDN lines rather than along TMF/OSS/BSS lines. If that happens, then only the happy accident of convergence on an early implementation by both NFV and TMF will save the role of the OSS/BSS in the network of the future.