Juniper CEO Johnson talks software, the company’s recent challenges and key future directions

Kevin Johnson

Juniper Networks had a challenging 2012 as new product cycles were slow to take hold and global economic conditions took a toll on sales. The company also undertook a restructuring that saw 500 positions cut and the departure of four executive vice presidents. As the Sunnyvale, Calif.-based company looks to re-energize its business, particularly with an eye towards enterprises and data centers, CEO Kevin Johnson shared his lessons learned in leading Juniper since 2008, as well as what’s ahead for the company in a discussion with IDG Enterprise Chief Content Officer John Gallant and Network World Managing Editor Jim Duffy. In this installment of the IDG Enterprise CEO Interview Series, Johnson also shared his thoughts on the hot topic of software-defined networks (SDN), Juniper’s role in enabling cloud and competing against the industry’s 800-pound gorilla, Cisco.

Customers are moving toward highly virtualized data centers, cloud services, hybrid cloud. In this context, why is Juniper a better strategic partner than, say, HP, Cisco, Brocade or another networking company?

The two key market trends are cloud computing and mobile Internet. Cloud computing can’t be enabled unless you have a high-performance, reliable network that’s connecting the users of services and applications to that data center and the compute and the storage layers within the data center. The heritage of Juniper is focused on innovation with a specific focus on high-performance networking, so tackling the most complicated problems of scale and performance and reliability in the network. If you’re moving workloads from one data center to another or connecting thousands of storage and computing devices within a data center, our focus has been enabling solutions that solve the problems of scale and reliability.

Some of the key differentiators for Juniper are that we invest in R&D and we develop our own silicon that we use in many of our systems — not all of them, but in many; silicon that has been purpose-built for different domains of the network and different areas of the network problem. No. 2, we focus on the software operating system that runs in the network. We’ve been very focused on Junos as a common software platform that runs across the product portfolio, which is something that helps customers better manage, configure and operate those systems. That ultimately leads to lower cost of ownership since it’s a single operating system, yet still having the benefits of high performance through the silicon.

RELATED: 5 things Juniper must do to reignite growth

MORE: FABRIC WARS: Cisco vs. Brocade vs. Juniper

Juniper has done very well in the service provider business. As we move more toward this cloud world, how specifically would you capitalize on that strength in service provider to benefit enterprise customers?

The investment we make in R&D strategically across routing, switching, security, we look to take those products to market to both service providers and to enterprise customers. Now, why would an enterprise customer be able to leverage engineering work that handles networking problems with the scale of the Internet? Well, when you look at many large enterprises today, they actually start to look like a service provider. You look at the scope of their networks, you look at the complexity of their networks, you look at the requirements they have for performance and reliability, whether it’s in financial services, large federal government, defense agencies, you look at healthcare institutions. Look at many of the large industry verticals in the enterprise and the requirements they have in terms of performance, reliability and scale start to mirror what we’ve seen from service providers over our 16-year history.

Kevin, you joined in 2008. Obviously, one of the key things for Juniper during this time period has been penetrating the enterprise. How would you characterize your success in the enterprise to date? And what kinds of things are you going to do in order to continue to improve your position in enterprise?

Certainly in that journey I think there are areas that we feel like we’ve made some good progress. There are a lot of lessons learned and there are a number of things that we feel that we can do a better job on. Today our revenue is roughly 38% to 40% from enterprise and 60% to 62% from service providers. We’ve grown both in service provider and enterprise over that four-year period, but the growth in enterprise has been faster than the growth of service provider, as we have gained market share in the enterprise. I think that in 2012, year-to-date through Q3 our switching and fabric business has grown 20%, much of that a function of data centers that we’re enabling, campus and branches we’re enabling in the enterprise. We’ve taken our routing portfolio and we’ve expanded it to provide routers that are more aligned with the needs of enterprise customers. The security business is one that was anchored in the enterprise and we’ve expanded that to cover both enterprise and service provider.

So let’s look at two of those aspects that you brought up: lessons learned in the four years in the enterprise market, and then things that you see as key strategic elements going forward…

I think a few of the lessons learned, one of the things that we’ve observed is that enterprise customers think about their networks more and more in specific domains. And that’s important because the architecture of those networks in domains is different and it allows enterprise customers to think about bringing in another vendor or a dual vendor strategy into their networks.

So when you say domains, do you mean different layers of the network?

Different areas of the network. And there are three basic areas that it breaks down to: the wide area network, data centers, and campus and branch. So as we engage with enterprise customers, oftentimes as they learn about us and think about where they could apply us, the first problem they go through and solve is which domain they think it’s most appropriate to introduce Juniper, begin to utilize Juniper technology. Historically, we’ve had a footprint in the area of security, and security plays a role in all three of those domains. We’ve invested in R&D to build out our switching and our fabric portfolios. We’ve seen good growth in that. We’ve continued to take share. We’re still a small share player though, when you look at the switching addressable market. It’s a $20 billion addressable market and we’ve grown to be about a $600 million plus business in switching and fabric — our QFabric product and our EX product line.

We’ve had some lessons learned there as well. I think we, over the last year, have had a number of features that customers have asked us for, things in the area of high availability, how they connect a single server to multiple fabric nodes, and so we’ve worked to enable many of those features. There are still some more software features that customers ask for. But one of the important lessons learned in QFabric was where we thought customers would want a single implementation of fabric in a data center, in fact they prefer to have multiple fabrics at a data center, and that was because they didn’t want to have a single failure domain or fault domain. They wanted to be able to have the opportunity to take a data center, break it into some smaller fabric chunks, and enable the architecture that way. So last quarter we introduced a new version of our QFabric interconnect that basically is a scaled down version that enables them to implement multiple smaller fabrics within a single data center. So that was a lesson learned.

Then certainly in the data center era today there is a lot of discussion around the concepts of software-defined networks. In many ways QFabric was architected with several similar principles to a software-defined network. The QFabric controller is a body of software that now controls the nodes and the interconnect, and yet in order to enable the QFabric implementation and the value it creates, there was no open industry standard protocol for that communication. So we utilized some protocols that we have. So I think the discussion right now in a software-defined network is how we’re going to continue to evolve both our single-tier fabric and our two-tier switching portfolio around the concepts of SDN as we did with QFabric, but do it in a way where we can now start to influence the industry standards for open industry protocols, including things like OpenFlow and other industry protocols that can be enabled in these data centers. So I think that was another lesson that we learned.

You’ve said in a couple of quarterly conference calls that QFabric and Juniper’s New Network initiatives embody the principles of SDNs. Yet Juniper has not been one of the more aggressive or vocal proponents of SDNs, nor has it come out with an overarching strategy like your competitors have done on SDNs. Why is that?

Well I think we’ve been a very strong proponent of SDN and we’ve been very clear that we embraced the fact that the industry standard protocols will evolve. We’re a member of the OpenFlow community. We’ve partnered with many vendors that have OpenFlow-based controllers. We’ve enabled the SDN protocols, including OpenFlow, in our MX routers. We’ve publicly announced we’re enabling them in our EX switches and in QFabric. So I think we’ve been very clear that in the domain of the data center that the business problems, technology problems that SDN is trying to solve, that there’s a set of those that we think are very viable problems to think about how software can communicate with the network systems to solve those problems. And we’ve been very clear that we’re going to participate in the industry to shape the standards and ensure our systems can interoperate with open industry standards, including OpenFlow. What I think people are waiting to hear is — do we have a view on what type of SDN controller we might bring to market, and how would that controller participate in open industry standards and how would that controller create value beyond what current OpenFlow controller providers provide? We’ve committed to build those SDN protocols into our systems, including OpenFlow, and we’ve been making progress in this.

[Ed. note: Juniper says it won’t make a broad SDN strategy announcement until early 2013. On Dec. 12 it announced the acquisition of SDN controller startup Contrail Systems]

Do you think your competitors have been more “hypey” in the strategies they’ve vocalized?

I think we’re certainly at a point where something like SDN, there is a lot of visibility on that topic and with a lot of visibility and enthusiasm comes the risk that hype gets ahead of the reality. That doesn’t mean that there are not some interesting things that software-defined networks can provide, but it does mean that as a leader in the networking industry we feel like we have a responsibility to, number one, be at the table and help shape the industry standards around this concept of SDN, which we’re doing. No.2, ensure that our systems interoperate with these open industry standards. And No.3, as we share our point of view on where we’re going to play a role and where we think this thing is going to go, we want to make sure that that has substance and that we’ve thought it through and that it’s real, and that we don’t fall into the trap of wanting to just be a part of the hype for purposes of being part of the hype. But I think there certainly is a lot of interest in the topic of software-defined networks and certainly we’re being very thoughtful about the implications of those concepts and the right way, from our perspective, to enable them to help customers.

A couple of months ago we interviewed Bob Muglia [Executive Vice President of Juniper’s Software Solutions Division] at your headquarters and he mentioned that Juniper is looking to coalesce the industry around a third standard open source controller as an alternative to those from Cisco and VMware. Can you update us on that plan?

I think specifically what he talked about was OpenFlow-based controllers and there’s already OpenFlow controller technology in the open source community. And we’ve partnered and worked closely with Nicira and Big Switch and many others. And our commitment is to open industry standards as it relates to SDN, and OpenFlow is certainly one of those open industry standards. The view is that with some of the OpenFlow controller technology that’s in the open source community, that there’s a high likelihood that that’s going to get some traction by some number of customers and others in the industry that are going to keep contributing to that. And we think that’s a healthy thing. We think in something like software-defined networking, it’s healthy to have innovation coming from a variety of different sources. And so we do think that will manifest itself in an open source controller that supports OpenFlow. So our systems will interoperate with OpenFlow and other SDN standard protocols. And I think the things that we might be doing in the area of software controllers maybe will go beyond capabilities of the OpenFlow API, but will still be based on open industry standard protocols.

If you look at Cisco over the years, there have been various inflection points where it seems the door has been open for competitors to get a larger share of the enterprise away from them. Do you think that software-defined networking creates that kind of an opportunity for the competitive landscape to change significantly?

Well, the concept of software-defined networking as it relates to the data center requires a physical network to be in place for the software-defined network to talk to. So think of software-defined network concept as an overlay network on top of the physical network. I don’t think that necessarily changes the dynamic in terms of what’s important in the physical network. You still need a physical network that can carry the traffic, that’s low latency, that can scale and that is highly reliable. But that physical network also has to be able to have the software in it that allows it to communicate with industry standard protocols to that software-defined network controller. So in the context of creating an opportunity, I think the opportunity is for the current networking players to ensure that their network systems are able to implement SDN open protocols. And the degree to which I think network system players do that will allow them to continue to play and have a significant role in providing the network equipment for the data center. And that’s going to be separated from what controllers they’re talking to. I think there’s going to be a period of a lot of innovation. There’s a period of fast fails, some things work, some things don’t work, and the industry learns together the best way to solve the problem.

So if we read into that, this is one where Cisco’s more proprietary may actually catch up with it? People have always used that complaint against Cisco, but it’s never really seemed to hurt them in the market.

Look, I won’t comment specific to Cisco, I’ll comment on our own lessons learned with QFabric. You know, to enable the QFabric solution and the benefits it provides, there was no open industry standard protocol to do that, so we utilized a protocol that we viewed as a proprietary protocol. And customers look and say, ‘Hey, if there’s an industry standard protocol available and network systems utilize that, that provides benefit to customers because they have a wider range of choice and flexibility in network components, how they architect things.’ And so if that’s any indicator, I would think that customers would welcome the evolution of SDN to include industry standard protocols and I think they would favor those network suppliers that provide network systems that enable those industry standard protocols.

Things that go beyond that where a competitor tries to take an industry standard and add something to it to make it proprietary, oftentimes that does not benefit the customer. In fact, it starts to hurt the customer, because it starts to lock them into fewer choices. And there’s so much energy around software-defined networks and so many different parties at the table, I’m confident that those parties at the table are going to shape a set of open industry standards in terms of the protocols for how things communicate, and I think because of that, I think it will be very difficult for anyone to have something that utilizes a proprietary protocol for how to communicate. The key will be: can those software controllers communicate effectively with everybody’s network systems? And that’s going to require industry standard protocols.

Do you think that software-defined networking will be essentially owned by the networking companies or will it be owned by independents? Virtualization at the server level was owned by a non-hardware company, right? Is that going to happen in networking?

It’s the early days. It’s difficult to tell. I just look at Juniper. Our entire business has been based on open industry standard protocols. The Internet was built on industry standard protocols. We know how to compete and do that. We built Junos as an operating system, it’s a significant body of software that utilizes industry standard protocols. The fact that routers talk to routers over industry standard protocols and they’re able to keep address tables in sync. I’ve got to believe that networking systems companies like Juniper have assets in software that could manifest themselves in a different way. Instead of running in a router or in a switch, they could run on an x86 server and still talk to routers and switches. And so I wouldn’t necessarily count network systems companies out of the software equation when it comes to software-defined networks. Yet I also respect the fact that when you look at a data center, the management of that data center manages compute, storage and networking. So if you look at different ways to approach the problem, I think there may be some different solutions and I think it’s going to take a while for the industry to sort of sort out what is the reality behind the current buzz in software-defined networks and where’s the real value created?

From my perspective, the real value would be created by automating things that are very difficult to do today, which is going to reduce the operating expenses of running a highly virtualized data center. Yet, a lot of people think it’s about changing the capital expenditures that go into the network equipment in the data center. There may be some of that when it comes to the top-of-rack switch, but generally the biggest benefit to customers is going to be a change in the operating expenses by automation. And that automation is going to translate itself into productivity on how to run these big data centers and it’s going to eliminate what today I think are barriers to taking the virtualized data center to the next level. That’s my personal view, but there’s still a lot to play out here.

So where are you going with the QFabric controller then? Are you going to embed that industry standard protocol within the QFabric controller or interoperate with it? Are you going to keep QFabric proprietary?

What we’ve stated publicly, and what we’ll tell customers in our briefing centers and with our work is that we remain committed to the concept of single-tier fabric solutions and the concept of a two-tiered switching solution in data centers. We’re going to have both. There are some common components that we’re going to use in both and that clearly our commitment as it relates to software-defined networks is shaping the industry standard protocols and we’re going to really focus on how we can help the industry solve these problems with industry standard protocols. Beyond that, we haven’t made specific announcements on specifically how that will unfold, but as we take actions and take steps we will communicate more with our customers and the market on what we’re doing.

Do you see OpenFlow as that industry standard protocol or will it be an amalgamation of several?

I don’t think there will be one industry standard protocol, like there is not one industry standard industry protocol today. We think there are numerous industry standard protocols today, we think there will be numerous industry standard SDN protocols, and they may be used for slightly different things. And I think those protocols will evolve. So we intend to play a role in helping shape the definition of those protocols and we’re committed to enable solutions in our systems that take advantage of industry standard protocols. And we’re committed to focus on how we can contribute to the SDN solution set with intellectual property that we have that we think can add value to customers. So I don’t characterize OpenFlow as the industry standard; it’s one of many industry standard protocols in the domain of software-defined networks and we think there’s still a lot of evolution that will take place there.

Do you see the movement towards an industry standard set of protocols potentially hurting sales of QFabric?

No, QFabric provides great benefit to customers today. You can’t get the benefits of QFabric in the SDN world today. It just hasn’t evolved. It’s not mature enough, it hasn’t evolved. So if you want those benefits today, QFabric is a great solution. So we’re continuing to build out software features in QFabric, we’re committed to a road map with QFabric. And what customers want to know is, ‘Hey, can we think of how you’re taking us forward on QFabric in a way that starts to embrace more of the concepts of software-defined network?’ Which QFabric did. Yes. And, ‘can you take us forward in a way that this starts to lead us more to open industry standard protocols?’ And the answer is yes. So we’re going to take our QFabric customers forward and we’re going to take them forward in a path that we think embraces open industry standard protocols as they evolve, to be able to provide the capability that’s in QFabric. So customers that are investing in QFabric, we believe that’s an investment that we’re going to help them move forward in a very thoughtful way and yet they can get the benefits of that today.

The networking market is changing pretty dramatically. Cisco is selling servers and has actually made some pretty nice inroads into that server market. We see people selling bundled data centers — storage, server, networking. One could argue that VMware is becoming the next big networking competitor, because they want to own that data center from a management or higher level perspective. What does that mean for Juniper from a competitive positioning? Do you have to expand into markets that are adjacent? Do you have to take on different kinds of partnerships in order to compete in a very different landscape than it was a few years ago?

Yeah, well remember roughly 60% of our revenue today comes from service provider on the technology we provide to help power the Internet, and 40% from enterprise customers. Many of the points that you just made have to do with the technology stack in the data center. So when you look in the enterprise, specifically within a data center, you’ve got the compute, the storage and the network layers and we’re focused on the network layers. The way we engage then on the storage and the compute side is through partnerships, and we believe that’s the right way for us to continue to contribute in the industry. Because No.1, we still think there’s a tremendous amount of innovation that needs to be done in the network and that we believe it takes a company that is focused on the network, a company with a heritage in the network, a company that has world class talent in the area of network innovation to solve those problems and contribute to that. And for us as a company to say, ‘hey, we’re going to expand beyond that into storage or compute,’ I think that that would dilute the impact that we could have in the domain of networking.

Now, that said, we realize that networking has to interoperate with the advances in storage and compute, and so we work to make sure that we have appropriate partnerships to help ensure those solutions come to market. IBM has been a very good partner. When you look at, for example, things that IBM is doing with their PureSystems implementation, the fact that we’re working with them to now integrate Juniper Networks’ technology embedded in PureSystems in the way that they configure the servers and that offering, that’s an example. We completed interoperability testing with QFabric in EMC storage for customers that look at EMC storage arrays running on a QFabric system. So it does require us to reach out and partner with a number of partners and do the interoperability testing, or sometimes do some joint R&D together, all done in the spirit of ensuring that customers have the best choice of solutions available to them.

What was the rationale behind combining the campus and data center units into one unit recently? Aren’t their needs divergently different?

Basically, what we combined was the data center group which was building QFabric with the campus brand group that was building our EX switches. And the reason for combining those is we’re committed to two-tier data center solutions, as well as single-tier fabric solutions. That means we have to be thoughtful about the components we’re building and how we can actually share components across single-tier and two-tier. So for example, today we have a top-of-rack switch in the EX family for two-tier solutions, and we have a top-of-rack switch in QFabric that can run in two-tier or fabric solutions. Moving forward it makes sense for us to now converge — there should be just one top-of-rack that can operate in two-tier mode or one-tier mode. So it makes us more efficient in R&D and it actually helps us rationalize the product portfolio in a way that we think benefits customers. So that was the thinking behind combining those two businesses.

Where are you going with the EX line? We haven’t seen any major refresh or upgrade, especially of the core 8000 Series switch since it was introduced in 2008. What’s on the road map with that product line and that particular product?

Well we certainly have a product road map for our EX switch family that when we sit down with customers in our briefing center or at customer locations under NDA, we take them through that entire product road map. So we do have a road map for refreshing the product line whether it’s with new silicon for some new core switch capabilities in the data center, but we haven’t made those public as of this time. But we certainly have an open dialogue with customers under NDA about where we’re going with that and when we’re ready to publicly announce those products we’ll certainly make those announcements.

Do you see the current generation of QFabric being pushed down into the campus eventually as you come out with newer generations of QFabric for the data center?

Not really. QFabric is staying focused really on the problem space of a virtualized data center. There may be concepts of software-defined networking that go down to campus, but the QFabric single-tier fabric solution is really targeted at the data center domain.

What about a release of QFabric based on custom silicon? When can we expect that?

Well again, that’s the road maps we have for both single-tier fabric and what we’re doing on the two-tier solutions. We share those road maps right now under a nondisclosure agreement with customers. We’re happy to do that, but when we’re ready to announce what we’re doing with those particular products we’ll make those announcements.

It’s still in the plans though, correct?

We have a very clear road map for what we’re doing on single-tier fabric.

With 200-plus customers in 15 months, are you happy with the traction of QFabric?

Well, I look at the fact we entered the switching marketplace four years ago and we’ve built that now to north of a $600 million a year business and we’ve grown that 20% year-over-year through Q3 of this year. It’s clear we’ve made some progress. It’s been a few quarters since we were disclosing the number of customers running QFabric, I think it’s well north of the numbers that we gave a couple of quarters ago. But it’s fair to say that the adoption of QFabric has been slower than we would have liked, and it’s a combination of the fact that we just got some of the key software features out in the market that customers wanted. There are still some features that customers are asking us for – Layer 3 multicasting as an example. The introduction of the MicroFabric we think is helping quite a bit, where customers want to architect the data center with different fabric domains within that data center. We’re very focused on how we continue to evolve and enhance the products based on customer feedback. It’s fair to say the adoption rate has been slower than we had anticipated and that’s for the reasons that I mentioned.

HP has made some inroads into Cisco share, seemingly because they don’t really push a big architectural strategy; it’s sort of a replace here, replace there, when you have a need, bring us in. QFabric seems more like something that you have to buy into the whole architecture of and that’s a bigger decision for customers.

Certainly QFabric is a new architectural approach too, and that architectural approach in many ways is very similar to what people talk about with software-defined networks. And so any time you introduce and you innovate in a way that provides a new approach to things, there’s certainly a learning curve with that. And there’s a learning curve for us. There are things we learned engaging with customers that, whether it’s new features or the fact that they wanted to have multiple fabric domains within a single data center, we continue to take that feedback and enhance the product set and continue to evolve it. We think that’s a good thing. That open dialogue between Juniper and our customers is very important and that’s what helps us sort of shape the core innovation that we have with QFabric and how we’re taking it forward.

So we wanted to ask about the security business, because as you mentioned that was the enterprise’s first introduction to Juniper really. What are you doing in that business? Help people understand some of the key elements of the strategy there and how you’re evolving.

At a macro level, the strategy is really focused on providing more of an end-to-end security solution for enterprise customers. Everything from the end point to the network, and there are probably three areas that we’ve been very focused on enhancing the capabilities for enterprise customers. No.1 is manageability, and this is one that with the introduction of the SRX and our security solutions, we didn’t focus enough on manageability. And so over the last year, through a lot of customer feedback, we’ve enhanced and created this product Security Design, which basically is a graphical user interface that provides the enterprise customer the ability to set policy and configure it once in security design, and then push it out to all the security devices in their network. Prior to that, customers had to do too much manual work to configure each system, each device, and so the manageability is a very important piece. We’ve got a lot of good customer feedback, customer adoption. And so manageability is one aspect of it.

The second aspect is around analytics and how we’re helping take all the data that we get from security within the enterprise and turn that data into insight. So there’s work that we’re doing on analytics, both work we’re doing through organic R&D, but also with our partnership. Q1 Labs is a company that we partner with, and IBM acquired them, so now we’re doing some deep work with IBM on how they can bring their engineering capabilities and the capabilities they have around Big Data and Smarter Planet to apply to the security data. So we can provide better analytics, and we think that’s a very important aspect.

And the third area is in the area of content security. We have an AppSecure product that’s moving into the areas far beyond just traditional firewalls, where we’re able to now have visibility as to what applications people are accessing and what policy enterprises want set. They may say, ‘we want to allow employees to go to Facebook, but we don’t want them to play Farmville,’ if that’s what they choose to do.

That seems harsh, but…

That is very harsh, but enabling enterprise customers to make their decisions on the content side is also important. So I’d say our strategy is really expanding to say, hey, how do we provide more of an end-to-end security solution to customers? The three areas we’ve been most focused on that we had gaps were in the areas of manageability, analytics and content security.

Back to SDN. In a recent conversation with HP’s Bethany Mayer [Senior Vice President and General Manager of HP Networking], she talked about the fact that SDN could allow customers to eventually do away with stand-alone security devices or other appliances because you can start to essentially program the network to do this. Do you have that vision of SDN and do you think it creates those kinds of risks for your security products?

What we have done is we’ve taken that Junos code that does all the security of the branch SRX (hardware) and we’ve now productized it as a software offering that can run in the cloud. Now that’s a little different than software-defined network. If you don’t have the security algorithms that you’re running your traffic through, SDN’s not going to solve that.

I think what she was saying is that’s one of the applications you could build on top of the network if you’re programming a network, in essence.

But we’ve already implemented that. We’ve taken our branch SRX and created a product called JunosV Firefly, which is basically the same security algorithms and code that runs the branch. And so instead of having to put a device on premise, you can basically just route the traffic for that branch through JunosV Firefly and it can take care of your security for you. So we definitely see that trend happening and we’ve enabled products to do that. So whether it’s work that we have with large service providers who want to have that as an offering to businesses or small businesses where they can provide a virtual security appliance running in the cloud… we have a software solution for them today ahead of any SDN controllers. It works today.

Given the financial results of recent quarters, do you still see 20% annual growth as an attainable goal?

We did an entire day analyst meeting in June, where we set expectations on the growth goal. And what we said was we would grow two to four [percentage] points faster than the addressable markets, and we took the financial analyst community through our view of 2013 through 2015 — what we thought would be the compound aggregate growth rates in the market. We said our job is to grow faster than the market. What gets hard to predict, with the volatility we’ve seen in the addressable markets, mainly due to the macro environment, is to predict what addressable market growth is going to be. So what we’ve stated specifically as our goal is to grow two to four points faster than the addressable market. So that’s been what we’ve been very clear on setting expectations around.

In the Q3 conference call, you said the market is very challenging right now, that spending is soft in some of your key target markets, like service provider and enterprise. Do you see any glimmers of hope in Q4?

I said a week ago at the Credit Suisse Investor Conference in Phoenix that through the midpoint of Q4 linearity was on track. Clearly the comments I made in our Q3 earnings call, on the service provider side I said that we saw certain challenges in Europe, the Americas was doing well and Asia-Pacific was stable. On the enterprise side, we continue to see challenges in Europe as well. We commented that financial services and federal defense business, we were seeing some pressures there. But I think we had good performance in Asia-Pacific. So you kind of have to peel the onion back a bit and sort of look by geography and look by sector. But clearly I think with service providers in the Americas, we’ve seen some good performance and perhaps are more optimistic about the demand equation there. Although the addressable market for routers in service providers has declined 3% year-on-year through Q3. So this hasn’t been a year where the addressable market for routing has grown, yet at the same time Internet traffic continues to grow. So we’ve seen this trend before. Over the last 10 years, we’ve seen about three or four periods where there’s a pause in investment in routing infrastructure in service providers and that typically four to six quarters, six to eight quarters later you start to see that uptick. And I think we’re kind of coming out of the trough of the fourth period of that over the last decade and we’ll see what unfolds in 2013.

They have more capacity than they need right now? Is that the reason for that?

Well, in certain points of time, service providers will run their networks hotter, which means they’ll run them at higher utilization. Now they never run them at 100% utilization, they’ll never run at zero, so it’s always between zero and a hundred. So the question for service providers is — at what point do they feel like they’re running their network too hot? Oftentimes, if a network starts to run above 50% utilization, that starts to cause some concerns, because if you have some spike in traffic or you have a fiber cut that causes a flood of traffic and you’re not able to manage that, then it is going to have some implications on the quality of service to their users. So I think certainly when Internet traffic continues to grow and you see the addressable markets for routing are not growing, that’s just an indicator that they’re running their networks hotter, meaning they’re utilizing some capacity in their networks to run hotter, and at some point they have to make a decision to invest and build out more capacity.

So I’d like to kind of come back to the beginning and wrap up with two questions: One is, you came from a software company and now you’ve been running a network company for four years. How are these two worlds different? What have you learned about the networking world?

Well, let me remind you that, before Microsoft I worked at IBM. So I worked at IBM for quite a few years, and then Microsoft and now Juniper. I think the common thread in the technology side of things is that at Juniper, half of our employees are engineers that design, develop and build silicon systems and software, and roughly 80%, 85% of those engineers are software engineers. So much of what we do is a software problem. Granted, much of the value we create is from the custom silicon that we engineer, but it’s the software we write that runs on that silicon that solves these problems in the domain of networking. So there are some common things related to the technology, the business of being in a software business or a technology business, and yet there are things that are different. I mean understanding the different domains of networking, understanding the problem space that needs to be solved in networking and understanding the implications of how you solve those problems in the networking industry is very unique.

So the other aspect of that is, you went from a company that was the market share giant and now you’re competing with a company that’s the market-share giant. What has that meant to you as a leader in going from the role of being in the dominant company and now competing against one?

I think back to when I first joined Microsoft in the early ’90s, it was a company that was the challenger and competing with many others. And when I started at Microsoft I think there was about $1 billion in revenue, not much more. And so the experience of competing and being a challenger and growing a business I think certainly is a fun position to be in, and playing offense and being able to come up with new ideas and new innovation is certainly much easier when you’re the challenger than it is when you’re the incumbent. And I think Juniper, clearly our value creation has to come from innovation. It has to come from our ability to do organic R&D. We’ll certainly complement that with tuck-in acquisitions, but we are a company that has to invent and create and come out with new ideas, new architectures, new systems, new software, new silicon, and if we do that well we’ll have an opportunity to grow. So the ability to play the role of the innovator and the challenger is a fun, rewarding role. If you’re the incumbent I could say, look, there are a lot of things that are hard about being the challenger and the disrupter and trying to claw your way with a very big dominant competitor. But I guarantee you there are a lot of hard things about being the incumbent dominant competitor and defending what you’re doing. Both sides of the table have certain things that you would say are benefits and certain things that are challenges to them.

So the question that we always like to wrap up with — you have 30 seconds, you’re in an elevator with a CIO: What do you tell them about why they should be doing business with Juniper?

I think certainly networks are important to how businesses operate today. If people can’t communicate and have access to the data systems that they need, that’s going to impact a business. And so when you think about where you’re making your investments in network technology, we think there are innovative new approaches that you should be aware of and that Juniper can play a role in your network, as we do with many other Fortune 500 companies today. And we’d welcome the opportunity to have that dialogue with them directly.