In all the years, all the decades, I’ve worked with telcos, nothing has been as durable as the debate over the importance of OSS/BSS systems. I recounted in a past blog, an experience I had twelve years ago, a meeting where the planner on my left wanted to modernize OSS/BSS and the one on my right wanted to eliminate it. Where are we in this now, and how is it changing?
Fundamentally, OSS/BSS systems represent the core business applications of the telco world, and no vertical can survive in our computer age without their core business applications. The issue, IMHO, has always been more complicated, relating to the role OSS/BSS played and plays in network operations. Yes, a network is an element of a telco’s core business, but it’s also a technology framework that evolves based on a broad, and broadening, set of missions. The real question is what linkage, if any, should exist between telco business and customer management, and network management.
OSS/BSS systems evolved in the era of customer-specific facilities and five-nines assurances. Today we have customer-specific wireline access to infrastructure that almost never guarantees anything like five nines, and that is shared on a packet level among users. Almost all of this is based on IP, whose management is inherited not from the days of T1 and T3 (or “E” for those outside north America) but from the Internet.
The shift from digital TDM circuits to IP packets was profound in a lot of ways, one of which was in management or “netops” practices. If you break a specific connection between network resources and customers, you break the model of managing the two together. It’s this model shift that raised the debate on OSS/BSS.
The OSS/BSS community, meaning generally the operators’ CIOs and associated organizations, has generally (and unsurprisingly) seen a future where netops is harmonized with, and subordinate to, the OSS/BSS systems. This is the view promulgated consistently (if implicitly) by the TMF or TMForum, the dominant industry group in the space. Since there is no corresponding group for the opposite point of view, this has remained perhaps the dominant force on the topic of operations.
The reason why there’s no specific body representing the opposite view may be that there really isn’t any dominant opposite view, at least not a realistic one. My own experiences here, both inside and outside the TMF, suggest that the debates on the OSS/BSS situation is not unlike modern political debates; it’s more about winning than about being right. In the netops-versus-service-ops stuff I’ve heard or heard about, the former positions are usually a form of counterpunching, and nobody seems to be facing reality.
Which is what? I’ve been working with network operators, in standards activities, consulting projects, and just chatting, for decades. I believe that OSS/BSS systems are as essential to network operators as DDA (demand-deposit accounting, meaning checking/savings software) is to banks. I also believe that just as it’s very unlikely a bank could successfully integrate facilities management into DDA, there’s little chance an operator could integrate packet netops into OSS/BSS. We have, with packets and IP, separated the services operators provide from network infrastructure in a practical sense. We have to recognize that in how we operationalize both.
To try to get to that point, I’ve drawn comment and insight from 44 telco and cable MSO planners I believe are thoughtful in their consideration of the problem. They’re unified in their belief that servops and netops are parallel functions with a narrow and specific point of interchange. That point is the exchange of service state and service commitment events, within a specific division of responsibilities.
Everyone in the group agrees that customer sales and billing is an OSS/BSS function. Everyone but one agreed that network fault, configuration, security, and performance management was a netops function. The majority of the planners (32) say that customer service and support is an OSS/BSS activity. From this general agreement, you can say that the interchange of events between the two areas would logically focus on where one activity influenced the other, which means areas where service state and network state intersect. It’s best to look at these areas by dividing them into servops-to-netops events, and netops-to-servops events.
One servops-generated event is a notifications of service commitment. A customer buys a service, and that implicitly commits resources to the service. To the extent that such a resource is unique to the customer, the process may require pre-validation of availability, and may also require a level of network provisioning. In most cases, the service will draw from a network pool of capability, and it may be necessary to validate whether the residual capability in the pool after the commitment meets operator policies for capacity reserve.
The second servops-generated event is a customer complaint. In services based on pools of resources rather than on dedicated facilities, and where no specific SLA is offered (consumer Internet, for example), it’s common to find complaints as the major way faults are identified.
The primary netops-generated event is a resource fault, meaning a condition that degrades the performance of the network, and is therefore likely to impact services. The purpose of this event was to notify customer support of a known problem, and so to improve communication with customers who made a complaint.
A related and more specific netops-generated event is an SLA failure. Where a service has a specific SLA, the general view of the planners (31 of them) is that the netops system would be responsible for detecting issues and determining if an SLA were violated. Planners generally agreed that having servops do this created too tight a coupling between the systems, and that this single point might be the major source of debate over the future of OSS/BSS.
The thoughtful planners think that the most significant goal in the design of a modern OSS/BSS and netops process set is to maximize the independence of each by ensuring that nothing is done in both at once, or in a place that disconnects from the primary organizational responsibility set. For example, what happens in an SLA violation? Yes, there may be a customer billing or support impact, but detection and remediation are clearly netops functions.
Event exchanges coordinate areas where network and service operations both have a role to play, and these events should trigger the playing of that role. They would emerge from the “detecting” system, and in general that system should be considered responsible for the function that generates them and any remediation the event implies for that generating function. That’s what the thoughtful types believe, and I agree. But will this quell the sometimes-rancorous debate? Does logic trump political debate? You decide.
