Suppose that the telcos were to follow the implicit recommendation of the TMF/Tech Mahindra report I blogged on earlier, and create a “ServCo/NetCo” separation of their organization. How would that transformation happen, and where would the current organizational elements fit in the new picture? That new organization was, IMHO, the best part of the report. Setting aside for a moment my objections to the report, based on its failure to address either a credible new service set or a technology shift needed to create one, could the organizational changes really be possible?
The report characterizes the two pieces of the new organizational model thus: “The asset-light ServCo component of any future CSP needs to be extremely flexible and predictive of market demand. The asset–heavy NetCo component of any future CSP needs to be hyper-efficient, which means a strategic laser focus on automation and simplification”. The implication here is that NetCo owns the classic network and ServCo owns the service-related elements and processes. That’s obviously too simplistic to be helpful.
A later figure (on page 14 of the report) might make things clearer. This figure confines both NetCo and ServCo to the bottom of a three-layer process set, and defines the two higher layers as being provided by partners or at least by other organizations. It’s that point that leads me to say that the report is really recommending not an end to disintermediation, but a formalization and expansion of it. Thus, I think that while there are surely plenty of people in telco executive positions who’d love to go back to “Watson, come her,” I don’t think that’s a sustainable strategy. That, in turn, means we have to redraw the concept shown on page 14 and redefine what makes up the NetCo and ServCo elements, and that’s not at all easy.
Start with the Office of the CTO, or what used to be called “science and technology.” This is the piece of a telco/CSP that does the standards work, trials out new technologies, and so forth. NFV, 5G, and other network initiatives come out of that group, and those initiatives are pretty clearly a NetCo element because they deal with basic infrastructure. However, almost every telco says that 5G and NFV are the likely sources of infrastructure for multi-access edge computing (MEC), and MEC is probably essential in any real advances in the mix of services a telco could offer. Thus, essential to ServCo.
How about the CIO organization, the place where OSS/BSS lives? Part of these systems address the network for sure; the original OSS/BSS map included the inventory and management of network facilities and elements. Today, BSS elements generally run the business and OSS elements run the network. But BSS includes product management, customer management, and revenue management and those are surely more ServCo than NetCo. On the OSS side, everyone thinks that management of the network devices are included. In addition, over 80% of operators think that management of hosting resources for functions and features are as much a part of the network as routers are. That would make them all NetCo, except that advanced services that utilize connectivity, like MEC, would likely fit better in ServCo.
The net point here is that remapping an organization to the new model is going to be a challenge because the practices and tools in use today, and in some cases in use for many decades, favor the current organizational structure. Telcos play in network standards, and so CTO responsibility for them logically fall with NetCo. Telcos also have started to dabble in cloud standards; look at the Nephio project to adapt Kubernetes to deploy feature/function elements of services and to manage, at least in theory, non-server platforms. That sure sounds like ServCo. And OSS/BSS providers usually deploy their entire suite for a telco, not just pieces, so it’s hard to say how you’d divide that across multiple organizational elements.
The insight that I think we can identify here is simple; no matter how difficult it might be, we have to structure a telco differently if we expect them to do business differently. However, in order to do that, we have to presume a framework of infrastructure and technology elements that we can align our new structure to, and that will help us assign responsibilities that were clear under the old organizational model to the right place in the new. I propose we do that with a different structural alignment, but one that’s really only slightly different.
In my model, NetCo is responsibility for connectivity only. It owns the standardization, testing and evaluation, operations and management, of the traditional network resources, consisting of trunks and nodes. It also owns the software tools that are used to perform these tasks, which means it owns a lot of the OSS elements. Finally, it owns the server resource pools that will host features, either as infrastructure or in the form of relationships with cloud providers.
ServCo, in my thinking, is responsible for service planning, service sales/marketing, customer support, and so forth. This layer owns the BSS tools associated with that. It would also own “service management” in the sense that it would be responsible for assembling a combination of connectivity and features needed to produce and sustain a sellable service.
The difference in my approach and the model the TMF paper proposes is that I add a FeatCo, or feature company, in between the other layers. FeatCo is responsible for the software that implements the features and functions that are exposed as retail or wholesale products. These are hosted on NetCo-controlled resources, and marketed, sold, and supported by ServCo. This layer is where the service value-add is created, and it could incorporate both telco-provided features (including connectivity) and third-party features.
The obvious question at this point is just how the feature implementation process works, and more broadly how function/feature hosting integrates with all of the layers. As I’ve pointed out above, you need to presume some framework or architecture model in order to organize the new structure of operators around something, and to provide a target toward which existing infrastructure and organization can be aimed in migration. The TMF paper doesn’t offer one, but might there be another source?
At roughly the same time as the TMF paper came out, the Next Generation Mobile Networks Alliance (NGMN) came out with a paper called “Cloud Native Manifesto: An Operator View”. We’ll address how that might fit the role of this essential framework in a later blog, and it may be interesting to see how it fits with the overall model I describe here.
