Business Transformation

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.


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

Page 1 / 2   >   >>
Kruz 5/26/2015 | 2:03:15 PM
Re: GTO...3D @jbailo: I totally agree with your description on SDN and NFV.

But more importantly, and while you are on it, please print an additional GTO for me, I could use one :)
jabailo 5/26/2015 | 11:51:10 AM
GTO...3D My dream car is the '68 Pontiac GTO.

But I expect that soon I will be able to 3D print the exact year and model I want, regardless of the current remaining stock of originals.

In some sense, with the world of SDN and NFV, Network Architects are in the same position.

Less sanding and machining, more sitting down and conceptualizing.


janerygaard 5/20/2015 | 2:33:56 PM
We all need to change ... Building the network of the future will take something else than one of the past - so I think it is clear we as an industry need to change, independent of sitting in telco or IT today. As everything merges and we can utilize cloud technology starting with NFV and SDN, business models as well as the need for integration and interoperability will change for us all.

Can we live with less than 5 9s? I believe that depends on what the network is being used for, e.g. public safety services could be a problem. Can we accept other services to have more downtime, most likely. But can we afford to build more than one network, depending on the services it should serve? 

I will leave out comments on integration and testing of network and services, in a world where standards are not given.

However a bigger challenge will be the mindset change, not only for how to plan, buy and launch networks and services, but also run them. So I am missing the 6. point about keeping the services alive in this landscape.

But no matter what - it all comes down to the customer/users/subscribers (or whatever we call them) experience of the services we consume. Because that is what the CSPs needs to provide - and therefore giving the criterias for what a supplier needs to supply. (and that will change again in a programmable world)

mendyk 5/19/2015 | 3:27:10 PM
Re: Why IT matters It's true that mobile service has conditioned users to expect and tolerate less than five 9s reliability. But there are lots of essential operations that absolutely require something like five 9s, which equates to downtime of about 5 minutes a year.
melao2 5/19/2015 | 2:42:29 PM
Re: Why IT matters We do not need 5 9s. We need a service with best effort SLA paid by advertisement, i.e., free for the end user. :)


Oh how i love the internet! 
brooks7 5/19/2015 | 12:59:49 PM
Re: Why IT matters Mitch,

The whole thing about 5 9s is the amount of downtime on an annual basis and the fines associated with them.  The quality problems on the IT side of the shop tend to be different.  Downtime is not really an issue.  Failures are.  How many times have you had a SaaS product "break" on a new release and not be up for hours to days?

I think the last time we talked about such a thing on the SP side was a Juniper software release or was it some Optical Gear where there were a number of line card failures?


Mitch Wagner 5/19/2015 | 11:39:45 AM
Re: Why IT matters Kevin Mitchell - For service providers, it's a question of which apps require those five 9s of reliability -- voice, as you say, is certainly one -- and which apps can be more forgiving in the name of innovation. 
Kevin Mitchell 5/19/2015 | 10:43:41 AM
Re: Why IT matters I get this sentiment with the fail fast mindset, but when it comes to voice, I'm not sure it's going to fly.

Reliability and quality are the two prime ways service providers win. I don't think they can sacrifice that in the NFV era.

Voice Apps, Video Not Wooing the Enterprise

Rather, reliability is still the top requirement. John Guillaume, vice president of product management and strategy at Comcast, said that customers are buying service from Comcast because of the value and ease of ownership through a self-managed web portal, not because of the bells and whistles.

Mitch Wagner 5/18/2015 | 7:03:20 PM
Why IT matters

One reason for carriers to look to enterprise IT expertise is that these carriers are looking to provide managed enterprise IT services. 

Reduced uptime was as theme at a couple of the conferences I attended recently.  One speaker said five 9s is the enemy of innovation, because no new service ever achieves five 9s in its first iteration. 

I'm just going to stare at that car for a while now. 

Kevin Mitchell 5/18/2015 | 4:54:53 PM
Danger of Decomposition Ah, decomposing your network. Sounds so appealing. It could mean getting to the simplest form or it could mean rotting, as in dead and not working.

IMS brought us The Great Decomposition of Voice. That's been a fun journey hasn't it? While standards bodies and vendors have been decomposing the technology, so too has the business case rotted for building these networks.

For the past several years Infonetics Research IMS surveys note that MONEY as the chief barrier to IMS (hint: CAPEX + fixed OPEX is not a good model for a flat-to-declining voice market).

Decomposition also brings about operational complexity. A basic IMS call could comprise 136 messages across 17 functional elements and involve six different protocols. NFV adds even more functions and more interactions. There are more moving parts and more chances that components can get out of synch. Upgrades and troubleshooting may be a nightmare.

There's service agility in there somewhere. Maybe some rotting parts too.

System integration to solve this is one approach. It at least solves the initial build, but not necessarily the ongoing complexity. Cloud sourcing technology and specific applications is an alternative approach that solves that complexity day one and going forward.
Page 1 / 2   >   >>
Sign In