Is zero-touch automation synchronized swimming or just playing in the pool? That’s a perhaps-less-than-elegant way of asking whether ZTA requires a unified orchestration model, or can be achieved while retaining the separation of network and service management. This is important because we don’t have unified standards or unified telco management across those two spaces, and if we do need a single model, we may struggle longer to get to our goal.
Historically, network operators have had three technical divisions—operations, science and technology, and OSS/BSS. These are ruled by the COO, CTO, and CIO, respectively, and the three organizations are polarized enough that operators have tried forming executive-level teams to address what should be common strategies. It’s not been a rousing success.
At the technical level, we have had a similar separation in infrastructure and spending, but this time we have two major focus points—the network operations activities that center on the network operations center (NOC) and network management systems, and the service operations activities hosted within the OSS/BSS framework. Both of these areas have evolved as networks shifted from a provisioned TDM model to a capacity-planned packet model, and as services shifted from incident billing to period billing. They’ve not gotten closer together, and in many of my discussions with operators I’ve actually seen more tension between the various technical models and the organizations that sustain them.
SDN and NFV threw a new complexity into the mix, largely because both technologies presume a more complicated technical structure aimed at reducing costs. Complexity, of course, is never cheaper; the opposite is true. Orchestration, in some form, is the reaction to this added complexity and the associated risk of rising opex. You can see this most clearly with NFV, whose Management and Orchestration and VNF Manager (MANO and VNFM) sought to address the new and more complicated model of creating functions by stitching components hosted separately.
SDN and NFV management have focused, I think for convenience rather than as a strategy, on making virtual stuff look and behave at the management level, like the physical element that’s replaced. A VNF-based virtual CPE (vCPE) deployment “looks” like an appliance, which means that management practices outside it could theoretically stay the same, both in terms of human interaction and management systems. Orchestration, then, focuses on making management inside the box automatic. A virtual device, in modern terms, is then an intent model that’s self-managed or at least zero-touch-managed against its SLA.
The industry has waffled on the point, but now it’s pretty broadly accepted that intent models are deployed and sustained using a data-model-driven process, increasingly based on OASIS’ TOSCA standard. A model-driven approach lets a common software structure handle diverse network elements and events, which is important if you want to avoid rewriting management processes every time you deploy or sell something new. The need for agility in the management of stuff contained within an intent model naturally raises the question of why you’d stop with ZTA when you’d replicated your old management model. Why not try for something better? That’s the question that gets us to the problem of synchronized swimming versus pool anarchy.
Think of the question as being one of scope. If I can model infrastructure and automate network management practices, and if network management is related to service management (which it clearly is) then why not model both at the same time and create ZTA across all processes? A given state/event combination could just as easily activate an OSS/BSS process as an NMS process, at least in theory.
But look at the flip side, meaning look at things in terms of event flows. The great majority of things that happen at the network infrastructure management level have no reason to be visible at the service management level. Network management remedies network issues, and if remediation is successful there is no service event at all. Similarly, if a customer is late paying a bill, that may have to trigger a service-level reminder, but I’ve never run into an operator who proposed to prep the network for a possible no-pay service deactivation. You’d wait till you made the commercial decision, then send a deactivate event to the network.
The point is that services and infrastructure are loosely coupled. Everything that happens in one of the areas doesn’t propagate, even indirectly, into the other. That means that it is not necessary to unify the two areas in a common orchestration/ZTA model, from an automation perspective at least. There are other benefits, however.
One of the main reasons why operators say they’d like a common approach to service/network infrastructure ZTA is that it’s inconvenient to learn and maintain two different toolkits, and to synchronize their behaviors when something changes either in the service framework or the network. This view is widely held among operators, but not widely held within them; organizational separation has tended to make a unified model look difficult to establish and sustain.
Another benefit of a common model is that most operators think they need to transform their OSS/BSS systems to be more event-driven, and if you’re going to do state/event processing in network ZTA, it would be nice to simply extend that into the OSS/BSS. The same problem is evident here, though. Operators fear that trying to unite services and networks in ZTA will raise internal barriers.
My work with ExperiaSphere suggests that there are perhaps a half-dozen events that cross the boundary between services and networks. Thus, with today’s services, it’s really difficult to frame a specific need to apply common ZTA logic across both the service and network domains. It’s going to be a matter of finding the best approach, which is one that works “locally”, can be integrated where there is interdependence, and can be sold internally without protracted political battles.
Let’s turn the question around, now. The biggest reason to keep ZTA separated is that it’s developing that way anyway. There are a number of credible initiatives for ZTA in the OSS/BSS space, and where there isn’t an easy path to ZTA in OSS/BSS, the path may be very difficult. Enough, in fact, that it could slow up ZTA in the network space.
The biggest barrier to independent ZTA for networks and services may be effective management of the event connection between the two. A more robust notion of intent modeling could help here, since a service and a network, in management terms, could be visualized as high-level intent models. In that architecture, passing events between the models is an essential piece of coordinating behavior, and so we might get a lot of value from simply defining a “service” and a “service-infrastructure” as high-level events with their own event sets. Vendors or operators would be free to do what they liked inside, as long as they harmonized to the specific standard at the border.
I still think it would be better to adopt a single model here. I think that too much vendor differentiation or even too many open-source solutions will only dilute efforts and make integration/harmonization more difficult. Sadly, I think the opportunity to achieve that has passed, so we should probably focus now on how to get the second-best approach to work optimally—and quickly.