The TMF has done some very insightful things in the last decade. One of the places where I split from the TMF is the boundary point between operations support systems (OSS) and network technology. My view has been that OSS/BSS should be dealing with functional entities, high-level service-related intent models, and never dig into the implementation of functions. The TMF has a more OSS-centric model, though it may be moving slowly to at least acknowledge the possibility that functional-based OSS/BSS thinking is acceptable. That would make it easier to reflect transformations in infrastructure into the service domain without breaking the OSS, and that’s a priority for many operators.
Light Reading did a piece on Telstra’s work in this space. Telstra is Australia’s dominant network operator, and was (and arguably is) enmeshed in the complicated, politicized, and (many say) doubtful National Broadband Network (NBN) initiative there. NBN has effectively removed the under-network from operators and planted it in a separate “national business”, and so Telstra is forced to consider “overlay” services more seriously than most big network operators. For some time, they’ve grappled with issues that every operator will face, arising from the decline in profits from connection services.
Right now, practically every operator in the world is struggling to create a new network model that optimizes capex through hosting and white-box devices, and opex through service lifecycle automation. At the same time, nearly all are trying to make their operations support and business support systems (OSS/BSS) more agile and responsive. That’s something like trying to threading a needle while break dancing. Linking these goals, meaning making the OSS/BSS handle the new infrastructure, continues a resource-to-service tie that’s been a thorn in the side of operators for a decade or more.
The article says that Telstra is hoping to use the TMF’s Open API definitions to build an OSS that’s more agile and that creates reusable services to limit the number of specialized implementations of the same thing that Telstra is currently finding in its operations systems. The barrier cited is that there’s not yet broad industry support for those APIs, which means that Telstra can’t expect to find OSS elements that support them and can be integrated. That’s an issue, but to my mind there’s another issue that I’ll get to later.
The no-support issue shouldn’t be surprising for two reasons. First, the TMF is first and foremost a body to support operations software vendors and provide them a forum for customer engagement. This isn’t to say that it’s not doing some useful work; I’ve said many times that the NGOSS Contract work the forum did a decade ago was the definitive, seminal, introduction to event-driven service automation. The problem is that a lot of the useful work, including NGOSS Contract by the way, doesn’t seem to get off the launch pad when it comes to actual deployment in the real world.
OSS/BSS vendors are like network equipment vendors; they want all the money for themselves. An open set of APIs to support the integration of operations software features would at least encourage buyers to roll their own OSSs from piece parts. It would lower barriers to market entry by letting new players introduce pieces of the total software package, and let buyers do best-of-breed implementations. Good for buyers, bad for sellers, in short, and in almost every market the sellers spend the most on industry groups, trade shows, and other forums.
If Telstra is hoping for a quick industry revolution in acceptance of the TMF’s Open API stuff, I think they’ll be disappointed, but I don’t think that’s the biggest problem that Telstra faces. For that, let me quote the Light Reading article briefly as it quotes Telstra’s Johanne Mayer: “We started with one technology and added another and then NFV came along and helped us add more spaghetti lines. It was supposed to make things easier and cheaper because it would build on white boxes, but in terms of management it is more spaghetti lines and that makes it hard to deliver anything fast.” The goal is to remove resource-level information from OSS systems and emplace it in service domains, and then to assure that all the service domains map their visions of a given function/feature to a single implementation (or small set thereof). It’s not easy to do that.
The problem here is one I’ve blogged about many times, and reflected in my ExperiaSphere work (see THIS tutorial slide set). Operations systems (in the kind of view Telstra wants) are disconnected from the resources by recognizing that there’s a “service domain” where functions are modeled and composed into services, and a “resource domain” where the functions are decomposed into resource commitments. If this explicit separation is maintained, then it’s possible to build services without making the results brittle in terms of how the services are implemented, and also to provide for whatever level of multiplicity of implementation of a given function might suit the operator involved. If there is no separation here, then you can’t remove resource-level information from OSSs because it would intertwine with service composition.
It’s fairly easy to convey the notion of service and resource domains, and the mechanism for composition in each domain, if you presume a model-based approach that recognizes the idea that any given “element” of a service is a black box that might decompose into resources (resource domain), or might decompose into other elements (which might be in either the service or resource domain). My presumption has always been that there are “service models” that describe functional composition, and resource models that describe resource commitments, and that the juncture of the two is always “visible”, meaning that service-model “bottoms” must mate with resource-model “tops” in some agile process (that’s also described in the referenced presentation, but more detail is available HERE, where you can also find a description of service automation, another Telstra goal).
Service/resource separation and compositional modeling are critical if you intend to expose service-building through a customer portal. If the modeling follows the approach I’ve described, then lifecycle management tasks are integrated with the models, which means that support is composed in parallel with composition of the service features. Moreover, the tie-in between the service and resource layers creates a set of model elements that present service-abstracted properties to service-builders, and permits any kind of implementation that meets those properties to be linked.
That’s an essential piece of any goal to reduce the integration burden, which Telstra says is now 80% of the cost of features and that they’d like to see reduced to 20%. Without some master target for feature implementations to meet, it’s impossible to present a consistent view of features to the service layer when implementations are different, unless all those implementations were harmonized somehow. That means that some resource details could not be separated from OSS concerns, as Telstra wants.
The frustrating part of all of this is that nothing that Telstra wants, and nothing that isn’t currently available in a uniform way, should come as any surprise. These issues predate NFV, as the timing of the TMF’s NGOSS Contract work proves. The TMF also grappled with them in their own Service Delivery Framework (SDF) work, another project that did good stuff that somehow didn’t move the market to implement it, and that again predated NFV.
Back in March of 2014, I did a final report to the NFV ISG on NFV objectives as I saw them, opening with these four goals:
- To utilize cloud principles and infrastructure to the greatest extent possible, but at the same time to ensure that functions could be hosted on everything from the cloud through a chip, using common practices.
- To support the use of any software component that provided network functionality or any other useful functionality, without change, as a VNF, providing only that the rights to do this were legally available.
- To provide a unified model for describing the deployment and management of both VNF-based infrastructure and legacy infrastructure.
- To create all of this in an open framework to encourage multiple implementations and open source components.
These seem to me to be the things Telstra is looking for, and they’re half-a-decade old this month. What happened? Did the ISG reject these goals, or did they just not get realized as so many good TMF projects have gone unrealized? The point to me is that there is a systemic problem here, not with our ability to define models that meet our long-term objectives in service lifecycle automation, but with our ability to recognize when we’ve done that, and implement them.
The challenge the TMF faces with its Open API Program in extracting resource specificity from services is similar to the one that the NFV ISG faced in integrating NFV with operations systems. You have two different communities here—the OSS/BSS stuff with its own vendors and internal constituencies, and the NFV, SDN, and “network technology” stuff with its own standards groups and CTO people. We’ve seen both groups try to advance without paying enough attention to the other, and we’re seeing both fail.
There are some players out there who have taken steps in the right direction. Cloudify has done some good things in orchestration, and Apstra has made some strides in resource-layer modeling. Ubicity has a good TOSCA modeling framework that could be applied fairly easily to this problem, and there are startups that are starting to do work in cloud orchestration and even “NetOps” or network operations orchestration. All of these initiatives, I submit, are at risk to the same problems that the TMF’s Open API program faces—sellers drive our market and sellers aren’t interested in open frameworks.
Buyers aren’t much better. The ETSI work on service lifecycle automation should have started with the discussion of modeling, service and resource separation, and event-driven, model-guided, operations processes. That was the state of the art, but that’s not what was done, and service providers themselves drove it. Same for ECOMP. If we’re not getting convergence on the things network operator buyers of operations automation technology need, it’s because the operators themselves are not wrestling effective control of the process. They’ve tried with standards, with open-source initiatives, and they still miss the key points of modeling that you can’t miss if you want to meet your service lifecycle automation goals.
The Light Reading article ends with Telstra’s Mayer expressing frustration with the lack of those function-to-implementation connectors discussed above. “There is no such standard as firewall-as-a-service and I am looking for a forum where we can agree on these things and speak the same language.” Well, we’ve had four that I’m aware of (the TMF, the IPsphere Forum, the NFV ISG, and the ETSI ZTA initiative), and somehow the desired outcome didn’t happen, despite the fact that there were explicit examples created of just what Telstra wants. I think Telstra and other operators need to look into what did happen in all those forums, and make sure it doesn’t happen again.
Without an open, effective, way of creating the function-to-implementation linkage, there is no chance that resource independence or no-integration service-building is going to happen, and the TMF alone doesn’t provide that. My recommendation is that those who like the points I’ve made here use the ExperiaSphere project material I’ve cited and the other four presentations to either assess the commercial tools (some of which I’ve mentioned here) or to frame their own vision. All the concepts are open for all to use without licensing, permission, or even attribution (you can’t use the presentation material except for your own reference, or use the ExperiaSphere term, without my consent). At the least, this will offer a concrete vision you can align with your requirements. That may be the most important step in achieving what Telstra, and other operators, want to achieve.