When a company loses its ability to innovate, it imperils its ability to thrive. This is because today’s competitive landscape includes the rapid expansion of the super scalers like Google, AWS, Azure, and so on into traditional telco services. This pressure is further amplified by the appearance of cost-effective low-earth orbiting satellites (LEOs) and the push for 5G networks owned and operated by enterprises.

Telco A’s approach does minimize the need for reskilling and culture change. But it pays a very high price for this benefit.

The in-house development extreme

From this perspective, the decision of Telco B to build its own internal software development group based on open source may seem like a way to avoid the monopoly risks that Telco A faces. But Telco B faces another set of daunting challenges. Theoretically, internal development allows Telco B to be the master of its destiny. The company can determine its unique requirements and build exactly what best serves its unique needs. However, Telco B’s approach faces a number of challenges, including reskilling, innovation, technical risk, execution risk and cost control. 

Telcos may have built up software development expertise in their business IT departments. But networking software is fundamentally different from business IT software. Network operations staff understand the needs of the network but typically don’t have the required advanced software development skills. Regardless of which part of the telco takes the lead, a major reskilling effort to attract the right type of software talent is needed. This is going to be difficult and expensive. To recruit talent, the telco is competing with innovation-driven startups, super scalers, enterprises and other digital-first players. Relying on open source groups dedicated to telco software may seem to moderate some of the reskilling as well as technical and execution risks. But the telco open source efforts have proven to face serious limits. First, sophisticated observers have commented on the fact that the telco industry is a small fraction of the size of the general enterprise market. Yet, even the large general enterprise open source groups haven’t sought to develop the kind of complete operations solutions that the telco groups are focused on. In effect, the telco open source groups appear to be dominated by the few large vendors seeking to hold on to monopoly-like control, while attacking a problem with challenging scale, complexity, and volatility aspects. Consider that all this must be pursued with fewer resources than the enterprise-focused efforts that the telco open source efforts are modeled after. What is the result? It’s definitely not innovative or efficient software. 

In addition to the apparent limitations of the current open source groups, Telco B faces the normal technical and execution risks that any software development effort must face. The jury is still out on how much of the promise Telco B will be able to achieve.  But some observers have noted that Telco B has been working on this for approximately four years and has not yet put much into operation.

Finally, by focusing on a single technical approach, Telco B has lost the potential advantage of a portfolio approach. The telco faces challenges in marshaling sufficient quality resources to develop one approach. A portfolio of different approaches is beyond its reach. If leadership picks what turns out to be the best approach, all is good. If not…to be fair, Telco A’s approach faces similar portfolio risks.

Telco as intelligent consumer

A telco acting as an intelligent consumer recognizes that to maximize its success, it must develop an ecosystem of suppliers. This doesn’t mean that all telcos must have the same set of suppliers. Each needs to select candidate suppliers based on its own particular situation, influenced by geography, competitive objectives, legacy infrastructure, and so on. The term candidate suppliers is a careful choice. To be effective, the ecosystem must maintain competition at some level. One way to do this is to select suppliers based on overlapping characteristics. For example, a supplier may be chosen to deliver X while having the capability to deliver Y. Another supplier may be chosen to deliver Y while also being able to deliver X.