Operations and business support systems (OSS/BSS) have been the center of network operator IT projects from the very first days of computing. As “vertical applications” for providers, they’re the heart of profitability and productivity for a global market measured in the trillions of dollars, and they are linked to infrastructure with residual value in the trillions.
OSS/BSS may be the most structured and standardized of all vertical applications, but that doesn’t mean that it doesn’t need to change. In fact, OSS/BSS is on the verge of changing to emphasize the customer experience that focuses on the quality of experience (QoE) of the user.
Customer experience: Where XML-driven OSS and service management meet
By way of background, operations systems have traditionally been differentiated from network management systems, with OSS managing the operations personnel and the business activity and network management systems managing the devices. A certain tension or competition has always existed between their missions, yet the two came together in the area of service management.
Service management was expressed as the top layer of the original network management stack (which includes element management, network management and service management). Service management has also become a focus of OSS/BSS through the TM Forum Service Delivery Framework (SDF) work.
Yet another way of looking at operations and business support, and at service management in particular, is as a customer experience model, which is implicit in the way over-the-top (OTT) providers offer their services. This model unifies network and operations management with services, but it focuses the unification around the quality of experience of the user.
In an experience-centric management model, everything starts with a user commitment to an experience or service based on an offering by a provider. In TMF terms, this would be the NGOSS Contract. The goal in experience-centric OSS/BSS design is to make that commitment into something that can be processed by software to create the service or experience the customer wants.
In order for that to happen, the commitment must be expressed in some standard form using a machine-readable structure. XML is the most widely accepted language for this mission because it is easily processed using a variety of standard software tools.
An XML metadata description of a service order could be translated by OSS/BSS systems into a set of requests for provisioning steps already defined in both management practices and formal standards (the TMF eTOM standard, for example). The service contract becomes a kind of shopping list for functionality of OSS/BSS systems, replacing a more traditional static application model that’s specific to the types of service being created. Instead of having an “IPTV application” or “VPN application,” the operator has a single application that parses XML metadata to create either of these services, and many more.