x

Choosing a Technology Supplier? Consider Changing Your Selection Criteria

This is my car. I bought it three weeks after I moved to America, way back in 1992 and I've spent the last 23 years restoring it, little by little.

I finally finished its makeover this year and it looks great, it's reliable and it's fast. It's fair to say that I'm rather proud of my '72 Chevy.

Retro is a great look for a car. For carrier networks? Not so much.
Retro is a great look for a car. For carrier networks? Not so much.

In fact, I probably feel the same way about my ride as many network architects feel about their carrier networks. After all, most of them have invested a couple of decades hard work on building networks that can deliver the kind of high speed (as in throughput) and reliability (five 9s) that end-users demand.

But there's a snag: While network architects were busy retooling their networks for 21st century service, the mission changed on them.

Now their employers (specifically, the business side of their employers) are telling them that raw capacity and network uptime aren't enough -- that networks today must also act as a launch pad for new, highly profitable, content-driven applications.

These networks must be open, virtualized and secure, they're being told. And they must provide an agile platform from which innovation can flow. In muscle car terms it's a bit like someone telling me "sure, it looks nice, but can you make it fly? And, hey, how about a spot of time travel?"

So it's a "big ask," as they say in soccer circles. In fact, for most network architects it represents the biggest challenge of their careers. Because this isn't just about upgrading technology (something most of them have had to tackle a few times, not least during the shift from circuit- to packet switching). No, their latest network journey also requires them to reinvent themselves as technology business strategists -- with the emphasis on business -- and it also requires them to overcome huge cultural impediments within their own organizations.

Choose carefully
Network architects need help, obviously, and, for many, their knee-jerk reaction will be to automatically turn to the same equipment manufacturer that helped them successfully build their current network.

But in this case, sticking with who you know might not always be the best option: To paraphrase Marshall Goldsmith, "the equipment manufacturer that got you here may not get you there."

The massive changes now taking place in the communications industry -- from old IP to New IP -- are forcing those suppliers to undergo their own period of self-invention, just like their customers. And some of them are better equipped (culturally, organizationally, financially, as well as technologically) to undertake that metamorphosis than others.

And some, including some of today's biggest names, won't survive the transition. At all.

Oops.

Choosing the best partner for the job of building a 21st century-proof comms network means service providers need to first force themselves outside of their comfort zone and at least consider alternative suppliers. And there's evidence that's happening. (See AT&T's Cloud Future Takes Shape, Swisscom Embraces OpenStack With PlumGrid and Telekom Austria Builds Multi-Vendor NFV 4G Core .)

Equally importantly, service providers also need to expand the criteria to use when evaluating potential partners.

New networks, new rules
So what are the boxes that service providers should be looking to check? That's a question I've been asking all year in interviews with C-level and senior VP leaders at equipment manufacturers and service providers.

Here are five of the answers I've been getting:

1. Open standards virtualization
Just about every company in the industry now claims to support NFV, but there are huge differences in the extent of that support, so it's important to dig in on exactly what is being supported, and how.

One of the most eloquent, and elegant, explanations of the different degrees to which it's possible to implement NFV virtualization that I've heard this year comes from Saar Gillai, SVP & GM for NFV at HP Inc. (NYSE: HPQ) (HP). (He is also a keynoter at this year's Big Telecom Event (BTE) in Chicago -- if you get a chance, I can't recommend checking out his presentation at the show strongly enough).

Gillai describes NFV evolving in four phases, or steps, each of which deliver incremental benefits, from reduced opex, all the way up to facilitating an agile services environment that encourages speedy development of new and innovative applications and services.

In phase 1, network functions are decoupled from hardware; in phase 2 network infrastructure resources are virtualized; in phase 3 the network is cloud enabled, or "cloudified," to use HP's terminology. (See The 4 Stages of NFV .)

It's phase 4, however, that is the most advanced iteration of NFV and produces the greatest benefits to service providers. In this phase, "monolithic" network functions are broken down -- or "decomposed," to use Gillai's terminology -- and re-written to perform natively in the NFV environment.

"Until you decompose the functions and rebuild them in a 'cloud first' method you're not going to get the full benefits of the agility that NFV promises," Gillai says.

2. Support for systems integration
Simply put, the latest developments in communications have the potential to cause huge disruption to the current hegemony of the incumbent equipment manufacturers.

For the last 30 or 40 years, best practice for service providers was to work predominantly with a single infrastructure manufacturer for each network being built (and each operator built a lot of different networks). Those vendors would design and install their products end-to-end, along with a bunch of proprietary bells and whistles that were guaranteed to lock the customer into the equipment manufacturer's solution.

Between now and the end of the decade, the arrival of open, virtual, white box (or New IP) networks promises to blow the bloody doors off this model, allowing service providers to mix and match hardware from different manufacturers and source and download network operating software and network functions over the Internet from the network operator equivalent of apps stores.

The problem is that once service providers dispense with the incumbents' end-to-end portfolios, they risk losing all of the critical high-touch hand-holding, service and support and proprietary business advice that came bundled with them.

Systems integrators, such as Accenture and IBM Corp. (NYSE: IBM), will likely do a roaring trade stepping in to fill this vacuum. (See NFV's Looming Battle: Systems Integration.)

But another option for service providers is to work with incumbent manufacturers that also have systems integration divisions and have thus clearly demonstrated proficiency in supporting multi-vendor networking environments and the apps that run over them. A prime example is Ericsson AB (Nasdaq: ERIC), which employs more than 65,000 people around the globe in this function, as well as Dell Technologies (Nasdaq: DELL), HP, Fujitsu Ltd. (Tokyo: 6702; London: FUJ; OTC: FJTSY), NEC Corp. (Tokyo: 6701) and Nokia Networks . (See My Ericsson Epiphany .)

3. Enterprise IT experience
It may seem odd to stipulate that experience of enterprise IT networking is an important prerequisite when looking for a company to help build a telco network, especially given that many Tier 1 operators have been in the habit of looking down on their enterprise counterparts over the years, but there are a couple of reasons why it makes sense.

First, service providers looking to build telco cloud services can learn a lot from certain suppliers -- including Brocade Communications Systems Inc. (Nasdaq: BRCD), Juniper Networks Inc. (NYSE: JNPR) and VMware Inc. (NYSE: VMW) -- that have already helped large private companies build enterprise cloud networks. Sure, the overlap isn't 1-to-1, but there's a huge overlap in the Venn diagram between the two cloud competencies.

And it's the enterprise world which has already perfected DevOps -- the practice of getting developers to work hand-in-hand with IT departments to more efficiently produce applications and then seamlessly run them over the network: That's a set of collaborative skills that service providers desperately need to learn.

Rod Naphan, CTO at Fujitsu Network Communications Inc. , refers to this trend as the IT-ification of telecom. (See CEO Chat With Rod Naphan, Fujitsu Network Communications.)

"The movement of technology towards software and network function virtualization and SDN really means that the way that network services will be built in the future look a lot more like the way that cloud services are built today," he says.

4. Less uptime (really!)
For as long as most people can remember, five 9s has been the standard for reliability on telco networks, but equipment manufacturers that are still pushing this level of uptime as the key metric may actually be doing their customers a disservice.

There's a devil's advocate school of thought in the industry right now that argues the level of uptime, and the SLAs (service level agreements) in which it is enshrined, are artefacts of the old way of building telecom networks and hinder service innovation by preventing service providers from quickly rolling out new services.

Changing that priority set requires not only switching technologies, it also means changing the way that service providers compensate network architects and their teams -- rewarding them based on rolling out apps first, rather than on eliminating network drops.

This may sound like heresy to many working within existing Tier 1 service providers, but those who resist this change are likely to be challenged to compete with new competitors, especially web-scale companies, that don't follow the five 9s mantra.

5. Less installed base (for real!)
Here's another conundrum for network architects to consider: Is it possible that the company best qualified to help them build their virtual network may not be the one with the most experience in building telco networks?

That's not actually as loopy as it sounds. To one extent or another, existing comms manufacturers face the "innovator's dilemma," which posits that the successful vendors of today are at risk of failure because they are too focused on their customers' current needs, and their existing lines of revenue, and thus fail to embrace disruptive new technology.

In other words, when it comes to designing and delivering next-generation network solutions, there are advantages for vendors that don't own the installed base, and service providers might at least consider asking themselves which suppliers aren't cannibalizing their existing revenue stream by building them a New IP network and are therefore truly motivated to do the job without reservations.

Buyer beware
It's clear, then, that just as the potential pay-off for service providers from segueing to a next-generation network architecture can be huge, so are the challenges. To be successful they must embrace their inner IT: One way to do that is by combining their CIO and CTO roles, something that Light Reading has been advocating for years. (See Bridging the Chasm[s]: Easier Said Than Done.)

And they must learn to live with failure -- network failure, that is, if the trade-off is agile, profitable service development.

But above all, they need to choose the right technology partners. There have never been more companies pitching for that business. With so much at stake, caveat emptor must be the order of the day.

    Note: There's plenty more to be said on this subject and Light Reading is currently engaged on a major research effort to: define new purchasing criteria; measure how today's equipment manufacturers measure up to the same; and survey service providers about how their buying habits are changing. The results will be released at the Big Telecom Event (BTE) in June. If you or your company want to be involved in any part of this important work, please just drop me a line at [email protected]

— Stephen Saunders, Founder and CEO, Light Reading

Be the first to post a comment regarding this story.
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE