Some New Insights on “Transformation”

Transformation is surely the key topic for telco executives, and that’s been true for over a decade.  I had a series of interesting discussions with telcos over the last three months, hoping to gain some clarity on the nature of their transformation plans.  Perhaps I shouldn’t have been surprised to find that there was little real detail available.  In fact, one senior planner gave me what I think was the comment that encapsulated the whole experience.  “Transformation,” he said, “is the process that turns our business from what it is to what we want it to be.”

Hope springs eternal, but it rarely generates results.  The comments got me thinking about just what transformation was, and was not, and that set me to doing some modeling on the topic.  I want to convey the results here.

The first point to emerge was that it is no longer possible for service lifecycle automation to create revolutionary changes in profit per bit.  I noted this in a couple of prior blogs, but the new models show that the best one-third share of addressable opex reductions (the share representing the highest ROI) have already been reaped, using point technology and less broadly efficient means.  The opportunity to use those savings, which amounted to almost nine cents of every revenue dollar, to fund a massive opex automation project was lost.

This is perhaps the most critical truth in all the transformation story.  Cost efficiencies are typically the easiest to address in projects because it’s possible to establish the benefit case clearly and usually possible to frame software and process model that can achieve it.  The problem was that we waited for over five years from the time the need for service lifecycle automation was identified to even catch a glimpse of the right path, and that glimpse has come from the cloud software model not from the standards process that telcos (sadly, and misguidedly) still believe in.

The point here is simple.  Opex low apples have been picked, and even if the telcos were to suddenly realize that they needed only to employ cloud measures and concepts to reduce opex, decisive changes aren’t available today at the same high ROIs that were available five years ago.

If you can’t improve profit per bit by reducing cost per bit, you have to raise revenue per bit.  Higher revenue per bit means more spending on services, of course.  The second point that emerged from the models is there are no new forms of connection service that have any positive impact on revenues.  The Internet revolution created two service communities, one focused on creating experiences (which we call “the OTTs”) and the other on delivering the connectivity needed for the first.  Operators comfortably hunkered down on the second mission, leaving the OTTs to the first.  To fix that, there’s no option other than for telcos to start mining the OTT revenue opportunity in some way.

Mining the revenue opportunity is not another term to describe providing that vanilla connectivity whose revenue per bit can only continue to decline.  If 5G is five times or ten times the speed of 4G, will it cost five or ten times as much?  If so, nobody will buy it.  Thus, no new telco service technology can succeed if it expects to deliver a lot better connectivity for little or no increase in price.  Price divided by bits, after all, can get bigger only if price goes up faster than bits do, and we all know that’s never going to happen.

OK, what pushes bits?  Network equipment.  If we have non-bit services, those non-bit services won’t come from network equipment, they’ll come from experience-creating equipment.  What kind of gear is that?  Data center hosting systems and software platforms.

That establishes our third point, which is that the success of transformation can be measured by the shift of telco investment from network devices to carrier cloud.  If operators spend (as they do today) way over 95% of their capital budgets on network equipment, they’re not transforming, much less transformed.  My models say that there has to be a shift of at least 15% of capex to carrier cloud to validate the notion of transformation.

Getting there is, and has been, the big issue.  I’ve modeled opportunity drivers for carrier cloud for five years now, and the modeling has consistently showed three phases to carrier cloud opportunity maturation.  The first phase, ending in 2020, is driven by “visible” and near-term opportunities, including NFV, mobile modernization (IMS/EPC), and video/advertising.  This phase should have created about three thousand carrier cloud data centers by 2020, and is falling short by over 50%, largely because operators took too long to define an approach to the opportunities, and when they did, failed to define one that could be implemented using current market tools.

The second phase of opportunity, ending in 2023, is related to mobile 5G modernization.  This driver, of course, has been present in the first phase but it’s already failing to realize the full opportunity.  The largest driver remains video/advertising, which is as I’ve said falling short even now, and operators show no signs of recognizing what IoT should produce for them.  Thus, the model says we’ll fall further behind the opportunity curve in the second phase.

If that happens, operators will have little chance of realizing that 15% capex shift, and little chance of a successful transformation.  However, even if operators get on the right track in terms of thinking, they will still face that problem of reliance on traditional standards rather than on cloud software.

Carrier cloud is a two-dimensional issue; one “functional” and the other “mission”.  The functional dimension relates to the hardware/software platform on which carrier cloud is to be hosted, and the mission dimension to whether the application of the carrier cloud infrastructure is “internal” to the operator (used to support service creation) or “retail” to a customer, including enterprises.  The two interplay in significant ways.

Cloud infrastructure today is largely based on a series of layers, with the bottom being an efficient hardware platform with all possible network acceleration.  The second layer is a very high-performance hypervisor that creates very efficient VMs.  Layer three is a virtual-network layer that creates the connectivity needed among the elements both below (the VMs) and above.  The “above” is a container layer, which would form the foundation for both operator internal services and retail and enterprise services.

The challenge in picking technology for these structures is that the current focus of the cloud market is the cloud buyer, not the cloud seller.  Carrier cloud is, as I’ve said above, a combination of an internal and a retail mission.  The retail mission isn’t about using cloud services but providing them, and the internal mission of operators has requirements that public cloud services overall may not recognize.  High data-plane speed is a requirement for some telco missions, and not for most retail missions.

You can see an example of this in the area of service mesh.  A service mesh is a framework in which microservices deploy, including load balancing and related features.  It’s an essential part of a retail microservice-cloud application, and it would likely figure in internal telco applications…except perhaps for the issue of performance.  The top service mesh, Istio, is far slower (perhaps ten times slower) than native microservice connectivity would be.  Linkerd, the service mesh de jure of the Cloud-Native Computing Foundation, is faster but still five times slower than native.  Telcos looking for a carrier cloud service mesh should be looking at this point, but none of the planners I talked with in the last three months were aware of it, and few were even aware of service mesh.

Virtual networking is another major issue.  The most important work being done with virtual networks is in the SD-WAN space, which currently focuses on enterprise use rather than on how virtual networking separates tenants in a multi-tenant provider network.  In addition, given that “network services” that include connectivity have to merge public address spaces with hosting and tenant isolation, they present a whole new set of challenges.  Operators need to address these, because cloud technology continues to focus on the retail buyer.

The risk the telcos are taking, and the risk they must avoid at all costs, is that they resolve the near-term carrier cloud opportunities using the same piece-based solution strategy they employed for opex.  They would then never build a correct carrier cloud platform, and never be able to combine the hosting of the various drivers in an efficient, optimum, way.  If that happens, they’re in big trouble with both carrier cloud and transformation.