Industry Bodies/Groups

Tribalism Is Rife in Telecom, Too

THE HAGUE -- SDN NFV World Congress -- Just as Catalonia considers breaking away from Spain, and the bedraggled British bulldog limps toward its EU Brexit, so the telecom industry is splintering into factions.

As if one open source initiative weren't MANO enough, the industry has gained two in the Open Network Automation Platform (ONAP) and ETSI's OSM. They are driving a wedge between operators. In a related move, even if not strictly analogous, a "zero-touch" group could now enter the automation fray, although it insists it will not play much of a technical standardization role. The MEF has also this week chipped in with a new sub-group -- through a partnership with ONAP -- that will define the specifications for inter-carrier connectivity. (See Automation Gets Its Own ETSI Group and ONAP & MEF Formally Team on LSO APIs, Framework.)

Meanwhile, on the the edge computing side, CORD, Open Edge Computing, the OpenFog Consortium and the edge-computing group within the European Telecommunications Standards Institute (ETSI) are all jockeying for position. And let's not forget about the Telecom Infra Project, itself an assortment of sometimes competing interests and working groups that encompass just about everything. (See Facebook's TIP to Launch AI Working Group.)

Telecom is undoubtedly a complex, hydra-headed beast. It's better that rival companies team up on important issues than stubbornly refuse to cooperate whatsoever. If that happened, and without the progress some of the aforementioned groups have already made, the industry would be going nowhere.

Two tribes – but telecom has lots more.
Two tribes – but telecom has lots more.

The problem is when groups that overlap, or have exactly the same aims, generate further complexity. That could defeat the whole purpose of buddying up in the first place. And here's the paradox: The telecom industry is losing people, and it will lose a lot more if automation takes off (that is something the industry needs to face up to, instead of kidding itself that staff will be "reassigned" when machines take their jobs). (See The Revolution Will Be Automated and The Automation Taboo: Let's Talk About Jobs.)

So while the industry is shrinking, the number of groups it hosts is proliferating. It is like a dying house party, where some guests are forming tiny cliques around the edge of the dance floor as others walk out. Or an ageing continent carving itself up into new countries and blocs when the need for collaboration is more critical than ever.

Commenting on this paradox at this week's SDN NFV World Congress in The Hague, an executive from Sweden's Ericsson AB (Nasdaq: ERIC) pointed out that new initiatives keep appearing even though the faces at industry conferences stay the same.

For more NFV-related coverage and insights, check out our dedicated NFV content channel here on Light Reading.

The industry's immediate fight-fire-with-fire response is to form yet more groups to bring the existing groups together. One stated aim of the yet-to-be formed ETSI automation group is to converge the efforts of multiple industry bodies like ONAP and the Open Source MANO Community (OSM) in one giant push toward the promised land of automation. Klaus Martiny, a senior program manager with Deutsche Telekom AG (NYSE: DT) and vice chair of the Network Operations Council with the existing ETSI NFV Industry Specifications Group, believes that, potentially, it could eventually be merged with ONAP. But is yet another industry group really needed to boost automation efforts? Might its creation cause further confusion about who is doing what?

No doubt, on the MANO side of the equation, there is now an urgent need for cooperation between ONAP and OSM on the information models that underpin their software. Unless this happens, developers will struggle to write the code that allows one company's systems to be used alongside or in place of another's. As companies pursue their own distinct agendas, this interoperability nightmare could become a reality.

Indeed, according to one senior industry executive involved with standardization efforts, it is not easy to see how ONAP and OSM will harmonize their activities in the short term. Those behind the zero-touch initiative think it could bring the ONAP and OSM groups together on information models. But representatives from some of the world's biggest equipment vendors are already talking about swinging firmly behind the group that gains the most support in the operator community. The current feeling is that ONAP is winning the battle. Yet operators such as Spain's Telefónica have made a huge commitment to OSM, and are not about to abandon that development. (See Martiny Cocktail? DT Exec Eyes ONAP & Zero-Touch Merger.)

The situation is not so very different in other parts of the industry. The conflicting visions of the distributed cloud, for example, reflect their sponsors' vested interests, as IT companies and network equipment makers eye a share in the spoils. Co-ordination is already happening, insist the edge-computing groups. But not everyone sounds convinced. (See Edge Inertia Grips Telcos as Rival Interests Jockey for Position.)

To some extent, competition and conflict is a necessary part of any industry, fueling innovation and improvement in product design and processes. To sell more cars, Italian companies have to make better and lower-cost vehicles than their German rivals, of course. But when it comes to basic principles and the rules of the game, a unified approach is always paramount. Telecom executives are now desperate to eliminate complexity as they automate and "cloudify" their networks. The factionalism that grips the industry, though, could prolong that transformation. (See Complexity Could Derail Automation, Say Telcos.)

— Iain Morris, News Editor, Light Reading

Joe Stanganelli 10/24/2017 | 2:25:44 PM
Re: Tribalism & Competition @brooks7: A Verizon exec I recently spoke with echoed your sentiments. When it comes to building real cohesion around standards in a useful way, he argued, interface work is important -- but involvement in real-world implementation and the how of getting things done internally just gets in everybody's way.
Joe Stanganelli 10/24/2017 | 2:22:01 PM
Re: Tribalism & Competition Point well taken. But Europeans seem to love meetings and bureaucracy even more than we Yanks do. Expect plenty of commissions and committees and subcommittees and more.
Carol Wilson 10/16/2017 | 10:51:02 AM
Re: Tribalism & Competition I totally agree that interfaces and interconnection are the primary points at which agreement is needed but, to Iain's point, if you have multiple groups defining these and developing them, is there ever really concurrence on what they are?

A lot of the folks I interview say TMForum work is foundational, and MEF is building on that and trying to coordinate with ONAP as well. That looks like progress on that one front. 

But on the edge computing side, as Iain rightly notes, the efforts are still very scattered. 

To this point, the push to products has been accomplished by a network operator choosing a team of vendors - with one vendor providing the ecosystem backbone or orchestration - and moving forward on specific goals, or a massive network operator like AT&T developing its own massive software platform. 

The approach you suggest makes sense to me in its practicality - pick products and make something is moving forward, and in this alleged era of "fail fast," movement forward is better than being stymied by interminable discussion. 
brooks7 10/16/2017 | 10:09:30 AM
Re: Tribalism & Competition @Gabriel,

The industry sort of needs such an entity but only for specific things.  The ITU, IETF and the 802 committee are such entities.  Note that they focus on Interfaces and Interconnection of things not implementation.

I think this notion that products need to have consistent internal implementation is a completely flawed notion.  It is eliminate the ability to have a fast moving and creative industry and did not happen on the IT version of this process.  Take a look at the LAMP stack.  That is about as plug standard as things get, but there is no set of requirements for it.  Nobody has to use it.

To me a better approach is to pick products and make something.  To sit in a large room with a bunch of people will get nowhere fast.  No matter what you choose there will be problems with it.  You can then contribute code to overcome those challenges and get them in the baseline of the next version.  All of this will come from real world implementations, not from some set of people sitting in a room.




Gabriel Brown 10/15/2017 | 10:04:47 AM
Tribalism & Competition To some extent, competition and conflict is a necessary part of any industry, fueling innovation and improvement in product design and processes. 

You need competition. If it's all design-by-committee you know what you end up with. To extend your theme, is a "European Commission of telecom" really what the industry needs?
Joe Stanganelli 10/13/2017 | 10:26:07 AM
Inevitabilities of commercial standards This has all been inevitable.

Open source and open standards catch on -- for good reason.

"Big-Corp" entities become increasingly criticized and ostracized because of their proprietary, competing, non-standardized natures.

So these major companies and carriers start joining open-source and open-standards movements -- for multifold gains. PR value. Learning from other developers. And, of course, helping to contribute to open source and open standards.

And not just contributing. Leading. Shaping. The optimistic apologist says that it's a matter of QC. The cynic says that it's about gaining back some of that dependency. The realist says it's probably a bit of both.

And now these competing standards are even more heavily competing with each other -- to the point that major carriers and other big enterprises are withholding their support/membership from certain open-source/open-standards organizations in the face of heavy involvement of rivals in said organizations.

As things begin to decentralize more, I suspect this will eventually come full circle.
Sign In