Integration in a changing is world

Integration in a changing is world

Jennifer L. Fischer
First Energy Corp. 253 White Pond Drive Akron, Ohio 44320

First Energy Corp. (FEC) is creating an Enterprise-wide solution by integrating its AM/FM system with other mission critical systems within the Company. First Energy has integrated its AM/FM system to its Customer Information System (CIS), Distribution Transformer Inventory System (DTIS), Customer Trouble Call System (CTCS), Engineering Analysis Package, and Work Management System (CREWS). This paper will describe these integrations, the use of different rapid application development strategies, the reasoning behind using these strategies, the benefits and drawbacks of their usage, and the manner in which these interfaces have evolved and will continue to evolve.

Company Profile
First Energy Corp. is an electric utility located in central and northern Ohio and western Pennsylvania. It is the newly formed holding company for the recently announced merger between Ohio Edison/Penn Power and Cleveland Electric Illuminating Company/Toledo Edison (CEI/TE) which has 2.2 million customers inside its 13,200 square mile service territory.

The AM/FM project began with an eight-month pilot application in 1992. The Ohio Edison portion of the project is on schedule to complete at the end of 1998, and the CEI/TE portion should be completed by the end of 2000. As of October 1997, 800,000 of the 1,070,000 Ohio Edison sites (poles, pads, vaults) have been converted; conversion of the CEI/TE territory is just beginning. One-hundred-eighty users have been trained to use the system which they use for designing new construction jobs, dispatching, locating equipment, and spatial related reporting.

Interfaces
Before discussing the development approaches that are being used, the existing interfaces to the AM/FM system will be briefly described. The FirstEnergy AM/FM system is currently integrated to the Ohio Edison Customer Information System (CIS), the Distribution Transformer Inventory System (DTIS), an outage analysis system (Customer Trouble Call System - CTCS), an Engineering Analysis package, and a work management system (Customer Request Work Scheduling - CREWS). See Figure 1 below.

Customer Information System (CIS) and Distribution Transformer Inventory System (DTIS) The CIS and DTIS interfaces, in their earliest form, were created during the pilot application. These interfaces are a simple flat file extract of data from two legacy information systems which are on VSAM and DB2, respectively. The flat file is loaded into Oracle; then views and triggers allow the information to be viewed in AM/FM with its respective graphical features. The major advantage of this interface style is that AM/FM can utilize the information captured in the other systems, without maintaining the data in both systems. The information is used for navigating to the customer or transformer, tracing circuitry to obtain loads from the customer information, mapping automatically the medical or critical customers, and displaying information about the customer and transformer.

Customer Trouble Call System (CTCS)
The AM/FM data is also passed to the DB2 CTCS system. This interface currently uploads the customer and its first protective device relationship from AM/FM to CTCS. Thus, whenever new customers are added to the system, the information only has to be entered into AM/FM and is automatically updated to CTCS. In the future stages of the integration, the entire electrical path will be passed from AM/FM to CTCS, and CTCS will pass live outage information to AM/FM, which will be displayed graphically for the dispatchers.

Engineering Analysis
The AM/FM data is passed to an Engineering Analysis system via an Oracle extract. The circuit details, which are maintained in AM/FM, can then be utilized for analysis and design in the engineering analysis system.

Customer Request Work Scheduling (CREWS)
The AM/FM interface with the CREWS system is by far the most complicated. New work is passed to the CREWS system and these new jobs appear on AM/FM to be designed. The job is designed in AM/FM graphically; at the same time, compatible construction units from CREWS are picked to assist with the AM/FM attribute population, cost and labor estimates, and material ordering. Once the design is completed in AM/FM, it advances through various stages in CREWS (estimating, various approvals, scheduling, material ordering, closing). The work sketch from the AM/FM design is used in the field, the as-builts are posted to the job, and then the job is automatically made a part of AM/FM production database.

Rapid Application Development
There are numerous definitions and techniques for rapid application development (RAD). To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 26 hours at a stretch. To the information engineer, it is a combination of CASE tools, intensive user involvement, and tight time boxes. To the vertical market programmer, it is rapid prototyping using the latest version of Visual Basic or Delphi. To the manager desperate to shorten a schedule, it is whatever practice was highlighted in the most recent issue of Business Week (McConnell, 1996).

The bottom line is that software development needs to be done much faster than in the past, and a variety of ways are used to do this. This point is particularly true in the AM/FM/GIS industry because of the constantly improving technology. The utility industry must also change its approaches because of the increasing competitive environment. It is no longer sensible to spend 5-10 years gathering requirements, designing, coding, and testing a system before it is released to the end user. By that time, the technology that has been implemented is out-dated, the systems to which it has been integrated have changed, or the business processes have changed and then a new project must start over again. The following discussion will highlight the two approaches that First Energy has used to develop system interfaces, the benefits gained by bringing the project to market in a shorter time, and the disadvantages of these approaches.

Staged delivery

Definition
The staged-delivery model involves giving software to the end-user in successively refined stages; the software is not delivered at the end of the project in one fell swoop (McConnell, 1996). This model involves the development of the initial software concept, requirements analysis, and architectural design once at the onset of the project. Then the detailed design, coding, debugging, testing, and delivery phases are delivered to the end-user in stages.

A version of this model was used to develop the FirstEnergy interfaces between the AM/FM system and the CIS, DTIS, CTCS and Engineering Analysis Systems. The next section will give an example of how this model was used to develop the CIS interface, the benefits of this type of implementation, and its drawbacks. See Figure 2.

Initial Stage for the CIS Interface
The initial software concept for the AM/FM interface with CIS was that although the data had to be accessible it was not necessary to maintain all of this information in the AM/FM system, since the customer data was being stored and maintained in other systems.

The requirements phase involved deciding exactly what data would be needed for various AM/FM applications, how the data would be used, where the data would be maintained, and how current the data would be required. Various customer information was needed at the individual service points that were to be graphically converted. Particularly the customers’ load should be tied to these points to be used in load calculation tracing routines. Other applications, such as optimizing read routes, calculating revenue by feeder, marketing studies by demographics, etc. were brainstormed and the desired data in CIS was identified. It was not known how current the customer data in AM/FM had to be. It was decided that weekly would be good for starters and as the applications were developed the timing could be determined and adjustments made as necessary.

The architectural design was heavily influenced by the short amount of time needed to get a pilot AM/FM application developed and the even shorter amount of time that could be spent on the CIS interface due to vast number of other tasks needing attention. Other considerations were the state of client-server applications at FirstEnergy and the uncertainty of the future of the Ohio Edison CIS system. In 1993, Ohio Edison was just beginning to develop other client server applications, the corporate direction was Sybase, and infrastructure middleware between Sybase and mainframe systems was under review. The CIS system was not ready for the year 2000 and there was much discussion about rewriting the system in a client server technology. Thus, a simplified approach of extracting the data from the mainframe system and loading it into Oracle was decided, at least for the short term. The first stage delivered to the end user was simply an extract file from the mainframe loaded into Oracle and other applications were built around the data, but no automated methods were put in place to refresh the data.

Benefits of the First Stage
The first major benefit was that the entire AM/FM pilot application, with the CIS interface being a small component, was completed in eight months. True, the interface was premature and it would have to be improved in a production environment, but it proved to upper management the benefits of an AM/FM system, including how this open system could provide customer information linked to the map. It was a proof of concept which showed that other systems such as DTIS could be integrated like CIS. It also conceptually demonstrated the value of having all distribution data under one system and how AM/FM could be the sole source of accurate data for other systems such as Engineering Analysis and Outage Analysis.

The second benefit was that it pinpointed a major flaw in the conversion process that, if gone undetected, could have cost a tremendous amount of money and time with post data cleanup. By having the CIS data available as the AM/FM service points were being converted, errors in matching the address information were detected and thus corrected. Initial deliveries of data occasionally matched CIS data by as little as 5 percent. This meant that when you looked at a customer on the map in AMIFM, there was no CIS information tied to that customer and all of the applications relying on this information were useless. Refined techniques for preparing the paper maps and records were developed, which has allowed the initial data conversion matching to CIS to be improved to 93°/0 or more. Thus, only 7 percent of the data has to be corrected after conversion.

The third benefit was that the simple approach allowed the users’ to see at an early stage the possibilities of the system and the value of having all of the data in one place. Since AM/FM/GIS is a new technology and it is replacing manual methods, not all of the uses/requirements are always fully understood. The pilot allowed them to visualize how other applications could tie into this data and assisted with the conceptualization of these. Most importantly, it stressed to them the importance of accurately preparing the paper sources for conversion, particularly the customer address which was drastically overlooked with the first data converted.

The fourth implied benefit was that since this first stage of the CIS interface was already delivered, it allowed team members to work in other areas of the project.

Remaining Stages of the CIS Interface
The pilot application was approved by Senior Management; and with their approval the five year project began in 1994. At this point, the CIS data had been loaded once into Oracle. The second stage of the CIS interface was to set up both the mainframe and UNIX processes that would run the respective jobs once a week to keep the data updated. This stage was not delivered to the end users until late 1994. This was about the same time that the first end-users were being trained on the system.

The third stage was released in mid-1997. This stage was almost transparent to the end users, but it made the interface fault tolerant so that CIS would always be available. In the past, any error in the load process could cause the CIS data to not be available. The new programs developed incorporated error routine checking to guarantee that all of the new data would be loaded and the data would be available constantly.

The fourth stage will be released in early 1998. This was an unplanned stage, but it is necessary due to the merger between Ohio Edison and CEI/TE. First Energy decided that the CEI/TE CIS system would be the new First Energy CIS System. Thus, a new slightly modified extract file will be created from the CEI/TE CIS system. The Oracle loads on the AM/FM side will look identical; the only difference being that the data is coming from two different mainframe systems. This convention will allow Ohio Edison and CEI/TE data to be loaded on the same system until the conversion of all Ohio Edison CIS accounts move to the new system. The jobs are also being modified to refresh the data three times a week.

The final stage(s) are still under discussion. These could involve only getting updates of the CIS records, rather than the entire extract file or using a gateway to go directly against the CIS system to retrieve the data. No planned date is set for starting this stage because the loading of the data into Oracle has not caused any problems.

Benefits and Disadvantages of the Remaining Stages
It is important to note that the timing of the other stages’ deliverance was driven by the progress of the other phases of the project. With huge projects, like AM/FM/GIS, not all applications can be developed and delivered simultaneously. Decisions need to be made about the priorities. End users don’t always agree with this approach because they want everything; but in a vastly changing IS field without enough resources to do everything up front, some functionality is better that none.

An advantage of this staged approach is that the functionality is not developed prematurely. Had numerous development hours been spent developing an interactive interface to CIS, it would have been wasted effort because the Ohio Edison CIS system is being replaced and the development effort would have had to be redone. Much less effort is involved in a simple extract and load.

A disadvantage of this approach is the need to rewrite a lot of the load process to make it fault tolerant in stage 3. This will also be a disadvantage if and when the interface between AM/FM and CIS ever becomes interactive. But for the overall project, the benefits of the first stage being accomplished in a very short time frame outweighs the necessity to do it all the first time and that would also have been a wasted effort with the implementation of a new CIS system on a different platform.

Evolutionary delivery

Definition
Evolutionary delivery is similar to staged delivery, but it allows for more customer feedback during the actual development. It begins with the software concept, requirements analysis, and design of the architecture and system core. The architecture should anticipate as many of the possible directions the system could go as it can. The core should consist of lower-level system functions that are unlikely to change as a result of customer feedback. The next sequence of stages are done repeatedly until the customer is satisfied, the number of planned iterations is completed, or the project is out of time or money. These stages include: developing a version, delivering the version, eliciting customer feedback, incorporating customer feedback (McConnell, 1996). The following section will give an example of how this model was used in the development of the interface between the AM/FM and CREWS systems. See Figure 3.

CREWS Interface
As in the staged delivery model, the initial software concept, requirements analysis, and architectural design were done at the onset of the development cycle. However, much more consideration and study were put into the design because it required a live interface, numerous interface points, and a complex user front-end. The other difference was that rather than just designing, coding, debugging, testing and releasing the first stage to the end user, more user feedback was required during the detailed design and development phase.

The initial software concept was to streamline the process of designing a job and maintaining the maps and records. The job should only be drawn once and all engineering work should be done from it. The requirements phase involved defining the work flow and its various stages, deciding which portions of the work would be done in which system, and identifying the interface points. The design of the architecture and the system core was focused on how the data would be passed between systems at the various interface points.

The next portions of the development cycle involved an iterative cycle of developing a prototype and presenting it to the end user for feedback. First, a few screens used to explain the detailed design were presented to the user. The screens allowed the user to conceptualize how they would be incorporated into the system. The developers were able to revise their detailed design based on feedback from the users. Second, the functionality to add a feature by picking the CREWS compatible unit was given to the user for review. This functionality was developed first because the feedback that would be received from this stage would be beneficial in developing the editing and deleting functionality as well. The process of eliciting customer feedback for different functionality continued for the duration of the development cycle.

These iterations of delivering a version to a small user base, eliciting feedback, incorporating the feedback and developing the next version greatly assists meeting the users’ needs and reduces major rework. Mid-course corrections in functionality aren’t as costly if detected early before other functionality is built on top of them.

The design of this interface is also a key component. All of the interface code was written with APIs and kept separate from the core AM/FM code. Due to the constantly changing GIS technologies, revamping the AM/FM application to a newer technology is very conceivable. By keeping these APIs separate, they can be salvaged if the core AM/FM application is replaced.

This approach can be very costly if the team accommodates all user requests; and it can be argued that this approach takes longer than traditional development methods due to all of the cyclical feedback. Thus, proper planning and control mechanisms must be exercised by both the developers and users. The users must be available when feedback is needed and must do so in an expedient manner. The developers need to work on essential portions of the interface and keep lists of additional enhancements that could be incorporated into other stages. A fixed deadline and only utilizing a small group of key users also assisted First Energy in managing the scope.

Conclusion
It is important to note the reasons for using the different approaches. The more complex the interface between systems, the more up front architectural design and user involvement is necessary. The faster an application is needed, the less time can be spent on design and user involvement, but the reality of eventually reworking the application must be realized and the benefits/drawbacks weighed.

Before anything else, the thing that is most important is that the “1S and AM/FM/GIS worlds” are changing very rapidly and a balance in information systems development is needed. Go as fast as is possible with what is available, and don’t deliver the functionality too soon or too late. Each part must be seen as a whole to be developed, but with the realization that it is only a part of the final desired product.

References
McConnell, S., 1996, Rauid Development, 2-427.