Amdocs, the giant OSS/BSS provider, turned in a good quarter last week. Operations software is a long way from glamorous, but it’s also a long way from irrelevant—Amdocs’ quarter shows that. The relevance of OSS/BSS is one reason why it might play an important role in the evolution of service management and orchestration. The lack of glamour is one reason it might not.
I’ve mentioned in earlier blogs that the process of management/orchestration can be visualized as the creation of functional service objects from cooperating sets of resources, usually drawn from a pool. The beauty of this model, which I’ve endorsed for better than half-a-decade, is that it allows for the creation of a kind of management two-way mirror. From the top, the customer side, you can exhibit functional management properties because functionality is what customers expect to get from services. Their vision of their service is a reflection of themselves. From the resource side, the network operations side, you see not only the resource commitments behind the functions, you see through to the customer.
One of the attributes of abstraction using functional objects is that you could theoretically create a lot of different kinds of abstractions that add up to the same function-to-resource mapping. A simple example is that I could model a VPN as a single “god-box” function, or as a collection of virtual devices. The reason this notion of a floating representation of functional abstraction is important to vendors is that the level at which you abstract determines what part of network/operations software gets all the new management/orchestration roles. That determines which vendors might win, or lose, big.
Let’s say that you build a “VPN” by assembling virtual functions to create virtual devices, then unite these into a single functional element called “VPN”. In this approach, the OSS/BSS systems have no role in the lower-level orchestration processes at all, and in fact “see” nothing different between a VPN created by a legacy NMS and routers, one built on SDN, and one built based on virtual functions. The responsibility for orchestrating behaviors of resources into functions of services lies entirely below the OSS/BSS.
On the other hand let’s assume that we build our VPN from real or virtual devices. We have no “VPN” artifact. Now, services assemble lower-level real-resource behaviors at the OSS/BSS level, which means there’s good and bad news for vendors. The bad news is that the OSS/BSS guys now have to do potentially a lot to get next-gen virtualization-based services to market. The good news is that makes them valuable.
There’s a kind of zone of possibilities in terms of where management/orchestration could lie. At the bottom, you could imagine network processes building functional abstractions from resources and exporting them directly to service operations processes. At the top, the service operations processes could reach down all the way to resources. Anything in between is also possible, which is why management/orchestration could be considered to be nearly anything, deployed by nearly anyone.
Logic does provide some limits to this, though. If we orchestrate resources directly to create services, then we’re either forced to integrate network-technology-specific processes into service definitions themselves, which creates total chaos in a network with multiple vendors and technologies, or build a structure of successive abstractions starting from the top and working down to the point where we divide the abstractions based on how they’re implemented. Now a “VPN” has to exist, and has to spawn the three implementation options I’ve noted.
What that means is that we’re really not changing what gets done, which is the gradual decomposition of logical elements into physical resource commitments, only changing where it gets done. In fact, if you had an agile and flexible way of doing this analysis/synthesis (depending on whether you’re moving down or up, respectively) you could stick it anywhere between resources and OSS/BSS and create what the other guy at the other end needs. Logically speaking, next-gen management/orchestration is one of those few examples of what analysts doing magic-quadrant charts love—a new product category.
The problem with this whole NPC thing is that we can’t have a claim without claimants. In the past, startups would be ballyhooing the media with their entries in this new group, eager to draw that first x/y chart with their stuff the sole inhabitant of the magic upper right. Today, we have no VCs willing to fund anything with a general and complicated mission so there’s no claims being made. Even vendors who actually do most of what’s needed here are reluctant to step up and admit it for fear it involves them in a black hole of sales cycles and pre-sale support. An effort that by the way is unlikely to pay back.
Amdocs, like most OSS/BSS players, is content to presume that there will be enough of our NPC functionality below them to make it unnecessary for them to do much work to accommodate the cloud, SDN, or NFV. To the OSS/BSS guy, it’s all about billing and charging in the end anyway. That’s where pedestrianism catches up with them, because there is a decided risk associated with letting all the new value live outside your own product world. The risk is that all that new value devalues you.
It’s my view that the only way to make our NPC of management/orchestration work is to adopt a state/event presumption. Every functional element is a little state/event process that handles events based on the current operating state, and this is done by vectoring an event to a specific process depending on that state. Instead of “workflow” we have a true real-time handler. For each virtual construct, including the ones that represent real resource commitments, you build your logic by assembling processes into a state/event table.
Which means that any process that works is fine. Which means that operations incumbents who have relied on workflow-driven symbiosis among their multiple elements to create the infinitely large camel’s nose to pull through their whole offering are now point-competitors for every intersection in the state/event table. It completely redefines operations by making service, business, and network operations just squares on a common NPC chessboard. The NPC is no product category at all, it’s a category eater.
You’d think this would be all the more reason for OSS/BSS players to want to jump in. A successful revolution is successful regardless of who plays in it or drives it, but it’s more likely to be successful for you if you are in the driver’s seat. Here’s where the lack of glamour comes in. The fact is that SDN, NFV, and the cloud are not disruptive technologies for OSS/BSS despite the fact that many say the opposite. We could manage the operations of a total-SDN or total-NFV network the same way we do with legacy technology, using intermediary layers as I’ve described here.
What is disruptive to OSS/BSS is the motivation behind all of these new technologies. Operators can’t make enough profits the old way, and so the need radical cost-reducing strategies, or revenue-enhancing strategies, or both. Operations is changed at the fundamental level by what you’re operating, and we’re going to operate different networks and services. This is a high-level, fundamental change. The kind of people who contemplate billing-system enhancements for a living aren’t rewarded for thinking about that kind of shift. That’s what all the OSS/BSS guys and standards groups need to be thinking about.