Inside Cisco Systems Inc., they like to consider Pankaj Patel their secret weapon. He's trotted out to the press every now and again, but he tends to avoid the big stages of conferences such as Cisco Live.

But as executive vice president and chief development officer, Patel has a lot of say in Cisco's engineering direction. A few minutes with him can teach you a lot about where the company is heading.

Figure 1: Are We Sitting Comfortably? Cisco executive vice president and chief development officer Pankaj Patel

We met with him recently to talk about the silo mentality to which large companies are prone and, of course, to discuss the topic of the moment, software-defined networking (SDN).

It's important to note that we spoke before the Cisco spin-in, Insieme Networks Inc., announced itself at Cisco Live! in June, so there's no mention of that. (See Cisco's Insieme Doesn't Like Your SDN Model and Cisco Drops Hints About Insieme & SDN.)

But Cisco had already spent nearly a year preaching the Cisco Open Network Environment -- Cisco ONE, although it would have been fun to name it CONE).

The ONE concept suggests that API-based, whole network programmability is more important than the type of SDN preached by startups and their acquirers. (See Cisco Takes ONE Step Beyond SDN.)

— Craig Matsumoto, former Managing Editor, Light Reading

On page 2: Patel on the impact of SDN.

Light Reading: How close do you think SDN is to making an impact?

Patel: People are not saying, "Give me a separate data plane and control plane," and this is not a lovefest. This is where I think it differs from how academia will play out, versus where the major market is headed. When you talk to the major enterprises, for the large production adoption, you're talking about three to seven years away.

What they're asking for and what they care about are different. They're really looking for a lot of simplification. A lot of simplification, and programmability, and I believe that for us, Cisco ONE is a much broader environment than just SDN. This is the power of our virtualization story, [with] the Nexus 1000v -- we have over 600 customers on the 1000v -- and our big foray with the onePK... and the controllers. (See Cisco Extends Its SDN & Cloud Plans.)

What customers are really looking for is the consistency between the physical and the virtual world. So, when it comes to datacenter and cloud, they want a seamless interface. We recognize the existence of multiple hypervisors and the multiple orchestration layers, and we create value in relationship to the existence of this -- whether it's a VMware, a Red Hat, a Citrix, a Microsoft; we work with all of them, but we create our own unique value as we work with them.

To the people who say this thing will commoditize the traditional suppliers, to them I would push back and say: Really? Ethernet got commoditized, and that hasn't commoditized us. We have always created a lot of value in software on top of that. For a long time, IPv4 was commoditized too.

Light Reading: That's a good point, but my understanding of Ethernet and IP is that even though they're "commoditized," you are always better off sticking with one vendor's products, because products are just different enough and managed differently enough that putting five vendors in your network is just going to be impossible. So you, Cisco, have got that going for you on the Ethernet side. There seems to be a push with SDN or whatever comes next in the network to make things more open, so you can just pick and choose.

Patel: Absolutely. As part of that we are big contributors to open source as well as OpenStack.

When we acquired Starent -- I did that personally -- they use Linux for everything. They have their own OS, but they use Linux, which means they put a lot of code they develop out in the public domain, because they have to put it back. So when I talk to Ash Dahod, who was a founder and CEO at that time, he said, "You know what? I challenge my competitors, Ericsson and Huawei and so on, to go take the code I have put in the public domain and create their own." It wasn't out of arrogance -- it was out of the confidence that he had created enough value by tying silicon and hardware and software together in a unique way that would stand for years to come.

Light Reading: The sense I get is that a lot of people are hoping SDN will drain some of the value from Cisco, or spread the value around industry. How do you keep that from happening? Granted, there'll always be a very high end that needs some sort of ASIC...

Patel: Right. But the two chips Rob Lloyd showed [in a presentation before this interview], they're for the low end and medium end.

Light Reading: Well -- they're for a highly capable router for the low end of the market.

Patel: Right, but the low end of the market. One is for the 3850, which is your medium-end switch. Think of this sitting between the Cat 3K and Cat 4K [the Catalyst 3000 and 4000 product lines].

Light Reading: It's medium-end in terms of size, but not in terms of what it can do. Not in terms of brains.

Patel: What I'm saying is, our competitors using off-the-shelf products have to really rely on off-the-shelf suppliers that will create products because of the cost points for the features they can write. Whereas we will be able to create features for many years to come. In the ASICs, we have created that much flexibility in the headroom.

On page 3: Patel on the impact of NFV and tech sharing.

Light Reading: Now the NFV question. When you oversimplify it, it's the hope that everything runs on x86s someday. It does sound like carriers are interested -- what does this mean to Cisco?

Patel: I think it's more around a lot of applications. Take a mobile operator. On the back end, the billing and provisioning of services or whatnot, you might find somewhere around 15 to 30 applications, each application running on a different server. I see an area where all of this can really run on something like UCS [Unified Computing System].

At the same time, what we are talking about from the point of view of networking and what it has to do -- I don't see that going away. There'll be times when you may be able to extract part of the software from a traditional networking product and run that on a server, but when that happens, the value would move from hardware to software. I'm not worried about somehow leaving money on the table if that happens. It means that how we charge and how we monetize become different. NDS [the video management company acquired by Cisco] is a great example. They don't care as to what the set-top box customer would buy.

Light Reading: Would it still be a transition for Cisco, though? The business is built around the concept of hardware.

Patel: There'll be a transition. We are entertaining a couple of examples where the customer would like to run some application on a UCS server -- that's like a long transition, for a variety of reasons... the world of virtual sounds so simple until it breaks.

Light Reading: I've heard that the best of businesses cannibalize themselves before somebody else comes up from under them. Is any of what we're talking about going to fit that pattern?

Patel: "Cannibalization" is a pretty strong word for me, but at the same time, when we develop the new products -- the switches routers or otherwise -- they typically impact what we're doing today. Not just in terms of the next generation. Like, for example, the 3850 -- that is a pretty strong offering for the wired, wireless and security. We may be using multiple products to achieve the same thing today.

There are many examples. We acquired NDS fully well knowing we have a large business in set-top boxes. We acquired a software business, and you might say, "Gee, doesn't that commoditize what you have on the set-top side?" Yes and no, because the thing is, people have been talking about the set-top boxes going away. They're not going.

Light Reading: You've made some changes in the way Cisco shares technologies internally -- what was that about?

Patel: I launched a major initiative late August last year, where I created a horizontal technology model.

Today we have a service provider networking group, an enterprise networking group, a security group, a data center group and a "collab" group [collaboration -- things like WebEx]. And we had central groups, things like operating systems. One of the things I pushed for very hard, and my team agreed to do this, is to tie all of this together.

So we created these strong horizontal threads, like security and mobility, and at each intersection point, where the vertical business meets the horizontal thread, I'm holding the CTO responsible to drive all of that into their respective groups. So when we come out with the architecture, it's truly a mobility architecture -- or it's about a datacenter architecture that can truly span across the portfolio. It's not about UCS and 7K [Nexus 7000], for example.

Light Reading: So is there someone responsible for each horizontal thread?

Patel: Yeah, out of my business leaders. So for security, Chris Young has responsibility for driving the security business [a vertical thread], but I also want him to drive the security horizontal thread across all the businesses. Same thing with Kelly Ahuja: Kelly is responsible for the mobility business on SP [the service-provider business]; he's also responsible for driving mobility across our entire portfolio. I also help Kelly and Chris, both responsible jointly, for driving policy across our entire portfolio.

And actually I'm holding my leaders accountable for success across each of these.

Light Reading: How was it done before?

Patel: Pretty much in silos.

What would happen is: A group has a need. They just go and pick what they want to. The next group comes along, and they go, "Well, I see what they have, but it doesn't quite address my needs; I can go off and do my own." This [new strategy] will help us bring some discipline in the way we operate and use the opex wisely. People always want to spend money on toys.

Light Reading: Had you come under pressure for opex?

Patel: Not the pressure -- more than reuse, my motivation is for consistency, so when I deliver an architecture, the customer doesn't have to think about: How will your devices self-discover? Or when you're running a security policy on one box, I don't have to go and do something different on the other Cisco box -- it's absolutely consistent.