The most glamorous part of networking is unquestionably the hardware that moves and delivers information. Historically, the least glamorous part has been the operations support systems and business support systems (OSS/BSS) that support the service providers' day-to-day operations as business entities.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Over the next four years, these new views of OSS/BSS will dominate and eventually replace the old.
But making a profit by delivering a product or service is at the heart of any successful business operation and without technology to support those goals, there won't be any hardware to deploy or a mission for it to support. So the bottom line is that telecom industry trends in OSS/BSS systems are just as critical as network hardware technology trends.
According to network operators, the top telecom industry trends in OSS/BSS systems and architecture are being driven by service layer architecture and changing the need to manage customer experiences rather than subscription services. The major changes include the following:
- A transformation from a supply-side to demand-side vision of the business;
- A transformation from craft (operations personnel) support to automated support
- A transformation from management-as-an-overlay to management-as-service logic.
Networks of old made money by providing technology to connect users, and services were derived from that technology. To achieve optimum return on investment (ROI), network equipment and services investments were made with a very long capital cycle. Products were expected to be in service from five-to-20 years or more.
Sustaining this long in-service period was critical, and OSS/BSS systems processes were tuned to manage the supply of transport bandwidth and connectivity, and to plan orderly capacity improvements. Network management and provisioning in this business framework were separated from service support and billing because the latter represented only the contractual commitments of resources from a pool. This vision of OSS/BSS systems is reflected in the TM Forum's venerable Enhanced Telecommunications Operations Map (eTOM).
Customer experience, service layer drive OSS/BSS systems change
In the network of the future, the "services" of the network involve the dynamic composition of "experiences" from a combination of transport/connection resources, content and processing resources, subscriber knowledge and even current customer behavior and location.
In this model, the OSS and BSS systems processes are bifurcated as before, but this time they are divided into long-lived and tactical technology elements, reflecting a separation from the supply-side vision of services to the customer, or demand-side, vision. Network transport and connection elements still form a resource pool, but that pool is organized into services and experiences through a new "service layer," where software tools to create features and "mash up" feature elements into services create operators' offerings.
This new vision is reflected in the transformation of the TM Forum eTOM vision through the addition of things like the Service Delivery Framework (SDF), the Telecommunications Interface Program (TIP) and the Integration Framework. These provide a new dimension to the older eTOM processes and link long-cycle technology planning with shorter-cycle, software-driven service creation and even shorter-cycle opportunities and competitive threats. Over the next four years, these new views of OSS/BSS systems will dominate and eventually replace the old.
OSS/BSS systems costs must stay down while automating services
If future services are created through software processes and aimed at supporting experiences instead of customers, they will be more complex and much more numerous than services of the past. Operations costs cannot be allowed to scale in proportion to the number of services, or to grow exponentially based on the number of service component relationships. That means that the OSS/BSS systems of the past, which supported human-driven provisioning processes, must support automated, software-based dynamic services.
Because the model of future customer relationships is to provision a service pipe (a broadband connection) and then exploit it with add-on services/experiences, is the industry has a unique opportunity to automate the latter process and contain the growth of operations costs to maximize ROI. Today, 65 cents of every revenue dollar for a network operator is spent on costs like operations and administration. At a minimum, that must not be allowed to grow in the future.
Service automation demands the orchestration of service features by first composing those features into services/experiences and then using the composition to deliver the customer experience when ordered. In effect, services of the future are defined by "scripts" that represent an abstract view of how resources are committed to create the service. When the order is placed, those abstract resources are mapped to "real" resources in a way very much like the mechanisms of virtualization or cloud computing. This means software designed to interpret "service scripts" can create the service automatically when activated by an order, eliminating manual operations on a per-service basis. That is absolutely critical if costs are to be controlled.
Service logic plays important role in new services model
The final trend -- and perhaps the most significant of telecom industry trends for OSS/BSS systems -- is the transformation of management from an independent layer to an element of service logic. The TM Forum's Next-Gen OSS Contract (NGOSS Contract) vision reflects a model of services where the "scripts" that describe service behavior process not only service orders, but order terminations, service faults, service changes and other "lifecycle" events.
This bold step would not only transform operations support, it would transform OSS/BSS architecture itself by making it less of a separate software function and more of an integral element of the service layer -- in effect, lifecycle processing becomes a piece of the actual logic of the service.
The interdependence of service logic and management presents major challenges to OSS/BSS vendors who have traditionally separated their tools from service logic -- and even, by isolating it through standard interfaces, from the network itself. Even OSS/BSS standards bodies like the TM Forum are challenged by the integration of logic and management because those bodies have not traditionally addressed service logic elements and issues.
Because componentized service-layer logic can be modeled easily through object-oriented software design and represented as a form of cloud computing, bodies like the Object Management Group, the Distributed Management Task Force, the Open Service Assurance Forum and the Open Cloud Consortium may play a much larger role in OSS/BSS systems in the future, and service logic principles articulated by traditional organizations like the ITU, ETSI, OASIS, GSMA and 3GPP will increasingly impact service management and thus OSS/BSS design and deployment.
The future of OSS/BSS systems: Summing up
All of this adds up to a single truth -- OSS/BSS systems of the future will increasingly be part of a larger service-layer architecture, gradually losing their current identity and focus. This will create opportunities for network operators, equipment and software vendors, and standards bodies to generate new and highly relevant solutions to the emerging service challenges. It will also create risks for those who don't recognize these changes and address them promptly.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecommunications strategy issues. Check out his SearchTelecom.com networking blog Uncommon Wisdom.