Gene Zimon, CIO and a senior vice president at energy company Nstar Corp. 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 Bob Brown about Nstar's key IT initiatives, including a move into Web services.
Q: 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].
Q: 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 percent 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.
Q: 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 (Inc.) messaging and Oracle CRM on the front end.
Q: 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.
Q: 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.
Q: 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.
Q: 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.
Q: Are you giving Microsoft Corp.'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.
Q: 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 percent 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.
Q: 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.
Q: 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.