Full exposure: How Kodak converged its net

News
Aug 30, 20047 mins

Eastman Kodak’s IT group has undergone sweeping changes, consolidating servers at 350 sites into one data center at headquarters in Rochester, N.Y., and standardizing on SAP software across the company. At the same time, Kodak converged its international voice and data networks over an MPLS VPN service. John Parsons, a 32-year veteran of Kodak who oversaw the projects, spoke recently with Network World Senior Editor Phil Hochmuth.

If any company is familiar with technology churn, it’s Eastman Kodak. The photography pioneer’s technology has evolved over a century from the first photographic dry plates to film to digital imaging. More recently, the company’s IT group has undergone sweeping changes, consolidating servers at 350 sites into one data center at headquarters in Rochester, N.Y., and standardizing on SAP software across the company. At the same time, Kodak converged its international voice and data networks over a Multi-protocol Label Switching VPN service. John Parsons, a 32-year veteran of Kodak who oversaw the projects as manager of Kodak Global Telecommunications, Worldwide Information Systems group, spoke recently with Network World Senior Editor Phil Hochmuth.

How do business conditions at Kodak affect network technology decisions?

Kodak is going through a major transformation from the film and paper world to a digital world. The profit margins are a lot less on digital; therefore, we have to restructure the company’s cost structure away from the labor-intensive, analog film business. So we’re going through some shrinkage and restructuring. At the same time, demand for services, particularly data, continues to rise, so there is more and more demand on the network. We have a single instance of SAP that is the core of our ERP system that runs in Rochester. . . . That puts some stringent network requirements on a global basis to make sure people are getting good response time globally.

How has consolidating servers and apps helped the business?

The company has seen a lot of benefits from running a single instance of SAP. We have a much more integrated view of what’s happening in the business at any point in time. That’s certainly making the company run better. But that decision to run SAP out of Rochester and service the world with it made life very difficult from a networking perspective. We had to make sure people had good performance from Rochester to the inner cities in China. That was a challenge, but we’ve learned a lot by doing that, too.

You recently moved from a private-line network to an MPLS-based VPN. Why?

Increasing data bandwidth [for SAP] was one of the drivers to put out bids for an MPLS network. At the same time, we were adding VoIP. [Voice and SAP] are time-sensitive, where a person is sitting there waiting for something to happen. . . . With MPLS, you end up with more of a meshed network, instead of a point-to-point network. You get connectivity from any site to any other site without going through multiple hops. You get some class-of-service options too, so you can differentiate traffic.

How is using an MPLS-based VPN service different from managing a private-line backbone?

We’re looking to get more bandwidth for less money, and that just requires almost constant renegotiation and redesigning. You really have to look at the traffic patterns. If the traffic patterns change because the number of employees in a plant changes, you need to adjust the bandwidth or adjust the topology as to what connects to what. We’re always looking at new technologies.

Are you and your staff less involved in network management now that it all runs on a managed MPLS VPN service?

My network engineers are still heavily involved with the carrier when they install the system and configure it. We’ve got as much experience as these carriers. We want to make sure we don’t just throw the specs over the wall and say go ahead and do it without us watching. We stay heavily involved in the planning and design to make sure it’s done right.

When did you start converging voice and data?

We started converging the network in 1999 with a couple of facilities in Asia, when we couldn’t get the carrier voice services we wanted. . . . We had standardized long ago on Cisco routers for data network technology, so it made sense to take a look at interfacing the PBXs to those routers and adding the VoIP capability on the data backbone.

What was more complex: voice/data convergence or the SAP implementation?

In the past, my group has spent more of our time dealing with data problems and making data applications work. The voice network typically just sat there and the PBXs go in and stay there for years; you don’t touch them, just maintain them. I’d say there’s less voice expertise in the company to deal with changing the voice network. So that was probably more of a challenge. It’s funny because you would think that running one application worldwide would be more complex.

What have been the benefits of going to VoIP?

Cost savings. Over the last five years, by going to VoIP, and things like MPLS, we’ve been able to drive $3 million a year out of our international voice costs.

Did you set a dollar value for the savings you expected?

It was more incremental. Once we started into voice over IP and saw it could work and save money, we continued to do it where it made sense. There was no big program that said we’ll save $5 million over five years and here’s how.

Were there staffing issues in converging voice and data?

Our staff is more data-centric. Most of the voice work was negotiating carrier contracts and making sure we got good rates.

For a long time we’ve had the voice and data people together in one organization. So there wasn’t much of an issue in bringing voice and data staffs together. Some data people had to learn new voice skills and voice people had to learn data skills, but that’s goodness in the end.

What were the major nuts-and-bolts challenges?

Getting the interface between the PBX and the router to work properly, and getting all the signaling that goes on to work properly . . . all those little nuances with making a call. We had to have our Kodak router engineers working with the Cisco router engineers right alongside the [Nortel] PBX engineers. . . . When we started out, we had to learn how to tune the thing, how to do the QoS and the bandwidth management. That took a little while. When we put in the new MPLS system in Asia with Singapore Tel, there was a learning curve to make sure things were configured properly.

Are there plans to put IP phones on desks or to implement converged voice/data applications?

We’re taking it fairly slow at this point, focusing on our WAN for VoIP. We haven’t put a strategy together on what exactly we’re going to do with IP telephony and how fast we’re going to get there.

I’ve been hoping to hear about more killer applications out there for IP telephony, but I haven’t seen much. Mostly [applications such as unified messaging and presence] seem like convenience things. Some of those things would not impress the CIO or the CFO with the business case. They’re looking for hard dollar savings right now. There’s definitely a place for some of these converged applications. But it’s a matter of putting a compelling story together as to why we should make the investment.