What the heck is an NGOSS? I’ve used the term a lot, relating to the “NGOSS Contract”, but for those not familiar with the OSS/BSS space or the TMF, it may be mysterious. Tata Consultancy Services, a large and active professional services firm, recently did a paper on “reimagining” the OSS/BSS, a TMF paper asking whether there’s life beyond connectivity services. There are interesting contrasts and similarities between the two documents, well worth exploring.
NGOSS stands for “Next-Generation Operations Support System”. It’s a term that’s been widely used for at least 15 years, and it’s often used by the TMF in their specifications. A lot of the TMF stuff is members-only though, and so I can’t cite it (or, if I’m not a member at the time, can’t even access it) except by summarizing. The TMF paper is particularly helpful because of this; it’s a public summary of the way the body sees the future of “transformation”. The Tata paper is interesting because it reflects a professional-services view of the same process of transformation.
The opening of the Tata paper has the usual platitudes about bandwidth. “As businesses increasingly adapt to a predominantly online model in line with the new reality, the need for high bandwidth and reliable network services is soaring. Consequently, communications service providers (CSPs) are experiencing exponential demand for services and are dependent on progress in virtualization technologies to continue scaling at current rates.”
The problem with this, besides it’s platitude status (one more “exponential” demand statement and I’ll puke), is that the real issue isn’t demand growth, it’s profit shrinkage. No operator would be unhappy with growth in demand for bandwidth, if they could charge incrementally for the growth. They can’t, so they need to either find something other than bandwidth to sell, or cut the cost of producing bandwidth to offset the fact that higher bandwidth services don’t generate proportionally higher prices.
This same issue colors the next section, which is called “Rethinking the OSS Function”. It cites TMF objectives for OSS modernization, none of which even imply dealing with that profit compression problem. In fact, that section of the document is why a lot of operator strategists are in favor of scrapping the whole OSS/BSS thing and starting over. It’s not that no useful goals are set (automation is one of the attributes of a future OSS/BSS), but that nothing much is said about achieving them.
That comes in the next section, which is called “Driving Well-Orchestrated OSS Functions”. This section finally makes a recommendation that’s useful; OSS/BSS has to be made event-driven. I had hopes here, because the TMF was in fact the source of the key concept in OSS and operations automation—that NGOSS Contract I mentioned at the start of this blog. Sadly, neither the term nor the concept is raised in the Tata paper. What it says is that “future OSS functions must be created and offered as services composed of microservices to support automated end-to-end orchestration of hybrid (physical, logical, and virtual) network resources.”
The TMF paper, in contrast, opens with the statement that “connectivity is rightly seen as a low margin business and is rapidly commoditizing further.” The goal of operators is “getting their interior world right with an agile technology foundation and operating model.” The TMF obviously includes its primary OSS/BSS target in this interior world, but just as obviously the agile technology foundation has to extend to infrastructure.
The mechanism of getting their “interior world in order” is, by implication, 5G. The TMF says that it’s critical in order “to make the most of the hugely expensive shift to 5G.” But that seems to be contradicted by the next paragraph, where the former CEO of the forum says “For consumers and smart home individuals, ‘connectivity’ tends to have an intrinsic value and is a valid thing to be purchasing. As you go up the scale, however, into the industry transformation realm, connectivity is only valued in so far as it is tied into the solution: “They don’t want to buy connectivity from you, they want to buy a solution.” 5G is clearly a connectivity strategy for consumers, as all mass-market infrastructure is. If we presume that to “go up the scale into the industry transformation realm”, meaning business services, the key is to sell solutions.
This seems to argue for the operators to focus their “digital service provider” business on enterprises, and to provide solutions there is to be a SaaS provider. Is that really a smart approach, given that there’s a highly active and competitive public cloud business already selling solutions to those customers? Especially when the majority of the profit-per-bit problems operators have comes from all-you-can-eat consumer services?
The resolution, says a Vodafone quote and other comments in the TMF paper, is that “what we now call ‘services’ won’t involve the telco alone, but will comprise a range of partners, including the telcos.” Thus, the telcos aren’t really digital service providers at all, but digital service integrators or resellers. Can a business that’s looking at transformation as a means of escaping profit squeeze afford to be a reseller of another player’s services?
It seems to me that the TMF vision is really not aiming beyond the OSS/BSS at all, but rather is suggesting that operations and services evolve to something above connectivity by partnering with those who supply services up there. That could be defeating the whole purpose of “digital transformation”, locking the telcos into not only their current level of disintermediation and commoditization, but also in a whole new level.
Both papers seem to suggest that OSS/BSS transformation is essential, and at least imply that an event-driven approach is the answer. That’s actually a good idea, but it misses the challenge of “how?” In order to be event-driven, a system has to recognize both the concept of events (obviously) and the concept of “state” or context. Anyone who’s ever looked at a protocol handler knows that the same message, in different contexts/states, has to be processed differently. For example, getting a “data packet” message in the “orderable” state for a service is clearly an error, while it’s fine in the “data transfer” state. For there to be states and events and related processes, you need a state/event table.
State/event tables are descriptions of the collective contexts of a cooperative system, and thinking about building them is useful in that it forces software architects to consider all the possibilities, instead of having something happen that falls through the cracks. However, there’s a potential conflict between the value of state/event tables and the number of possible states and events. If you look at a complex network as one enormous, flat, system, you’d have way too big a table to ever implement. The TMF and my own ExperiaSphere work dealt with this by dividing complex systems into “intent models” that each had their own state/event relationships. Hierarchical composition, in short. That’s what NGOSS Contract described.
The point here is that both papers miss what should be its own strongest point, which is that data-model-driven steering of events to processes via component-aligned state/event tables is the way to create both event-driven behavior and microservice-compatible design. If a service data model drives an event to a process, the process can get the information it needs from the service data model alone, which means it’s stateless and can be deployed as a microservice or even in serverless form.
If you pull the NGOSS-Contract approach out of the OSS/BSS modernization story, you’re left with the thing that has plagued the whole notion of OSS/BSS modernization from the first—platitudes. We can talk about bottom-up and top-down as long as we’re focusing on project methodologies, but a project methodology drives a project, it doesn’t write software. A software architecture should emerge from the methodology. That’s a separate element, a result of the right process, but it’s not the automatic consequence of waving a wand over a bunch of data and chanting “top-down, top-down!”
That sums up my problem with the Tata paper. Project methodologies in IT and networking lead to application or service architectures, which then frame the requirements for the components of the solution and the way they’re integrated and managed. The project is not the output, it’s the path to the output. The problem with the Tata paper is that it’s yet another description of a project methodology (a good one, but not a transformative one), at a time when we’re long past looking for a path to OSS modernization and instead are looking for specific products, or at least architectures. The TMF seems to be heading to the same place by a different path—transform by partnership with your former enemies.
The Tata paper does, in the section called “The Role of Industry Standards”, call out an important problem, one so important it might actually be the barrier to progress toward the OSS modernization goal. The paper cites the TMF and ONF models for top-down design, but throughout the paper it’s clear that the “modernized” OSS/BSS has to be more tightly integrated with the rest of the network and service ecosystem. We have standards for every possible piece of every possible network strategy, and in some cases the standards even compete. We recently heard applause for the unification of two different operations API specifications, for example. We should be asking how we came to have them in the first place.
The TMF paper seems to not only accept this fragmentation of the future, but depend on it. Cede the mechanization of stuff beyond OSS/BSS, and focus on harnessing that “beyond” stuff to create services as a pseudo-integrator. OK, that may not be an unreasonable view for the TMF (an OSS/BSS-dominated body) to take, but it’s a formula for staying disorganized while facing what almost has to be a unified initiative—transformation.
It’s my view that the TMF was the logical body to modernize the OSS/BSS, and that the TMF did (with NGOSS Contract) devise the central paradigm of event steering to processes via a data model, that’s critical to this modernization. Everything else the papers describe, every API anyone is developing or harmonizing, every standards activity aimed at any aspect of operations and management, should be fit into that NGOSS Contract framework. If that were to be done, the result would be exactly what “NGOSS” stands for.
The model of the TMF NGOSS Contract is just as valuable, or even more valuable, if you step into the network domain. A true “contract” state/event process could manage everything about the service lifecycle, including the network piece. It follows that a network-centric solution could easily be extended into the service, the OSS/BSS, domain. The universality of the approach is good for the industry, because service lifecycle automation should be universal to be useful.
It should also be based on state-of-the-art cloud-think. Both papers seem to agree with that, and yet both skirt the question of how to bring that about. If you’re planning to use current tools to accomplish something, you have to frame your approach in terms of those tools. You can’t accept the notion that you can write specifications for everything, or simply translate goals at the top to arbitrary features at the bottom. That’s especially likely to bite you given that the standards processes take years to come to a conclusion. We’re deploying 5G today and the standards aren’t finished, and likely won’t be until 2022. I wonder if there’s time for that stuff, given that operators are already facing falling infrastructure ROIs that are nearing the critical point.
NGOSS Contract has been around for about 13 years now, and the TMF once told me that it had gained very limited traction. It doesn’t seem to be played in the current TMF material, though as I’ve said, I don’t have access to the members-only stuff. The question, then, is whether the TMF is prepared to promote its own (dazzling and unique) insight, first within the narrow OSS/BSS domain and then in the broader lifecycle automation mission. If it does, the TMF takes its rightful role in NGOSS evolution and defines the basis for service lifecycle automation overall. If it doesn’t, the it will be up to some other standards body or open-source group to pick up the torch, and the TMF will then have to fight for relevance in its own space.