A unified lifecycle automation model, as I noted in my blog on March 15th, seems to be the only way for operators to stabilize or reduce opex, now that they’ve used customer care portals to pick the low apples of high-touch support. I’ve suggested that this would likely involve creating a single state/event-driven model for service/network/OSS/BSS, and that it could impact future profit per bit trends. How? That’s what we’ll look at today.
OSS/BSS systems, the biggest consumer of IT resources for operators today, are often based on a hierarchical service model like the TMF’s SID. I’ve suggested in recent blogs that this approach could be modernized to allow for hierarchical decomposition of elements, explicit intent model principles, and perhaps a link to a digital-twin model of infrastructure. However, I was really looking at lifecycle automation in terms of the operational lifecycle rather than the entire lifecycle. Let’s start with the difference.
In operations lifecycles, we could expect the process to start with a service in a state we might call “orderable”, and an event we could call “order”. That event would initiate the process of decomposing a commercial-feature model downward into resource commitments. The “order” would presumably emerge from the commercial side of the service, which could be an OSS/BSS element. Could we, should we, model that commercial side?
Portal technology has proven that it’s possible to rethink “service operations”, eliminating the OSS/BSS model in favor of treating customer orders for service or service change as transactions, transactions for which we have a cloud front-end. Work I’ve done with regional business service operators suggests that these companies tend to create a portal-based system rather than adopting traditional OSS/BSS. As I’ve noted before, about half of a given Tier One organization seems to want to trash OSS/BSS and start over, presumably with a portal strategy.
It’s not quite that simple, of course. There are two sides to OSS/BSS, one focused on managing the order/support processes (especially billing) and one focused on managing “resources” that include the field service people and higher-value trunks and service elements. For example, where do we have capacity on a “multiplexer” to connect a new access point? We could surely convert a lot of the process to a portal-based system, using for example the public cloud to front-end current systems. We could also use the “new” portal to generate events to our state/event process. However, in order to do all this, we’d need to build event-driven process elements to replace the current transactional OSS/BSS frameworks.
What’s actually happening in most telcos and many cable companies is that there’s an “OSS/BSS modernization” movement aimed at “real-time” behavior. In practice, this is sort-of-creating the same model for OSS/BSS applications that we’re seeing in enterprise applications, meaning that it’s building a web/cloud front-end to a legacy system. That has been helpful in that it’s limited the impact of automated customer care on the balance of the operations systems and practices, but it’s also limited the extent to which we can actually unify operations. The relationship between OSS/BSS and NMS, in particular, has been largely sustained, and since I’ve noted that the relationship between NMS and virtual functions sustains the device-management model of traditional networks, we have created a chain of limitations.
That chain of limitations is further sustained by the public-cloud dependence that’s growing among operators who deploy 5G or other virtual-function-based applications. That’s because this move taps off the need to create IT operations systems that are more efficient; public cloud operators now do the IT operations. And, of course, because new IT operations systems would be the easiest way to “modernize” and “unify” lifecycle automation.
IT operations, in the wider world, is in large part application operations. While there is normally a mechanism for identifying broken IT elements that are not currently committed as application resources, the primary focus is to redeploy applications around the stuff that’s broken. Repair of the resources themselves is a manual, offline, task.
Application operations is increasingly event-driven, meaning that steps are taken to remedy problems, triggered by a report of a problem. Scaling and redeployment, for example, are attributes of a container/Kubernetes platform, and issues are triggered by a report of an issue by a distributed element, or by having a distributed element disappear and stop reporting.
OSS/BSS systems are just applications, core business applications like those found in virtually every industry. Things like order entry, customer care, CRM, ERP, and so forth have counterparts in both OSS/BSS and other industries. Operators’ CIO organizations and their vendors have, not surprisingly, resisted any thinking that OSS/BSS has no reason to be “different”. However, there is increased recognition that OSS/BSS needs to be modernized, made “event-driven” or “real-time”.
Some vendors are making progress in that area, and a truly event-driven OSS/BSS would be a very critical step. We don’t seem to be there yet, and I’m not even sure that there’s general movement in that direction at the technical level. The current vendor approach is to do something based on events, and then say they have an event-driven system. PR conquers all, I guess. However, a movement toward virtual-function hosting in any form could break the logjam for three reasons.
First, virtual-function hosting would really require a modern event-driven, application-centric, IT operations model. Such a model, derived from the broader IT marketplace, could then spread to the OSS/BSS space to manage OSS/BSS as an application, which could then encourage a more general commitment to industry practices for application operations and event-based automation.
Second, virtual-function hosting isn’t a CIO activity, it’s a network operations activity. The CTO and COO would have a greater role, and they have a much different, much broader, vision of lifecycle automation. A pool of operations people, focused on aggressive opex management, would quickly become the largest source of IT expertise within an operator organization, where the CIO group holds that title for most today.
Third, virtual hosting almost surely means a resource pool, and if there’s a resource pool available there will be pressure on the CIO people to host their OSS/BSS on it. Given the above two factors, that is very likely to shift the power of IT operations completely, and that in turn would likely stabilize lifecycle automation views around the network-centric model of function hosting. OSS/BSS is then just an application.
Which brings me to the final point. OSS/BSS systems are leftovers from an era when “provisioning” meant sending out field techs and making connections, running wires, and testing stuff. That high-touch past is totally impractical in the modern age of consumer broadband. We don’t “provision” services any longer, we “coerce” them from pools of resources. You don’t have your own Internet, or even your own broadband. You have access to a pool. Aren’t we then already at the point where OSS/BSS relevance is slipping away? Isn’t managing that pool of stuff now the real requirement. Worth thinking about.