The Autonomous Network Is the Endgame for Telecom
Who you gonna call?
So the big question for service providers is: Who can they trust to design and help build their autonomous network? Options range from traditional to mold-breaking.
At the "trad" end of the scale they can go with one of the incumbent vendors (Huawei Technologies Co. Ltd. , Nokia Corp. (NYSE: NOK), Ericsson AB (Nasdaq: ERIC), etc.), which in turn are competing head-on with the incumbent OSS vendors ( Amdocs Ltd. (NYSE: DOX), Oracle Corp. (Nasdaq: ORCL), Netcracker Technology Corp. -- all of which have their own NFV and multi-domain orchestration platforms) and the heavy-duty IT vendors ( Hewlett Packard Enterprise , IBM Corp. (NYSE: IBM), Dell Technologies (Nasdaq: DELL)).
"Each type of company brings its own strengths to the party, and some of them play in more than one camp, notably Ericsson, which is strong in network operating software, as a network equipment provider and as an integrator," comments James Crawshaw, analyst at Heavy Reading, who recently published a report on this market called Intent-Based Networking, Automating Next-Generation Networks.
On the more disruptive end of the scale, carriers can opt to use code from one of the new carrier-driven industry organizations, such as ONAP or OSM; do it themselves using an automation programming framework and a lot of hard work; or go with one of the new and disruptive "God code" middleware solutions now entering the fray (more on these later).
Whichever path they take, for service providers this is a decision fraught with much more anxiety today than it was four or five years ago when they were considering suppliers for NFV.
Back then, service providers were optimistic that deploying software-based virtualization (SDN and NFV) would buy them two benefits: cost savings, plus a way to escape from being locked into one vendor's end-to-end communications portfolio. At the same time, those same service providers were also predisposed to continue to work with the incumbent vendors they knew and trusted.
For the incumbent vendors, this situation presented a serious quandary. How could they continue to lock in their biggest customers while also showing that they were fully committed to the bold new, open and interoperable world of software-based virtualization? Their answer, basically, was to slap some open source lipstick on a proprietary pig, by continuing to sell their own technology while also joining a slew of open source virtualization organizations. This effectively sent their service provider customers (and analysts and the media, who all fell for this line) the strong impression -- not guarantee, mind -- that their products would seamlessly interwork with products from other open source supporters.
Today, of course, we know that "support" for open source code doesn't mean that a vendor's products will interoperate with anyone else's, at all. Mostly they won't, without a lot of hard systems integration and/or lab work. Now add in the fact that the incumbents' early NFV products were mostly hard to implement (buggy, overly complicated, expensive to get running) and the result, four years on, is a lot of very big incumbent equipment companies with a lot of very frustrated carrier customers.
Next page: Making sense of the vendor marketectures