News Stay informed about the latest enterprise technology news and product updates.

Cisco CIO to enterprise network managers: Think like service providers

At Interop Las Vegas 2011, Cisco CIO Rebecca Jacoby will bypass subjects like switching and routing, instead talking private cloud and delivering measurable services.

Image goes here

Rebecca Jacoby, Cisco CIO

When Cisco CIO Rebecca Jacoby takes the stage as a keynote speaker at Interop Las Vegas 2011 this week, she will not talk switching and routing or speeds and feeds. Instead, she'll use words that make networking folks prickly, like service-level agreement (SLA) and LSS, and she'll address the need for IT shops to transform into service-oriented architecture providers. Of course, she'll also explain how the network plays a role in this metamorphosis.

Jacoby has lead Cisco's internal IT shop down the services path, building two new Texas data centers that serve as a private cloud and host nearly all of the company's core business applications, including telepresence and collaboration— which have an extremely high bar for service assurance.

Jacoby sat down with to explain Cisco's data center and IT organization transformation and what it takes to ensure application and service delivery to Cisco's enormous campus and thousands of employee devices.

Interop is a network show, so this talk of services is different. Is this indicative of how networking trends have changed?

Rebecca Jacoby: When I first came into this role [over four years ago], there was a bifurcation between people that were working on applications and business process vs. the people working on the infrastructure in the organization.

As application service providers have evolved over the last decade [we realized] you can't go out and buy the business service required and not necessarily think through all the different technological components it takes to deliver that service. There is a big evolution as we move to cloud services that causes us to understand that we need technical expertise in both infrastructure and applications. It has become increasingly important to understand how those things work together. The way that manifests itself in everybody's career is you need to know the bigger picture beyond your technology because the only thing that counts in the end is the business service that you're delivering.

Where do the Cisco data centers fall into this picture?

Jacoby: When I first came into this role, I wanted to know why we weren't more virtualized. It just seemed that virtualization was a logical approach from a business standpoint. That's when I first learned that running a virtualized data center is completely different in terms of the architecture, the processes you use to run the data center and even the culture of the people that are running it. It's quite different than having a physical stack where you have specific experts on the server or specific experts on the network or storage. Having services that are multipurpose changes everything. We needed to change our overall architecture, as well as the processes and culture associated with the data center, too. This included organizing a little bit differently—growing to more of a lifecycle organization with horizontal technical expertise.

We've been on a journey for a couple of years to implement this data center strategy, which manifested itself most recently in two data centers in Texas. One of the biggest factors in making that successful was making sure the applications and the data center architecture work together seamlessly.

You've already seen a big savings and improvement in operations, right?

Jacoby: The results we've gotten are pretty spectacular. Overall, from pure virtualization we've seen about a 37% improvement in total cost of ownership, and as we've applied cloud services techniques and started to move our major applications into this environment, we're getting another 27% savings in our overall operations cost.

More importantly, we've reduced the time to provision those services significantly.

A couple of years ago it was six to eight weeks to provision any kind of data center services, and now we can provision something in about 15 minutes. This would not work if it were strictly an infrastructure program.

Can you talk a little about the technical architecture behind this?

Jacoby: We have virtualized all aspects of the data center. We're using a Cisco set of architectures with the Unified Computing System (UCS) and unified fabric, and that's allowing us to move forward with simplification across the board on things as seemingly mundane as cabling, but also how we manage the total set of resources.

How does this support the application architecture?

Jacoby: Another topic that has been around the IT organization for years is a service-oriented architecture relative to the applications you deliver. If you take the principals of virtualization in terms of what it delivers and how assets can be leveraged in a relatively rapid form, we're taking the same approach to all applications. When you look at the whole architectural stack together, you can get some advantages. But not all applications are the same. You have large-scale services that are transactional in nature, such as order management, supply chain, HR systems. What you want to do in instances like that is standardize as much as possible and make them usable for multiple aspects of your business. You can modularize those applications that are critical and architect to provide differentiation.

How do you prove your level of service in this scenario?

Jacoby: When you talk about data center services there is a matrix of things that we look at. It starts with understanding total cost of ownership for your service. So in our data center we can talk about Infrastructure as a Service, and we are able to talk about all the key components, including compute, storage, network and communications. In most cases, we have a tiered approach to that—gold, silver, platinum. Depending on what somebody's business state is, we can say, 'Here is where [and how] we can apply this part of the architecture and this is what the total cost of ownership is going to be.'

Closely related to that is cost-per-use, and that is an art form because you have to define what per-use means by service. [You have to ask:] What are you trying to measure and is that truly leveragable? These are important from an operational cost perspective. From an IT perspective it's important in terms of teaching people to clearly define their service.

In the world of cloud services, this is critically important because the IT professional needs to be able to benchmark their service against someone that can provide it externally. And frankly, if you find a situation where the right thing to do is source that service, either in full or in part, than your job as a service owner becomes to provide this service in the best possible way for the company. To make those tradeoffs you can't just look at cost. The other things we look at are the actual service levels and where possible we tier those. We also consider the time to provision, which turns out to be very critical. Then there is risk profile. For your service, what's the level of resiliency and security that you need to apply? This is a developing space.

Can you talk about ensuring this service level for communications services?

Jacoby: Any other application I deliver is essentially used by part of the company, but collaboration and communication services are used by everybody. We've done a lot of experimentation; we've learned it's still about defining services. Some of them are traditional in nature, so I deliver client services to the basic devices like desktop or phone. But we also deliver the ability to do video conferencing, and we do virtual events within the company. How do we deliver that as a service? We look at them from a performance standpoint the same way I described any other service.

Do you serve these applications out to any device on the network?

Jacoby: The strategy really is any device, anywhere. I wouldn't say we have that ticked and tied but we are well down that path.

If you just attack the front end of how somebody interacts with the system, there are some challenges. So you need to look at how this affects the rest of the architectural stack over time. I foresee a situation where we're providing cloud services [to these devices]. I may choose to source from multiple services. I am going to be sourcing these from my cloud and multiple external clouds. Creating content and applications, deciding where they reside while you're operating them, and decoupling that from the device somebody chooses to use or where they're located in the world, is the end game. It's critically important to provide choice at that initial connection point. It's a losing battle for people in IT to say, ‘I am going to tell you what device you need to use.’ We need to concentrate on how and where we manage the content and the applications, where they reside and how we secure them.


To learn more about Interop, view our 2011 Interop Las Vegas conference page.

Dig Deeper on Network Conference and IT Conference News

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.