Way back in 2013 I attended a big transformation meeting at a Tier One operator. One of the things that happened that I felt was both interesting and ironic was that the person sitting on my left was making a case for the modernization of OSS/BSS systems as the key to transformation. The person sitting on my right was making a case for the elimination of legacy OSS/BSS completely. Does this sound like consensus to you? Further, that division of perspective is still active today.
How critical are OSS/BSS changes to operator transformation? At one level, you could say that since operations and the business of service providers are framed by these systems, they’re absolutely critical. At another level, the right one in my view, you’d say that there are definitely operations things that need to be done, but that OSS/BSS systems may not be where the changes need to be made.
The truth is that service lifecycle automation is the key to transformation. Things like SDN and NFV require it or any reduction in capex would be swamped by operations cost increases. Even without any new technology shifts, my models say that service lifecycle automation could save enough to virtually eliminate the risk of declining profit-per-bit. I’d say that this view is widely held among operators, and that among senior people it’s probably almost an axiom. It’s less clear just how to go about getting to service lifecycle automation, though.
There have always been three approaches to service lifecycle automation. One approach is what could be called the autonomous infrastructure approach, where infrastructure cooperates in its own terms to create services. IP networks could be made to do this with policy management, and it’s Cisco’s solution. The second approach is the operations orchestration model, which says that the OSS/BSS system provides the critical lifecycle automation features via its own orchestration. The third is the abstraction layer approach, which says that we put a new layer between infrastructure and OSS/BSS, and that new layer does the heavy lifting.
The problem with autonomous infrastructure is that making a “service” a byproduct of network behavior misses the current OSS/BSS processes completely and also tends to create vendor lock-in, since there are no agreed open strategies that operators accept. The problem with operations orchestration is that it requires a major shift in the way OSS/BSS systems work, because new network technologies (as well as current ones) have to become visible at the OSS/BSS layer.
The abstraction layer has been my solution from the first. The general goal of such a layer is to harmonize the presentation of services and service elements between what’s above and what’s below. In the context of service lifecycle automation, the goal is to create abstractions that from above look like the logical, functional, elements of a service, and then to map them to the resources below. The specifics of that mapping would be opaque, meaning that each abstraction would be an intent model. This approach has benefits in both the upward and downward directions.
Looking up, meaning toward the OSS/BSS, the biggest benefit of the abstraction layer is that it can portray services as function collections, which is really what an OSS/BSS wants to be working with. Network operations may need to know how a specific function like “firewall” or even “VPN” is implemented, but OSS/BSS systems and their associated operations personnel don’t need to know. Abstraction, then, lets OSS/BSS systems manage services built through service lifecycle automation, without caring about the implementation of the capability.
Looking down, the biggest benefit is really one of immunization. OSS/BSS systems are not structured to be event-driven, to provide orchestration capability at the resource level. To give them that mission is to impose legacy OSS/BSS structures on new service lifecycle software elements, and even down to the network and element management tools.
There’s immunization down below, too. Abstraction means that all implementations of a given logical element are equivalent, which means that a software provider, operator, hardware vendor, or whoever could create interchangeable function implementations easily. You can have a variety of technologies within a functional abstraction, and even have internal orchestration tools there, and they’re invisible and equivalent from above.
If we go back to the old Telecommunications Management Network model (TMN), which defines management as a cake with an element management network management, and service management layer, the abstraction is the highest level. OSS/BSS then deals with services, as it usually does today, and it’s not whipsawed by changes in technology.
To me, the point of all this is that not only are the OSS/BSS systems not the major challenge in transformation, a view that they are would indicate the operator involved isn’t on the right track to transformation, period. You can’t achieve your goal by attacking the wrong problems.
The regular survey done by the TMF on transformation is, in my view, an indicator of these truths, and the survey itself shows the division in perspective that exists on transformation with the operators’ management team. My own contact with operators, in a rough survey, suggests that most of the CTO organization thinks that SDN and NFV are what transformation is about, and since there are standards and tests/trials for both, they’re on their way to success. The CIO organization, where OSS/BSS lives, has almost the opposite view, thinking that not enough attention is being paid to their side of the house, so progress is limited. CFOs have never believed any of the current hype, nor have the COOs and CEOs, so they are still waiting for a convincing path forward.
Open-source interest among operators is a symptom of this waiting and hoping. The operators hold a strong view that vendors are not only uninterested in transformation, they actively work against it. Open source is their answer, but as I’ve said several times, open-source isn’t an application or application architecture, and you can have a lousy open-source project that’s no more value to operators than an obstructionist vendor offering.
We don’t even have the open-source teams lined up right, in fact. The typical story on the current transformation race pits ONAP against OSM, and in fact the two are aimed at completely different places on the model of service lifecycle automation. OSM is principally an implementation of NFV MANO, and ONAP purports to be the layer between network infrastructure and OSS/BSS. The latter, then, is in the right place with the wrong architecture, and the former (IMHO) in the wrong place with the wrong architecture. “Wrong architecture” is enough wrongness to make the other distinctions unimportant.
There are still reasons to update OSS/BSS architecture, but even there the question is whether to modernize or supplement. The big questions relate to the way that OSS/BSS systems and personnel interact with service models. Do we demand service composition, customer support, etc. be integrated with current OSS/BSS features, or should we think in terms of having a “composer” and a “viewer” function that is really independent of current logic, integrated with OSS/BSS via a portal? The latter view is more closely aligned with what’s being done for business applications as they’re expanded to support more composable GUIs and portals for apps.
The net here is that abstraction approach may be broadly accepted, but implementing it is another matter. We still lack a good model-driven way of defining services and linking events to service processes, though the TMF came up with that idea a decade ago. Without such a model, we can’t define how events actually link to processes, which means we can’t define how service lifecycle automation would be integrated/implemented. There are companies who have made progress here, but they’ve not managed to inspire confidence among operators.
I think 2019 might be the year when this changes. Operators are under a lot of profit pressure, facing a need to define new services in a more agile manner. Service lifecycle automation is critical to making that work, which is the good news. The bad is that even if everyone buys into the right approach, it may take time to productize it in a way operators will accept.