Software is the iceberg that continually sinks the aspirations of traditional telcos to become nextgen telecom solution providers and offer network infrastructure and services with “cloud-like agility”1.
In the traditional telecom world, that software is always about OSS/BSS.
I was recently reminded of this when I read an investment report by a new entrant into the telecom investment analysis pool. The report centered on how software was revolutionizing telecom, which it certainly IS slowly doing.
The most eye-catching slide was a graphic – a rubric of incumbent software providers in the solution space and their new market challengers. It’s an eye-watering chart of some half-dozen well-known offenders and dozens of functionally specialized newbies. Some will see that graphic and drool over the money making opportunities and Private Equity (PE) and Venture Capital (VC) are all over the challengers in the space, engineers will hold their heads in their hands.
The key question that comes to mind is whether all that new software will change the status-quo in telcos where integration complexities across such functions have traditionally forced the adoption of multiple, often bespoke service-specific “stacks”.
Anyone with telecom experience can see in that “cluster” that the telcos are in a full losing position if they try to build their next-gen service solution stack a la carte. What a patchwork quilt of integration nightmare!
There were twelve “cells” of software functionality for the mobile operator stack in the example analysis. You need all cells (functions) filled to have a complete solution. The reality of that eye-chart is that if you choose one vendor from every cell you are completely fubar. Leaving alone the “agility” dream of being able to switch or change to new technology or service to fulfill that functionality.
So, do you go with existing sub-par big vendors that have historically lacked agility or more modern architectures built on startups offering their pieces as SaaS? In the architecture presented you’d have to do some integration work to be able to swap out any piece.
In practice, early efforts in mobile network infrastructure toward open RAN by “disruptive” providers may be instructive. They are moving in a few parallel tracks toward turn-key-like integrations of subsets of that daunting software swamp, creating an “Integration as Product” service solutions that they may hope to sell or license in turn to telecom operators. At the head of this line is arguably Rakuten and Fujitsu.
The turnkey integration approach is decades old – and how we ended up with the status-quo. What may be novel here is that these solutions are being sold by carriers to carriers instead of by big software vendors selling bespoke implementations to carriers. Given the strategic setting of this revolution, that telcos face a diminishing talent pool and commoditized product offerings, the hopes of these provider-integrator-resellers may not be misplaced.
The disruptor concept in the mobile space hinged on the idea of a service offering on commodity hardware, a longer-term flex toward a type of “agility” and “ecosystem” definition that accentuates innovation and variability in software. But, reality forced an early go to market (4G-LTE solution) with several traditional hardware vendors and what has been described as a “moat” of software products.
Like their cableco predecessors, who started with 31 vendors for their vCMTS/headend solution and then reduced it to four, going with a curated collection of PNFs (physical network functions) and VNFs (virtual network functions) for the new RAN helped whittle away at the integration problem from “the bottom” of the stack.
Similarly, by leveraging the learnings from early NFV misadventures, they wisely integrated around the single most popular commercial orchestration layer (VMWare) to decrease integration complexity at that branch of the architecture.
It’s the smallest path through the integration jungle you can hack before you step into that messy OSS/BSS pile of value-added fun. Minimizing integration pain is apparently still the game, no matter what part of the solution stack you are working in.
Honing down a bit as time progressed, disrupters like Rakuten then up-leveled their solutions by pursuing acquisitions of key parts of their original go-to-market stack, starting with the more obvious parts of the lower radio software chain (acquiring Altiostar) and pursuing co-development with NEC for the virtual packet core. These moves also echo cableco experiments like Comcast’s co-development with Harmonic of a vCMTS.
They acquired robin.io as a potential replacement for the commercial virtualization stack.
They chose to initially integrate across the upper part of the stack (particularly the BSS) with a big vendor like NEC/Netcracker, answering the question of whether to attack the “next gen service solution” in pieces or big chunks – chunks cause less pain. But, they have begun chipping away at pieces there too – acquiring an OSS company (Innoeye). And, the Rakuten Communications Platform (RCP) that is the basis of their offering to partner telcos has the BSS component grayed out, which could be a nod toward future development of their own BSS or the serious problems of integrating with the myriad (often bespoke) provider BSS implementations currently deployed.
The developing state-of-the-art seems to be a half-step forward: codifying the learnings that more control over the moving parts equals tighter and easier integration and (more interestingly) hinting at a longer-term strategy of total ownership.
Resistance to that approach may mean you have to fund a super-expensive integration and test center to guarantee that your bespoke collection of vendor products and software stack participants WILL work if you’re willing to pay to integrate them.
What might that mean for both sides of the industry – investors, vendors and providers? Is the end-game that all those startups get bought by a few telcos or cloud providers and we get a few turn-key implementations of new services in telco-land to choose between?
OSS/BSS integration is the third rail of telco. It’s where true business agility (or lack of it) resides. Every attempt at re-invention tiptoes around it. “Open” (kind of) now is really only at those lower layers where the bits flow. The interface to everything above may be ultimately defined over the decades by some standards org in a neat block on a nifty framework or another dump truck of quarter-baked software may be backed up into open source, but for all practical purposes integration there will be very tight (no matter what the spec says about the interface).
Open Source foundations and efforts have been plagued by the dump truck gift and taken years of effort (and of course many fine lunches and conferences) to get to the point where no one is using any of it. The point in time chosen to integrate is the point you stop innovating. And you’ll be limited by what one of the vendors, partners, startup or coders can or will do … in one of the many shards of “BSS” or “OSS”.
It just doesn’t seem feasible or practical to continue forward with thousands of bespoke implementations of a service. Unless your company is entirely brilliant with infinite capacity, there are inescapable investments – traditional build-vs-buy decisions to be made. You may NEED to buy some part or all of the solution. To be as competitive as cloud providers is to own as much as possible and carefully pick your pivot point(s). Rakuten seems to point in that direction.
That isn’t bad news for the PE and VC that are so excited about the potential in that rubric. Acquisition is a successful exit, even if it’s by a telco. Thankfully PacketFabric reimagined all this and went cloud native, with a ground up rebuild for a modern world and thus, has the only real-time, on-demand full OAM, measured SLA with usage based BSS … build a network like it’s part of the cloud and operate it fully from the cloud.
Footnotes
1 Matching the agility cloud service providers (CSPs) display in infrastructure and service offerings.