By Steven M. Brown, Associate Editor
Ludwik Lejzer Zamenhof is not a name generally associated with the electric utility industry or systems integration, but parallels do exist between the Polish philologist’s efforts in the late 19th century and the back-office landscape of modern utilities.
Between 1877 and 1885, Zamenhof undertook an ambitious project: to construct a common language so that all people, regardless of nationality, could communicate more easily and effectively with one another. It was Zamenhof’s opinion that much of the conflict that arose between different people and different populations of people came as a result of their inability to speak a common language. To solve that problem, Zamenhof developed a universal language that became known as Esperanto (after the pseudonym-Dr. Esperanto-that Zamenhof published under). Esperanto never gained the widespread acceptance that would have been necessary for it to achieve Zamenhof’s goals, but the concept behind his effort was sound. If Germans, Russians, Poles, and Zamenhof’s other Eastern European neighbors could only communicate more efficiently, then maybe it would not be as difficult for the parties to resolve the differences that occasionally developed between them. Perhaps, he believed, they could even live in harmony.
It’s not too great of a stretch to compare Zamenhof’s efforts and desires of 120 years ago to the efforts and desires of those charged with integrating back-office utility software systems today. While communication barriers between a geographic information system (GIS) and a customer information system (CIS) aren’t likely to spark an international conflagration, the integration of these systems can be a problem nonetheless-particularly for the smaller rural electric cooperatives that lack the IT infrastructure to foster harmony between pieces of utility software. As rural electric cooperatives continue to become more sophisticated in terms of automation, integration issues have become a top-of-mind topic in this industry segment.
Rural electric cooperatives are relying increasingly on the same types of GIS, CIS, engineering analysis and automatic meter reading solutions that the larger investor-owned utilities employ, said Martin Gordon, senior program manager for the National Rural Electric Cooperative Association’s (NRECA’s) Cooperative Research Network (CRN). And, as a result, co-ops are facing the same integration issues that the rest of the utility industry is confronting.
“It’s important to remember that just because our members may not be that big, it doesn’t mean they’re less automated,” Gordon said. “Our members are telling us that integration is a problem, and it’s only going to get worse. For our members, who are relatively small, data integration is a major issue.”
At issue is the fact that as rural electrics work toward automating such functions as mapping, staking, billing and a variety of customer service operations, they realize the need not only to automate those specific functions, but to exchange information between the various systems. So-called “islands of automation” (see figure next page) exist when information from one automated system cannot be exchanged, or at least cannot be easily exchanged, with information from another automated system. This occurs most often when utilities attempt to integrate different systems developed by different vendors. When two disparate systems cannot communicate with one another, it becomes necessary to build a custom interface between the two-a bridge between islands of automation, so to speak. The task of building that bridge falls on either the utility itself or on the software vendor. Regardless of who the onus falls on, building custom interfaces between software systems almost always acts as a hindrance to achieving the organization’s actual goals. If it is the utility that is charged with building the interface, time and resources are taken away from the goals of delivering power and serving customers. If it falls on the software developer to build the interface, doing so takes him away from his core responsibility of developing and improving upon the core product. To put it simply, no one wants to build the necessary custom interfaces, and no matter who ends up doing it, a core competency suffers as a result.
This is particularly the case for smaller rural co-ops, which generally do not have the same IT resources of larger investor-owned utilities. For the smallest of rural electrics, the person in charge of integrating systems may not necessarily be a computer professional at all, said Barry Scott, information and communications services manager for Sulphur Springs Valley Electric Cooperative (SSVEC). SSVEC likely would be classified as a medium to large cooperative with its nearly 50,000 accounts. As such, SSVEC has sufficient staff with sufficient technical knowledge to either perform custom integration chores themselves or to negotiate stringently with software vendors whenever integration issues crop up, Scott said. But even for an adequately staffed cooperative, systems integration is not an enjoyable task.
“If you’re not talking to a vendor who offers a pre-integrated suite, or you’re talking to vendors who haven’t worked together in the past, integration can be quite daunting,” Scott said. “Anytime you want to make a major systems upgrade, it’s like pulling teeth because people know how painful the integration process can be.”
And it’s a painful process not only to the utility. Industry software vendors detest building custom interfaces as much as do the co-ops to whom they market their systems-if not more so. Hal Gentry markets AM/FM/GIS and automated staking systems to about 300 utilities. He estimates that probably 60 percent of his customers are rural electric cooperatives. Despite the small size of some of those cooperatives, Gentry acknowledges that their software and integration needs are the same as utilities of a larger scale.
“Islands of automation affect rural electrics just like they do the IOUs, municipals or anyone else,” Gentry said. “Co-ops want and need to integrate data from different systems. We can save co-ops a lot of time, but the systems have to be integrated first.”
Unfortunately for Gentry and those of his ilk, much of the integration burden falls on the software vendor. The result is that Gentry cannot always devote his resources in the proper areas. “For each application that we write, there may be 10 different accounting and billing systems that we have to interface with. It’s a massive job,” Gentry said. “What I would rather do is work on my core application as opposed to building all of those interfaces.”
MultiSpeak Aims for Integration
Help may be on the way for Scott, Gentry and the hundreds, if not thousands, of others affected by the integration woes of rural electric cooperatives. The Cooperative Research Network (CRN) of the NRECA is sponsoring the MultiSpeak Initiative-an aggressive, collaborative effort between about 40 industry vendors to develop a specification for common data interfaces between their products. MultiSpeak isn’t exactly Esperanto for back-office utility applications, but its goal-to ease data exchange between the systems most commonly used at rural cooperatives-is not terribly dissimilar from the goal Zamenhof worked toward 120 years ago. MultiSpeak, however, seems more likely to be widely adopted than was Zamenhof’s failed universal language.
For all practical purposes, MultiSpeak was born a year ago in October 1999. At that time, Gary McNaughton of Cornice Engineering spoke to a CRN task force about the issue of data integration. McNaughton realized that the best-case scenario would be to bring together as many industry vendors as possible to discuss the development of an interface definition specification; however, that didn’t seem likely to happen. Data integration was no doubt an important issue for vendors, but was it important enough for competing vendors to work together toward such an interface definition? As it turns out, it was.
“We had a kick-off meeting,” McNaughton said, “and basically the vendors said that integration and having to support numerous interfaces was getting to be such a problem for them that they were willing to sit down and talk to each other. That’s never been the case in the past.”
McNaughton sat down with a group of six vendors at the initiative’s initial meeting in October 1999 to discuss what would need to be done to arrive at a common interface. The vendors told McNaughton that for the initiative to go forward, there would have to be agreement on data models, process models, and a knowledge of how co-ops input and interchange data in various back-office systems. Initially, MultiSpeak would focus on five types of software systems: GIS, CIS, engineering analysis, interactive voice response (IVR) and automated staking.
“The vendors said if you could just tell us what the co-ops want in terms of data and leave it up to us to deal with the architecture, that would simplify our lives tremendously,” McNaughton said.
“The other thing they said was that they didn’t necessarily want to share data with each other, but if they could feed data to an independent third party who would mask the details and give it back to them, they would work on that basis.”
McNaughton became that independent third party, acting as a sort of human data integration interface between the various vendors. He also became a salesman, pitching his back-office lingua franca to vendors with significant interest in rural cooperatives.
“We wanted to get as many vendors participating as possible,” McNaughton said. “As soon is it became obvious that this wasn’t just another data integration flavor of the month and that it was supported by the NRECA, more vendors started participating.” The current list of vendors active in the MultiSpeak project includes such industry notables as Gentry Systems, ESRI, Intergraph, Mesa Solutions and CES International. The initiative is also receiving support from the American Public Power Association, which represents the interests of municipal utilities.
What McNaughton wants to produce as a result of this vendor collaboration is an interface definition specification that will facilitate the exchange of data between the five types of software systems mentioned earlier. Although initial plans were to accept an ASCII text file as the lowest common denominator for data exchange, it now looks as though MultiSpeak will use extensible markup language (XML) as the transfer mechanism. XML’s flexibility, McNaughton said, will make it easier for vendors to support MultiSpeak-compliance.
“One of the problems we encountered early on was that the different co-ops implement things in different manners,” McNaughton said. “Do they store transformer information in the GIS or in the plan accounting system? Where is the primary store? We ran into process flow problems and were going to have real difficulty with ASCII text files as the transfer mechanism. We were going to have to define a data flow for both directions and implement the one that made sense in each particular co-op. With XML, you can set the characteristic of the data flow in the DTD (document type definition), and then if there are data attributes you don’t need to send, you just don’t send them.”
McNaughton expected the last round of comments from the initiative’s vendor group to be coming in at about the time of this writing. The next step would be to issue an interface definition (in the form of an XML DTD) for industry comment. Once comments are reviewed, the definition can be released to the industry for implementation. McNaughton hopes to have MultiSpeak-compatible systems, at least to provide proof-of-concept, by March 2001 to coincide with NRECA’s annual meeting and technology expo.
Rural co-ops and vendors alike seem excited by the concept of an interface, which, if not quite universal, is closer to universal than anything they’ve had before. According to McNaughton, the comment he hears most often from co-ops is that “they wish they would have had something like MultiSpeak five years ago.”
Bob O’Connell of ESRI, a vendor actively involved with the initiative, said that successful completion of the initiative should dramatically decrease the time it takes rural co-ops to implement new technology. “This should ease the ability of the co-ops to rapidly embrace good IT business systems,” he said. “One of the biggest things that will come out of this is that a co-op will be able to implement a true business system faster and more cost-effectively than ever before.”
Both Scott of SSVEC and Gentry of Gentry Systems note that co-ops will also benefit by being able to take a best-of-breed approach to systems implementation. Scott said he believes that picking and choosing individual systems from different vendors generally works out better than buying a pre-integrated suite of software from one vendor. Unfortunately, many small co-ops often opt for the pre-integrated solution so they can avoid the hassle of building custom interfaces. But according to Scott, “Nine times out of 10, a homogenous package is not going to do everything you need it to.”
Gentry echoes Scott’s assertion that utilities will benefit from a best-of-breed approach to software purchase. “Now rural electrics can buy the best application for their needs, and integration can move toward the background,” Gentry said. “Now the co-ops can concentrate on who has the best technology, as opposed to who has the best ability to integrate with what they already have installed. Utilities will finally get what they’ve been wanting for a long time-ease of integration and the elimination of islands of automation.”
Those interested in learning more about MultiSpeak or in participating in the interface specification’s technical review can contact Gary McNaughton at Cornice Engineering (970-264-6121, email@example.com) or Martin Gordon at the NRECA’s Cooperative Research Network (703-907-5840; firstname.lastname@example.org).