Beyond Electronic Forms: E-Mail as an Institution-Wide Information Server Copyright CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear,and notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To disseminate otherwise, or to republish, requires written permission.For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu BEYOND ELECTRONIC FORMS: E-MAIL AS AN INSTITUTION-WIDE INFORMATION SERVER by Carl Jacobson ************************************************************************ Carl Jacobson is Director of Management Information Services at the University of Delaware where he has worked for the past fourteen years. Management Information Services has responsibility for acquisition, development, and maintenance of administrative and library systems. Mr. Jacobson's recent emphasis is on expanding the boundaries of the University's administrative systems beyond the realm of administrators to students, faculty, researchers, high school students, and parents. ************************************************************************ ABSTRACT: At the University of Delaware, faculty, staff, and students-- the "secondary users" of administrative systems--had traditionally encountered many roadblocks in their quests for information from administrative databases. Users of "academic" machines had little desire to log on to "administrative" machines and to navigate through applications, menus, and display screens for occasional access to small amounts of narrowly defined information from a diverse collection of institutional data. In response to this challenge, Delaware developed an intelligent mail server to provide easy, inexpensive access to institutional information for users on any node, any machine, or any operating system on the campus-wide network. Following years of substantial growth of our central computing resources, the University of Delaware entered the 90s amid calls for budget restraint, improved "customer" services, and the distribution of increased responsibility to academic departments. The institution began the decade under the leadership of an enthusiastic and progressive new president, David P. Roselle, who urged all members of the campus community to "do more with less." Perennial mainframe growth was capped, while aggressive expansion of the campus network continued. With the legacy of mainframe development at our backs, and budget retrenchment in our faces, we looked to the promises of networking, downsizing, and client-server computing on the horizon. To take immediate steps toward this promised future, Delaware chose to leverage existing resources in a unique way to quickly deliver improved information services to faculty, staff, and students. Administrative systems at Delaware By tradition, convention, and design, administrative systems at the University of Delaware satisfied the needs of the primary campus processing offices: payroll, registrar, general accounting, and others. In turn, these offices provided services to their institutional "customers"--students, faculty, researchers, and administrators. With the business climate calling for increased customer service during a time of fiscal restraint, administrative systems needed to be redeployed, targeting the needs of the "customer" more directly. The registrar's office provides administrative services relative to student records. Students receive grades and transcripts, faculty expect course rosters and classroom assignments, administrators request classroom statistics and enrollment demographics. Automated systems had been developed to enable the registrar's office to deliver these services. But expectations of these systems changed and the registrar was no longer asking, "Make systems to help us take care of the students when they come to the counter." The refrain became, instead, "Make systems to help the students without their having to come to the counter." Of course, these changing requirements were not limited to services provided to students. Faculty and administrators made similar demands on the registrar. And, in fact, it was not the registrar alone facing this challenge; it was shared by financial aid, public safety, food services, billing, housing, and many other campus departments. While this collection of administrative systems was carefully integrated, and network access was provided to all processing offices, and campus-standard terminals and workstations were installed, the computing needs of faculty, students, and researchers were met on different platforms on various networks using a variety of terminals and workstations. Thus a large collection of valuable institutional information was segregated from "academic systems" and their users. The vision of a seamless, integrated environment providing all members of the campus community with effortless access to a valuable storehouse of institutional information was clear. The effort necessary to realize this goal was substantial. With tight budgets, our need to move quickly toward this goal led to an examination of existing tools and technologies to identify solutions to satisfy some, if not all, of the requirements set forth by this vision. As the first step toward this goal, a charge was adopted to: deploy existing information resources from all administrative systems to all users using a common user interface providing a single system image quickly and at a low cost! Electronic mail as an integrator At Delaware, word processing and electronic mail were the most commonly used applications and e-mail was the only application crossing all network boundaries. And while e-mail user interfaces differed from one platform to another, e-mail was the "most common" user interface. Although each e-mail system had a unique user interface, each was a familiar, well-used interface. These systems shared common e-mail metaphors such as inbasket, outbasket, and file folders. While the details of the e-mail interfaces differed from system to system, every campus user was familiar with at least one e-mail system, and all campus users were routinely familiar with the e-mail metaphor and general e- mail concepts. This, in effect, provided a "common user interface" enabling electronic mail to deliver a useful level of apparent system integration. E-mail systems existed on every campus mainframe, minicomputer, or local area network. Various network gateways allowed communication among these systems. Campus e-mail systems reached further into the campus community than did administrative information systems. Such system penetration was exploited to help address issues of information isolation. Existing facilities met four of our six objectives: * e-mail existed on all systems, reaching all users, * e-mail provided the most common user interface, * network gateways presented the appearance of a single messaging system, and * existing tools allowed for rapid, inexpensive deployment. * The development of an electronic mail server met the requirements of the remaining objectives. * Much as the listserv software automates the management, access, and distribution of electronic mail messages across the BITNET network, Delaware's electronic mail server automated the access to and distribution of institutional information across the campus network. E-mail server On one hand, electronic mail systems spanned the campus-wide network, providing basic messaging services to all campus computing users. On the other, administrative systems spanned the institutional databases providing access to a valuable information resource. Delaware's simple e-mail server was implemented to merge these two existing resources to create an effective information system. The e-mail server is capable of * receiving e-mail requests, * determining what to do based on the content of requests, * providing necessary interfaces with institutional databases, and * preparing e-mail messages for subsequent delivery. * While listserv message managers use a command syntax to enable users to communicate with the server, our institutional mail server uses position sensitive electronic forms, or templates, to provide this capability. For this reason the e-mail server is commonly called the "electronic forms agent." At Delaware, we developed the electronic forms agent on the "administrative" mainframeto provide the closest possible interfaces with administrative databases. As these applications migrate to network-capable databases and client-server platforms, the physical location of the agent programs will be of lesser importance. At the time of development, the e-mail package used on the administrative mainframe was the EMC2 mail system from Fischer International. Software AG's ADABAS database system managed the administrative databases, while the Software AG programming language, Natural, was used to develop administrative applications. A network gateway had been installed with the EMC2 e-mail system allowing mail to be exchanged with other campus e-mail systems. The EMC2 product provided a forms feature allowing fill-in-the- blank forms to be designed for use by EMC2 users. Most other campus mail systems did not provide specifically for forms. In these cases, "templates" may be manipulated using e-mail editors, or forms "front ends" are used to provide for more control over the forms editing process. While campus e-mail systems provided the user interface and transport mechanism for electronic forms, the forms agent was developed to control the distribution and routing of these forms and to provide interfaces between the forms and official institutional databases. The agent was developed using the programming language Natural. A series of Natural modules serve as the generic agent providing an interface with the e-mail system. As the processing rules for each form are unique to that form, separate application interfaces were developed to meet the requirements of each form. See the sidebar for an explanation of the techniques used in our system. Applications Six classes of application have been identified. This somewhat arbitrary classification helps in understanding the capabilities of the e-mail server. Some applications are complex, while others are simple. In fact, some are so simple they can be accomplished without the use of an automating agent. However, an agent can bring additional functionality to such applications. The six classes include form distribution, request for information, request for service, authorization required, data capture, and automated notification. Form distribution Counselors in the office of the dean of students complete an academic withdrawal form when a student decides to leave the University before graduation. The form requires no further approval, that is to say, no one can deny the student's intent to withdraw. However, the form is distributed to notify eight departments of the withdrawal. This is an example of the simplest class of application, form distribution. While a full-function e-mail system can be used to implement most form distribution applications without the use of an electronic forms agent, an agent may add value to the form during distribution. Form distribution applications accept an electronic form and deliver copies of that form to members of a distribution list. The agent may append official institutional information to the original form during this distribution process. For example, a student's outstanding liabilities might be added to an electronic withdrawal form as it is being distributed to administrative offices. An electronic agent could go one step further and pass the withdrawal information directly to an institutional database to update an official University record. Request for information Applications classed "request for information" are quite common. An electronic form is submitted by a requester calling for the agent to compile information from official institutional databases. The agent prepares and formats the information, places it in an "electronic envelope," and sends it across the network. In this manner a faculty member working on a Unix-based "academic" machine may request student transcripts from the MVS-based "administrative" machine. Class rosters and grant balances are examples served by this class of application. This example may be seen as a precursor of a true client-server approach to information access. The Unix mail system acts as the "client" providing the user interface and structuring each query. The campus e- mail network acts as the transport mechanism between the "client" and "server," while the formatting rules of the electronic agent provide the client-server protocol defining the parameters for communication between "client" and "server." The "server" is found in the electronic forms agent and corresponding application interface, accessing the institutional databases, extracting requested information, and formatting each reply. A clear understanding of this analogy provided Delaware's information services staff with a valuable introduction to the concepts of client- server methods. Furthermore, this understanding also has provided the groundwork for the future migration of electronic forms from e-mail to true client-server platforms as they become available. Request for service An electronic request for service is similar to the request for information. However, instead of requesting information from University databases, these forms are used to request services from University departments. And while e-mail alone may satisfy these requests, a forms processing agent can provide interfaces with institutional databases. Inter-library loan requests, textbook adoption forms, and workorder requests all fall into the category of "request for service." Authorization required Electronic forms requiring authorization are among the most complex applications. Routing rules must be established, stored, and maintained to provide the agent step-by-step work flow instructions. Routes may be pre-specified and stored in tables or in the records of institutional databases. Routes may also be determined "on the fly" based on work flow rules processed by the agent. "A purchase requisition for hazardous materials must be routed to Occupational Health for approval" is an example of one such routing rule. Three personnel forms exemplify different levels of routing complexity as they might be addressed by an e-mail agent. The personal information form allows employees to change certain datafields in the institutional payroll/personnel system. Home address, phone number, and emergency contact are examples of information that can be changed at the discretion of each employee. The form requires no further approval and is routed directly to personnel system update programs. The personal data form, however, contains fields that can only be changed with the approval of departmental personnel representatives. This form may be submitted by any employee, but is routed for departmental approval before reaching the system for update. The personnel action form allows changes to payroll information and cannot be submitted by the employee. Rather, the departmental representative submits this form, and the agent's routing rules send it on to the appropriate dean or director for subsequent approval and to the personnel office for final approval before entering the system. Data capture There are occasions when electronic forms are used to collect and format data to be posted in institution databases. If these applications don't require the complex routing rules of the "authorization required" class, they fall into the category of "data capture" forms. An electronic form prompting department users to provide campus events information for a campus-wide electronic calendar exemplifies this class of application. The form prompts the user for formatted information, the electronic agent validates the completeness and correctness of the provided information and may return the form for editing if the data have not been correctly submitted. A simple authorization step may also be added to data capture forms. Automated notification While most electronic forms actions are initiated by individual users, one class of application is initiated by application software. These "automated notifications" allow applications to send e-mail notifications to members of the campus community. The simplicity of these applications makes this a good entry point for those wishing to develop e-mail-enabled applications by exploiting existing e-mail capabilities in the delivery of institutional information. A summary report listing University donors of large gifts, automatically prepared and delivered to the University president, is an example of an automated notification. Security and other limitations There are four general security concerns associated with electronic mail: authenticity, integrity, confidentiality, and non-repudiation. Authenticity provides proof that the apparent sender of a message is, in fact, the sender of the message. Message integrity guarantees that the message has not been changed since it left the sender. Confidentiality assures that the message cannot be intercepted on route from sender to receiver. Non-repudiation indicates that the sender cannot deny having sent the message. Most electronic mail systems today do not address all four concerns and, therefore, information systems based on e-mail do not easily deliver the highest levels of security. However, until vendors of e-mail systems incorporate digital signature technology into their products to provide better authenticity assurances, effective e-mail agents may still be built based on the following assumptions. * Many electronic forms applications do not require high levels of security. * Many current information requests are made by telephone or paper form, methods which do not provide high levels of security. * Electronic mail messages sent to the agent may be forged. * Electronic messages sent by the agent are correctly delivered to intended recipients. * Those who can intercept campus e-mail messages in route can also intercept information from other administrative applications using the network. Application strategies can be developed based on these assumptions to deal with many security concerns. The "round-trip" nature of electronic forms transactions provides for several such strategies. If a student submits a forged "request for transcript" and the processing agent is fooled into thinking this is a valid request from the professor, the agent will send the transcript to the professor, not the probing student. The professor, while not making the request, does indeed have permission to access this information and the student's attempted breach is unsuccessful. The electronic form round trip can also be used to develop other authenticity strategies: Post-Event Audit. An electronic agent can deliver a notification of change providing the data owner with a record of changes made, and giving the owner an opportunity to repudiate. Pre-Event Approval. The agent can return a submitted form to a data owner requesting confirmation prior to processing an update. Request To Make A Change. If necessary, the agent can require a data owner to request a "turn-around" form, populated with current field values, and delivered by the agent. Only upon receiving the returned form would the agent process an update. The agent's master database provides a degree of security by storing all original electronic requests. Upon submission of an electronic request, the original form is assigned a certification number, time-stamped, and stored in the agent's master database. From this point on, all versions of the form are routed through the agent and built from this database. Any unexpected changes to a routed form are effectively erased as the agent rebuilds the form before the next delivery. Additionally, if the certification and time-stamp information has been altered on the returned form, the transaction is rejected. The certification and time-stamp information is known only by the agent and each approver. Approvers must return to the agent an unaltered electronic form in order to complete the approval process. Finally, a complete audit trail is maintained logging each step taken by an electronic form as it makes its way through the work-flow chain. In addition to security concerns, there are other limitations to e-mail- based information managers. Alternative procedures must be used when handwritten signatures are required. Most e-mail systems today cannot respond when a collection of paperwork must accompany a form on an approval journey. Finally, when there are many members of the campus community who are not attached to the campus network, electronic mail loses its effectiveness. Costs Existing e-mail systems effectively bridge a growing, campus-wide network. Existing administrative systems span a diverse collection of institutional information. An electronic forms agent can merge these two valuable campus resources at a low cost. An agent with basic functionality can be developed in a matter of weeks. Each application requires the development of an interface with the agent. The effort required for such interfaces differs according to the complexity of the application. Simple interfaces can be developed in a matter of hours. Complex applications require several months of analysis and coding. As the application interfaces are primarily collections of institutional rules governing paperwork flow, analytical requirements usually outweigh the coding effort. Delaware's IS toolset With the implementation of a central electronic forms server and an accompanying set of generic development tools, e-mail-enabled applications have become a routine part of Delaware's application development strategy. Programmers, analysts, and application designers are free to exploit campus e-mail capabilities to revive existing administrative systems and to provide new campus information services. The existence of Internet and facsimile gateways for campus mail systems provides these application developers with the tools to extend the reach of the institutional information resource beyond the bounds of campus to businesses and other institutions. The emergence of e-mail clients for DOS, Macintosh, and Unix workstations allows these developers to build forms front-ends to take advantage of local spreadsheet, database, and word processing applications. Conclusions Vendors of e-mail systems, groupware, graphics-based forms- processing packages, and database management systems are beginning to consider the potential of complete forms-automation systems. As work- flow processing agents begin to be employed, electronic mail will play a more important role on our campuses. An automated mail processing agent can provide a useful level of integration of campus information resources. Existing resources found in administrative systems, institutional databases, electronic mail systems, and the campus network can be easily combined to provide more universal access to valuable institutional information. Delaware's unique application of existing technology returned immediate benefits against a small investment, while positioning the institution for the arrival of the more aggressive technologies associated with downsizing and client-server computing. ************************************************************************ TECHNIQUES EMPLOYED Inbox An inbox was established within the administrative mail system to receive all electronic forms. Program code was developed to monitor this inbox and extract e-mail messages (forms) upon their arrival. Each extracted form is passed to the work flow agent for processing. Form Parser The agent identifies the form and passes it through a parser to strip data from the form. Each form is defined in a dictionary containing rules for parsing and data validation. The data are placed in the agent's master database and control is passed to the proper application interface. Application Interfaces Application interfaces may (1) perform additional data validation, (2) return error or warning messages, (3) extract information from institutional databases, (4) pass data to update programs for eventual update of institutional databases, and (5) determine distribution lists and routing paths for subsequent form routing. Form Builder When the application interface determines the "next step" in the work flow process of a form, the form itself is rebuilt, moving the data from the agent's database onto a blank form. An audit trail, maintained by the agent, is appended to the form. Outbox Once the agent has completed the rebuilding of a form, it is placed in an e-mail outbox for subsequent delivery. ************************************************************************