Utility Industry Group Implementation Guideline for Electronic Data Interchange
4 |
Environments |
|
4.1 |
System Architecture |
|
| The graphic description of how the software and hardware are assembled to
support the needs of the user is called the system architecture. The system architecture
relates primarily to the needs of the end user rather than technique or technology. The
system designer, as with any other architect, must satisfy the user's requirement within
the constraints of serviceability and cost.
There are three basic EDI system architectures: Standalone Microcomputer: Outbound transactions are keyed into the microcomputer. Inbound transactions are transferred to an attached printer. Translation software (to/from ANSI standard) resides within the microcomputer. Communication software/ hardware handles both inbound and outbound transactions. Microcomputer/Minicomputer Front-End: The microcomputer serves as a front-end processor to the mainframe. The translation software (to/from ANSI standard) resides within the microcomputer. Mainframe/Minicomputer: All processing is performed within the mainframe. lnbound transactions are received by the mainframe, translated, and forwarded for further processing. Outbound transactions are consolidated, translated, and transmitted. Network communications hardware and software are under the control of the mainframe. With the addition of value-added network services, you can "mix and match" the basic architectures and let the network manage the complexity of different hardware/software. The networks provide the capability of indirect communications through the use of electronic mailboxes and support code, speed, and protocol conversion. |
||
4.2 |
Application Integration |
|
| Application refers to the current functional processes which may or may not be automated. To take full advantage of EDI, it should become part of the functional processes and not be an add-on. EDI will change the way you accomplish your mission. Planning for integration will reduce the impact of this change and allow a smooth transition to an environment which maximizes your return on investment. Total integration does not have to be achieved before starting EDI, but it should be an established goal. Failure to achieve integration will result in the attainment of some short term benefits, but the real benefits which come from increased automation will be unattainable. | ||
4.3 |
Translation |
|
| Translation is the automated process of translating the proprietary data into ASC Xl2 standard structure for sending and then reversing the process for receiving data. The core translation program uses "table driven" subroutines to generalize processing regardless of the actual application being processed. Specifications are taken by the program, depending on the data being processed and the particular tables associated with the transaction set. The ASC Xl2 standard provides a specific structure for the data. It does not affect the program design or the program function. As a consequence, there are many commercial software packages which provide "core translation" and other related functions that are designed to support different EDI environments. Their costs range from a few hundred dollars to one hundred thousand dollars. The decision to "make or buy" translation software must consider many factors; however, the availability of relatively inexpensive, proven commercial software packages supported by a growing industry should make development unnecessary. EDI software should be managed as "system software" rather than "application software". |