Light Reading did a nice piece on OSS/BSS in the cloud, which happens to be the next of my “what operators think” topics, arising from my almost-two-months of exchanges with a variety of operators globally. The LR article covers some things I didn’t get into, and I got into more detail with operators on some other topics. This all adds up to some points I think are interesting.
Let me open with what I didn’t cover in my talks with my operator contacts; the operator politics. I’ve noted in past blogs that there is a real tension within operators on the topic of OSS/BSS. The CIOs are indeed a conservative bunch, but that’s true of almost all the telco executives I’ve dealt with. The unique problem that CIOs have is that OSS/BSS change is, to quote a comment from decades ago, “All cost and no benefit. The best you can hope for is that nobody will know you did it.” But conservative or not, CIOs are under pressure to modernize in some way, and it’s pretty clear that cloud-hosting more of their operations systems has a lot of CEO and CFO backing.
A cloud-hosting decision for OSS/BSS has wider impacts than the CIO organization. The reason why OSS/BSS as a cloud application is important overall is that it’s a primary driver in the early network operator decisions to partner with public cloud providers. Progress in cloud-hosting OSS/BSS would enhance these relationships, teach operators cloud-think, and perhaps accelerate the move to true carrier-cloud infrastructure. A slow roll here might push back operators’ cloud plans for a long time.
Very few operators have really done much with OSS/BSS transformation to the cloud, no matter what steps you define as “transformation”. Smaller operators, who have a harder time sustaining their own data center resources for hosting operations, have been more aggressive in migration. Operators have also been looking to bypass traditional operations systems entirely for new services, and what’s happening in both these areas is interesting.
Perhaps the biggest question in OSS/BSS migration to the cloud is whether “migrating”, meaning simply moving, makes sense. For the last decade, there’s been a powerful and growing set of operator insiders who believe that legacy OSS/BSS is really a bad idea. Thus, to “migrate” what they have is to waste effort cloud-hosting something that’s going to be replaced, inevitably. Of the operators I’ve communicated with, almost four out of five expected that “major changes” to their overall operations software model would be likely within three years.
There are major changes and major changes, of course. All software tends to change over time, and some of the changes seem profound but are actually simple while others seem simple and send everyone back to the drawing board. Most applications will tolerate GUI changes, and many will even tolerate having new data elements added. What’s hard to absorb is a basic change in mission, but interestingly the OSS/BSS is somewhat insulated from that extreme fate by a structural truth.
To understand why this is, you have to look at operations software the way operators themselves are starting to look at it. Don’t think of the difference between “OSS” and “BSS” or the antecedents of either of the two. Think in terms of the way functionality is organized. There are essentially three layers of operations software, and each of these layers is under a different set of pressures. As a result, cloudification of each could be driven in different ways and different directions.
At the bottom are the batch systems that do things like billing and analytics. These systems operate off databases and it’s highly questionable in the minds of two out of three operators that they’d be candidates for change or cloud-hosting. Generally, the data held by and used by these systems are important and regulated, and so the operators are wary of pushing them into the cloud.
The middle layer of software is the transaction processing that does the updates to these databases. The transactions come from a variety of sources, including customer service reps, customer online portals, and network/service operations systems. This layer is much like enterprise OLTP software, and there’s been ongoing work to use the cloud, web, and mobile devices to support at least the front-end portion of these applications.
The top layer is the real-time operations layer, the layer responsible for actually supporting the service lifecycles and the resources that support the services. This layer is handling service and network events, to generate transactions, trigger operations tasks, and perform whatever automated operations responses are available. Obviously, this is a layer that’s subject to a lot of pressure for innovation, and thus is the one changing the fastest under business pressure.
One of the differences between Tier One and Tier Three operators is the extent to which these layers are supported by commercial off-the-shelf general business software. Some Tier Threes use simple tools to handle their operations tasks; I’ve visited Tier Threes who used Microsoft Office components for everything. Tier Ones are more likely to use OSS/BSS products, supplemented in many cases by stuff they’ve developed on their own. Obviously, the more an operator relies on third-party software, the more they’re committed to the cloud strategies of their software provider. That doesn’t mean that it would be impossible for an operator to migrate a commercial software package to the cloud without vendor help, but it would be a fork-lift migration rather than something optimized for cloud hosting, which most operators know is less than optimal.
Another difference is the pace of change/innovation in the three layers. Over three-quarters of operators say their batch-layer stuff is fairly stable, and most Tier Threes and over two-thirds of Tier Twos say that’s also true of the rest of their layers. The Tier Ones, with more services, more regulations, more infrastructure, and more competitive pressure, have seen considerable change in their middle-layer transactional stuff already, focused on improving productivity and customer service. They’re also the ones looking at radical changes in the top layer.
It’s the pace of expected change that raises the biggest questions about OSS/BSS migration to the cloud. There are few vertical markets whose core business software structure has been as static for as long as network operators’ have been. Those who lived through the early days of the Bell System will recognize, in some OSS/BSS systems, the pieces of SS7 and Class 5 switching in some of the implementations. The times, as they say, are a’changing now. Would even the batch layer be designed as it was, were today’s requirements the drivers and not the requirements of yesteryear?
If operator transformation is driven, as operator standards have been, from the bottom up, technology changes (including SDN and NFV) would have the greatest immediate impact on the top layer, where events were turned into transactions and where any form of operations automation would likely hit. If transformation were driven from the top, from the introduction of new services, then the biggest impact would come in the middle transactional layer. The difference here could be significant.
Transactional impact would mean that changes in the middle layer would make it a candidate for cloud hosting and even optimal cloud hosting. Since new services would likely involve new real-time events, the top layer would also be a candidate for cloud-native modernization. If we have mostly real-time operations event impact, the tendency would be to try to preserve the transactions generated by the top layer, to minimize the ripple impact on the transaction layer. That would tend to confine software modernization to the top layer.
Closed-loop or “zero-touch” automation could have a broad impact on both the top and middle layers of OSS/BSS. At the high or “goal” level, the hope is that a customer portal could be the source of service moves, adds, and changes, and also a means of linking users directly with the operations processes intended to rectify service problems. This could cut out the CSR and the associated transactions. At the middle level, the hope is to link condition changes to remedial processes without human mediation, which would eliminate the need to dispatch craft personnel and reduce the role of the network operations center. At the bottom level, it would tend to eat events in the top layer of the software, making that layer much larger and more important, and perhaps eventually even turning the middle layer into a kind of stub between real-time and batch. Even the batch layer could be reduced because the use of portals would reduce the need for commercial paper and the associated processing.
Then there’s pricing. The majority of the batch or bottom layer of OSS/BSS relates to the paperwork in service ordering and changes, and to billing. The majority of the billing transactions relate to service changes that have billable impact. As the transactional middle layer declines, transactions also decline. That means less for the batch layer to do. If you combine fixed-price services with all the other factors here, you can see why a lot of people think OSS/BSS is a dinosaur.
But we’re ignoring the new services. I think it’s true that traditional OSS/BSS will decline gracefully into a largely irrelevant state, if operators remain fixated on selling only connectivity services. If they go more OTT-ish, I could see a lot of new requirements. Would they be fulfilled by the OSS/BSS? That depends on how quickly operators move to these new services. If I were an OSS/BSS vendor, I’d be erecting “Start Selling New Stuff!” billboards outside my customers’ executive offices.