Utility IT exec to explore power of Web services

Zimon, CIO and a senior vice president at energy company Nstar in Boston, has an atypical perspective on network technology. He sits down with NW’s Bob Brown to discuss Nstar’s key IT initiatives.

Gene Zimon, CIO and a senior vice president at energy company Nstar in Boston, has an atypical perspective on network technology. While he currently oversees a statewide network for the utility, which serves 1.3 million residential and business customers across Massachusetts, he also has spent time on the vendor side, most recently at Oracle. This is an edited transcript of Zimon’s talk with Network World News Editor Bob Brown about Nstar’s key IT initiatives, including a move into Web services.

What do you see as the pros and cons of being an early technology adopter?

Considering that Nstar is an energy distribution company focusing on improving customer service and operational excellence, I don’t feel that being an early adopter of networking technology is appropriate. However, if a new technology will provide us a significant opportunity to achieve improvements in customer service and/or reduce our operational costs at reasonable cost and manageable risk, I would definitely consider piloting and adopting it. I have done this in the past with wireless technologies and am considering several emerging technologies [now].

What are your main challenges?

The key things are driving improvements in data quality and leveraging our systems so we can get information to our internal customers that’s needed to manage and measure our business and improve our workforce’s productivity. Our focus now is primarily on improving the outage management process from the time a customer calls to the time we actually restore service and issue a follow-up work order to correct the system.

Our role from the network standpoint is to keep the outage management system up 100% of the time. We’re decentralizing our dispatch system by setting up new service centers. From a network perspective, we’re basically just building redundant links to those centers. But the other thing we’re concerned about is how the power restoration process would be affected if the network or a service center went down. We’re planning to build redundant data centers. The first step there is building high availability into the servers, and we’re looking at building a geographically dispersed storage-area network.

So your efforts are largely about speeding business processes?

Right. One key project we expect to roll out in the spring will make it easier for customer service reps to answer questions. We’ll provide the [representatives] with a portal to all back-end systems they need for that job, from billing to services. That is all done through WebMethods messaging and Oracle CRM on the front end.

Then you’re getting into Web services?

I guess you could say we are. We’re starting small, not attacking it as a special project but really as part of a project to solve a business problem. We’re moving to setting up internal services for validating information and providing reference services. One problem we have is a disparate set of systems that our people use for things such as addresses of customer premises. We’re trying to establish a message-based premises reference [system] such that you enter a request about a premises in one system and it goes out across the network to validate a street address, ZIP code, and the X and Y geographical coordinates. We also might do this when looking up equipment we use. The hardest part in all this is getting agreement on what the problem is. Then we need to build a data model from which we can build the reference services that self-populate as much as possible.

Why Web services rather than more traditional application-development methods?

While we’re starting internally, the real potential benefits will come when we’re able to take advantage of external providers of certain types of databases and/or services. There’s no reason we need to create all these types of databases internally. Right now some these limited services are free, too, although we’d need to validate them. To create an extended enterprise that can take advantage of these services we need to componentize our application architecture, so all the parts can just plug and play.

One example of where we might want to take advantage of this is when a utility pole goes down or is damaged and you see double poles go up. That damaged pole can’t be removed without the cable, telephone and electric utilities taking action in a prescribed order. Web services could be used to determine the status of these actions, the order of which varies based on who owns the pole. In fact, all the major utilities in Massachusetts got together and selected a vendor to provide what is really an application service provider; however, this functionality could be restructured as a Web service that could work with our back-end systems.

Web services have been hyped to death over the past year. Do you think they’ll live up to the hype and if so, how soon?

Web services are extremely appealing from an architectural and cost containment perspective, and therefore Nstar is closely monitoring product development strategies of application and other technology vendors. Currently, it is more hype than real in that we have not seen true usable Web service delivery components from the major application vendors beyond some [programs for validating customer locations].

My view of a Web service is the ability to initiate a request from your internal portal and have that request validated and returned by an external or internal Web service. To achieve this there are issues related to the availability of portals, data latency, security, validity of source and cost, which need to be defined. None of the enterprise portals currently on the market are architected to take advantage of the emerging Web services standards, particularly the emerging interoperability and security standards. Such portals are not expected to come on to the market until late 2003.

What ramifications do you expect running Web services to have on your network and computing infrastructure?

We presently deploy most enterprise applications through a distributed client/server model. Few are deployed on the desktop. As we upgrade these applications, we will be moving to a thin-client model. Thus, we already have a fairly high-traffic network. I’d say that the greatest ramification of running Web services, and particularly depending on the distributed Web services delivery model, is going to be the administration. For example, how will enterprises deal with Web service components hosted outside the enterprise that are subject to change? How can you guarantee availability of key business functionality or continuity of service when such functionality is coming from outside the enterprise? How do you ensure that two Web services components, both of which are hosted outside the enterprise by different entities, remain in synch?

It will be our intent to pilot some minor Web service applications internally to better understand the internal network traffic. Examples could be our employee telephone directory, our conference scheduling capability and, as I mentioned before, evolving some of our reference data services.

Are you giving Microsoft’s .Net architecture a look?

We are presently watching both .Net and J2EE [Java 2 Platform Enterprise Edition]. This is the key technical decision that we will need to make within the next six months. It impacts multiple dimensions and layers on our technical architecture, and we will need to understand the benefits, limitations and risks of the various options. Analysts seem to be favoring J2EE as the standard to adopt.

What does your network look like?

We have a totally redundant Gigabit Ethernet fiber ring around the Boston area that connects our major sites, and Ethernet, frame relay, T-1s or T-3s to all our service centers. Our unregulated subsidiary, Nstar Com, installed the fiber. Verizon is our primary carrier, and we have UUNET for Internet access. We’ve completed all network integration work associated with the merger of Boston Edison and Commonwealth Energy that formed Nstar.

On the computing side, about 90% of our servers are in our data centers. We have several types of Unix, but are in the midst of a consolidation in which we’re moving all Unix servers to Sun Solaris SunFires. They offer high availability and can back each other up. We have [Windows] NT servers and are moving to Windows 2000, and have mainframes running a couple of major applications that are outsourced to IBM. We manage the NT servers internally but outsource the Unix server management to IBM.

Any room for Linux?

We are looking at possibly using it to run some  applications, as a cost savings measure.  We have an architectural group that will begin looking at our best options though. Our Chief Technologist, Jack Weilandt, feels strongly that  Linux it is something we should seriously consider.

Where does wireless fit in?

We’re focused on externalization of applications in general, wireless or not. We’re  planning to push transaction processing to the mobile workforce and looking at providing self service to our customers and suppliers. But first, we need to have our internal operations optimized before we expose them externally. Architecturally, we are moving to a wireless gateway that would allow anybody to access any application through any communications protocol. This may be a public wireless network or a private one since we already have a private radio network in place. We’re looking at how to upgrade that private network. We don’t want to roll out just one application either. We want to roll out a portal for our crews so that they can access multiple applications, such as maps, manuals and payroll. They won’t use them if they don’t add value.  We’re finding that a lot of our data transactions are small enough that there would probably be enough bandwidth in our private radio network to handle voice, too. We’ve got a wireless LAN in one field warehouse and it’s working fine.

We’re also looking at voice over IP over this network but given our concentration of facilities in Eastern Massachusetts, we are not sure it will be cost effective.

Do you have plans to move to VPNs?

We’re very interested in VPNs and the primary driver is cost. We were looking at them primarily as a means to allow access to third parties that are working with us on the network. The first VPN we’re using has been with Oracle product developers working with us on our CRM project.  We want to give them limited access to our network and are very concerned about the security ramifications of a VPN.  When we implement new systems we use external consultants a lot. But we don’t necessarily need them physically here, so as a means of reducing travel costs that are passed along to us, we want to move much more to secure remote access for these third-party providers. Overall, we’re looking at more efficient means of remote access for our internal and external users.

If you could change one thing about your network, what would it be?

Our network is basically sound. If we could change anything, it would be to automate security patches and updates for the network. From a technical standpoint, this could be done, but from a practical standpoint we have always had trouble with the automated update process. The other area would be to ensure more automated and proactive network performance monitoring and intrusion detection . . . both of which we are working on.

What did you learn being on the vendor side that you’ve been able to use on the user side?

I was CIO at Boston Gas, then moved to Oracle [for nine months], where I got a much broader view of all aspects of the energy industry. I was responsible for helping Oracle with product development and to increase its penetration for this sector. I got a broad perspective on how partnerships should work between systems integrators and vendors, I viewed the product development life cycle and the approach to which products are released and tested. It certainly gave me an understanding of pricing structures in terms of what can and can’t be done.

From a negotiating standpoint, I got a better perspective on where a vendor comes from. You’ve got to look at the four parties in any negotiation: the project manager and decision-maker on your side, and the salesperson and sales manager on the vendor side. They’ve all got different objectives and you’ve got to develop a negotiating strategy that results in a win-win situation since you’re really building a partnership, not just beating the vendor.

How has the economy affected your efforts?

Our IT budget has been falling in actual terms for the last three years, so we’re trying to reduce the cost of maintaining our network and systems. We’re doing a lot of TCO studies of everything from PC purchases to voice and data network services, looking to free up resources for more value-added business process systems. I have more projects than I have labor capacity and more projects than I have dollars. We go through an internal ROI analysis on every project, even those that aren’t necessarily designed for any rate of return. But at the same time, it’s most definitely a buyer’s market. I’ve still done a significant amount of buying consulting contracts, hardware and software and I feel like we’ve received value at very competitive prices. We try to make what we have work, but at the same time, if it’s not cutting it, we’ve got to move forward. Take our customer billing application on our mainframe system. It’s been around for years, but we are  putting a new front end on it and eventually want to componentize and replace those functions that don’t work that well, leaving the system to do what it does best:   bill residential customers.

Another example is our work management system. We had an improvement project for that in which we put together a team and said you’ve got 90 days to come up with ways to make it so that this system is simplified and delivers productivity gains. The team rose to the challenge and delivered significant savings while leveraging existing systems.