New IP

Carriers Need to 'Take Back Development'

BURLINGAME, Calif. -- OPNFV Summit -- Do you think proprietary technology, backed by a known vendor, is the safe choice? Do you think open source is riskier?

Think again.

The average lifespan of a corporation today is 15 years, compared with 60 years in 1960, said Margaret Chiosi, distinguished network architect, AT&T Inc. (NYSE: T) Labs, speaking at a panel here on Wednesday.

So the vendor that you trust to support your essential networking technology might not be around in a few years. You might be better off adopting open source, and getting involved in the development community, to share ownership of the technology you rely on and achieve agility required by the New IP economy.

"We have to take back the development," Chiosi said.

Take It Back
Margaret Chiosi, distinguished network architect, AT&T Labs
Margaret Chiosi, distinguished network architect, AT&T Labs

That will be a case of history repeating itself for telcos, which in decades past had large R&D labs -- including AT&T Bell Labs -- to develop new technologies, Chiosi notes. Carriers used iterative development and DevOps methodologies, even if they weren't known by that name.

More recently, AT&T outsourced development, but the company is now bringing development in-house. "Because of the original Bell Systems days, we actually have a good strong base," Chiosi said. Another fortunate development for AT&T is that, after recent acquisitions, the carrier has developers on-staff who worked on the original SDN controllers and other fundamental technologies.

Innovation often requires external recruitment, but when doing so it's important to recruit new ideas, not just people, said Hal Stern, executive director for applied technology at pharmaceuticals giant Merck. "If you bring in people who think about things the same way as you, you get the same solutions to problems," he said.

Recruiting people to work on infrastructure projects can be challenging, because those are often perceived as boring. "How do you celebrate it," Stern said. "How do you make it cool to do? The blinking lights are far more interesting."

SDN specialist Lucera contributes to many open source projects, but keeps the company name out of it, CEO Jacob Loveless said. The company looks to recruit from the open source community.

Having the right mission attracts talent, Loveless said. "It's always been the mission for me. If you have the right mission, and lack of nonsense for people executing on that mission, the right engineers will come find you," he said.

Related posts:

— Mitch Wagner, Circle me on Google+ Follow me on TwitterVisit my LinkedIn profileFollow me on Facebook, West Coast Bureau Chief, Light Reading. Got a tip about SDN or NFV? Send it to [email protected]

COMMENTS Add Comment
kq4ym 11/25/2015 | 5:44:05 PM
Re: Odd premise But then if the big guys are making some changes as in "AT&T outsourced development, but the company is now bringing development in-house" one might wonder if that a way to be copied by others. Even though the lifespan of companies seems to be trending down, even 15 year of life can be very useful, assuming one doesn't sign on in the last few years before death.
Mitch Wagner 11/19/2015 | 5:16:32 PM
Re: Under Estimated Costs of SW Development But can carriers afford to simply hand over their innovation future to other companies?
SeniorSo18507 11/18/2015 | 9:32:17 AM
Under Estimated Costs of SW Development I have seen Service Providers trying to do own SW development in house and at the point they realize the there are other aspects of Development that requires;
  • Life Cycle Management,
  • Support,
  • Able to convince the talent to stay
  • ...

they give up and ask vendors' to swap out their own "child" with theirs. This has happened many times and it will be happening again and again, Open Source will not address any of these issues. Imho; Service Providers will not leave the luxury of SLAs in Support Contracts.



mendyk 11/17/2015 | 8:38:53 AM
Re: Odd premise There's only one 100% guaranteed outcome for everyone. The rest comes down to probables, possibles, and improbables. BellLabs was created and thrived in another, very different era. Given current and foreseeable CSP economics, the prospects for significant in-house technology development look improbable. That's one of the reasons for the attraction of open source.
brooks7 11/16/2015 | 9:18:13 PM
Re: Odd premise You might think that part of vendor challenges is the procurement methods of the carriers.  If you treat high end systems like low value commodities, you can't expect them to invest the way they have.


Mitch Wagner 11/16/2015 | 8:46:19 PM
Re: And how about real disruptive innovation ? Service providers don't want to close out relationships with vendors. They should get useful technology from wherever it is available. 
Mitch Wagner 11/16/2015 | 8:44:46 PM
Re: Odd premise Sure, but the common belief that vendor solutions are safer assumes that the vendors will continue to be around to provide support. 
mendyk 11/16/2015 | 11:38:50 AM
Odd premise Using the shrinking corporation lifespan as a lead-in to the discussion about DIY R&D is dramatic and grabs attention, but it's a bit disingenuous. We use suppliers of all types for some good reasons, one of which is that it's economically much more efficient.
brooks7 11/16/2015 | 11:16:51 AM
Re: And how about real disruptive innovation ? Disruptive is the word that is a challenge.


Tell me.  In your process, where is training 100,000 people to deploy the technology?


Yossi W 11/14/2015 | 3:30:28 PM
And how about real disruptive innovation ? It's clear that those service providers that can afford to build the critical mass required for an effective R&D team should do it. 

However, the missing part here is how to take advantage of real disruptive technologies that naturally come from smaller companies or start-ups. If they want to enjoy the benefts of disruptive and innovative technology from such companies, service providers need to develop short agile processes to test and evaluate such technologies. 

Imagine a service provider cycle for technology screening that's structured like this:

* 3 weeks to bring technology in front of relevant users in the operator

* 2 weeks to define a successful trial action items upon success

* 1 week max for legal (prallel to former)

* Limit trial to 3 weeks

* 2 weeks to start executing on action items 

Sign In