\documentstyle[guidemacros,psbox,changebar]{report}
\stdsizes

%include the below line for tty output.  Reduce to "-2" if excluding
%change bars.
%\addtolength{\textwidth}{-2.25in}


%\newcommand{\draft}[1]{{\huge #1}}

\title{Opportunity Evaluation of an Electronic Forms-Routing System}
\author{Andy Oakland}
\date{March 25, 1992}
\maketitle

\begin{document}

\section{Background}
An electronic forms-routing system could serve many purposes within the
MIT environment.  
\chgbarbegin
As a replacement or supplement for existing administrative paperwork, 
\chgbarend
it could reduce paper flow and redundant
data entry, and speed up the processing of forms.  
Within the software
and support communities, it could be used by
computing support groups to track user's requests, and by 
developers to manage bug reports.  

A forms routing system is something like a railroad.  Forms move through
the system just as trains move along railroad tracks.  When a form comes to
the attention of a user, he or she can do something to the form and then
select another user to send it to---just as the dispatcher at a station
can shunt an incoming train along a variety of outgoing tracks leading to
different stations.

Penn State's IBIS and EASY\footnote{
``Integrated Business Information System'' and ``Electronic Approval System''}
systems have been able to automate all of their student services,
such as admissions and registration, and many of the business systems,
including some financial and all personnel actions.\footnote{
``Presentation to Board of Trustees'', July 25, 1991, Edie Bender}
However, Penn State relies on an integrated database for all
departments--far from the present situation at MIT.  Given the lack
of such a database here, it is currently impossible to implement
as comprehensive a system as EASY.  Even so, an electronic forms-routing
system can act here as an adjunct to the existing information systems,
and still be of significant value.
In this paper, we present some first thoughts on the design of 
such a proposed forms-routing system for use at MIT.

\section{General Description}
A form in the system would appear on the user's screen as a depiction of
a paper form.  
\chgbarbegin

Although the form will be functionally equivalent to any existing
paper form, it's not guaranteed that it will look exactly the same,
as some features of a paper form may not have an exact electronic
equivalent.

The form will have text fields to
be filled in, some of which may be constrained to be of a certain
format (eg, dates; dollars and cents) and some of which would be free-form
text.  Other types of input fields, such as checkboxes and multiple-choice
selections, may also appear.  Eventually, an electronic
form may include types of input which have no paper equivalent, such
as pop-up menus and nested sub-forms.
\chgbarend

\chgbarbegin
Each type of form will have a unique route associated with it, 
which will consist of a 
collection of stops and a listing of which stops are connected to which
other stops.
In the railroad metaphor, a stop corresponds to a station, and the
connections between the stations represent the tracks.
The route for a form is
the collection of all the possible ``tracks'' on which this type of
form can travel.  Because the route may have forks in it, the paths
taken by individual forms of the same type may differ.
\chgbarend

At each stop, a person or group 
of people will be assigned ownership of the form, and be
responsible for ensuring that appropriate action is taken at this point
and the form forwarded to the next stop.  As long as the form is at this
stop, these people are said to ``own'' the form.

For example, an auditing program could generate forms containing a list 
of calls made from each office phone, and assign each form to the 
owner of the phone.  The program itself would own the forms at
the first stop on the route, and moving the forms to the second stop
would assign the forms to the phones' owners.

The phone's owner would mark off his personal long-distance calls, and send 
the form on to the third stop on its route.  The person responsible
for the third stop would likely be
the administrative officer for this person's department,
who would be responsible for collecting the necessary funds and archiving
or deleting the form once this was completed.

Certain fields could only be filled out during a certain stop.  In the
example above, marking calls as ``personal'' or ``business'' could only
be done when the form was at the second stop...Neither the auditing
program nor the administrative officer would be allowed to edit these
fields when the form was at ``their'' stop.  
\chgbarbegin
In addition, fields may appear and disappear as the form moves along
its route, if they are appropriate only at certain stops.
This would be the electronic
equivalent of the ``For Office Use Only'' section often seen on paper
forms.
\chgbarend

\chgbarbegin
\subsection{Expected features}
The following items are the main features we expect of an
electronic forms routing package.
\chgbarend
\begin{itemize}
\item The system should be accessable from a variety of machines, including
but not limited to, Athena workstations, Macintoshes, and 
\chgbarbegin
eventually DOS machines.
\chgbarend
Furthermore, it should be possible to use the system from machines which
are not directly on the Athena network, via telnet or dialup.  
\chgbarbegin
This requires that the system must be able to work with simple character-based
displays, such as the vt100, as well as on more sophisticated graphic displays.
\chgbarend
\chgbarbegin
\item It should be possible, at any time, to print out a paper version of
the form.
\chgbarend
\item The system must be secure.  At the simplest level, this means
that unauthorized people must not be able to corrupt
existing forms or read forms they should not be able to access.  
Beyond that, if the electronic forms are ever to be able to replace paper
forms, the system's records must be made nonrepudiable...i.e.,
if the system shows that someone made a particular
change, it's guaranteed that he actually did it.
Only the simplest level is likely to be implemented for the first version 
of the system.
\chgbarbegin
\item The system should maintain a modification history for each form.
At a minimum, it should record the identity of anyone who enters values
onto the form or moves it along its route.  It may also be desirable to
maintain histories of the values of individual fields within
the form, along with the identities of the person who entered or 
changed the value.
\chgbarend
\item At any given stop, the current owner may have several alternatives for
forwarding the form.
Sending it to the next stop will always be an option, unless the form is
already at a final stop on its route.
Other options, such as returning it to the sender,
referring it to someone else, or terminating it, will be available if
appropriate.
\item Tools will be available to allow non-programmers to design
forms and their routings, and to enter them into the forms database.
\chgbarbegin
\item Fields on a form will be somewhat intelligent.  They will recognize
what sort of data they should contain\footnote {At a minimum, data
types like text, numeric, and multiple
choice will be supported.  Formatted input, such as phone number templates,
may be added later.}
and will provide default values where appropriate.  In
the first implementation, these will be hard-coded for each field.  
In later versions, the
defaults may dynamically adjust depending on the values of other fields in 
the form, as well as the contents of the underlying database.

Furthermore, various attributes of each field, such as its visibility,
whether a value for the field is required, and
whether the user can change its value, will change depending on
the values of other fields or the current status of the form as a whole.
For example, a section asking for MIT office number might only appear
if the originator checked a box indicating that she was an MIT employee.
\chgbarend
\item It will be possible for a system outside the router to interact
with the routing system.  For example, if the router were to pass completed
forms to the personnel database as the last step in their routing, it should
be possible for personnel to tell the router that the forms are safely
archived and can now be deleted from the router's database.
\end{itemize}

\subsection{Open Issues}
\begin{itemize}
\item Must routes end with the form leaving the system?
Some useful applications, such as a bug-tracking system,
can run entirely within the forms system, and will not require an external 
department database to hand off to.
However, giving users the ability to write indefinitely into
the forms-router database can cause space problems, and forces the router
to act as a custodian of their data.  This is similar to what would happen
if users could expect the post office servers to store their mail for them,
instead of being required to incorporate it into their own directories.
\chgbarbegin
\item Should there be a single database for the entire form system,
or should individual projects have their own databases?  Maintaining a
single database simplifies the construction of the routing server, but
seperate databases will make it easier for individual projects to
maintain their own databases.
\chgbarend
\chgbarbegin
\item Should we allow administrative users to specify arbitrary 
\chgbarend
commands to be executed as forms enter and leave various states?
For example, this will allow people to get automatic notification of new 
forms as they arrive, or for the date any form enters a given state
to be logged in a global file.
However, there's no way to write arbitrary commands which will run
on all systems, and it introduces a gaping security hole.  
Furthermore, users may interpret any failed 
commands as bugs in the router, even through the router was only
executing a command specified by the person who designed the form.
Providing a library for common requests, such as email or zephyr, 
will suffice for many cases, but not all.
\chgbarbegin
\item At what point will the user-supplied values be checked for validity?
Some simple validation can be done as the values are input, but
full sanity checking of fields may have to wait until after the form 
exits the routing system.  Expecting the router to 
interact with many different databases in order to confirm the validity
of new data will probably be unrealistic.
However, users will expect some level of dynamic checking and validation of
fields, and providing this will provide a great incentive to use the
electronic rather than paper forms.
\chgbarend
\end{itemize}

\chgbarbegin
\subsection{Interface for the typical user}
The typical user will interact with the system via a single
client designed to make it as simple as possible to perform the
most common tasks.  This client will be accessible as widely as possible.
We currently plan to put it on at least Athena workstations and
Macintoshes, with a curses-based version available for dialup and
telnet purposes.

Using this client, the user can:
\begin{itemize}
\item Select from a variety of blank forms, and fill a new
form in.  Simple data verification will be run on the entries
(required/optional, correct data type for each field, etc.)
\item Display existing forms which he is allowed access to.
\item Manipulate values on a selected existing form, provided this user
has authority to do so for those specific fields at the form's current
stop.
\item Select the next stop and owner for a form he currently owns.
\item Query the forms database for at least:
\begin{itemize}
\item A list of existing forms with a particular owner.
\item A list of existing forms of a particular status.
\item A list of existing forms which he has originated or modified.
\item The current status of a specified existing form.
\item The routing and modification history of a specified existing form.
\end{itemize}
\end{itemize}
\chgbarend
\subsection{Administrative Tools}
\chgbarbegin
In addition to the main client, a collection of administrative tools 
will eventually be supplied.  These will include tools for:
\chgbarend
\begin{itemize}
\item Defining new form templates.  Modifying existing ones may not be 
possible, due to the problem of what would happen to forms 
using the old template already travelling in the database.
\item Defining or editting the routing for a new or existing form.
\item Running canned database queries, to list
all those requests of a specific type and with a due-date in the next 
month, all the forms in a certain state, and so on.
In addition, it would be useful to run arbitrary database queries
in a standard query language, although security problems may preclude
allowing this.
\item Manually editting fields on a form without any sort of constraint
checking, and forcibly moving forms to arbitrary stops on their route.
\end{itemize}
\chgbarbegin
\subsection{System Architecture}
We expect that the system will consist of a centralized server,
to maintain the database and control access to the forms;
and a client for each supported platform, which would present the forms
on the user's screen and provide the means for the user to edit the forms.
Users not on supported platforms would access the system via telnet
to a client which uses a character-based interface.

A command-line or other non-graphical interface should also be supplied,
so that shell scripts and other programs can interact with the router.

Administrative clients for relatively infrequent tasks such as designing
new forms will eventually be added.  However, we expect that these
tasks will be done manually with ad-hoc tools in the early phases
of the system.
\chgbarend
\section{Automatic Routing of Forms}
Forms will often ``know'' where to go when they have been completed.
While it's impossible to imbed the entire structure of MIT responsibilities
within an application,
the router would be able to make informed guesses.
In the Penn State EASY system, this is done with pre-defined tables.\footnote{
``Presentation to Board of Trustees'', July 25, 1991, Edie Bender}
At MIT, the definition of a form
could contain a list of people or groups responsible for
this type of form at each stop.  Thus, after a user completed
a form of type ``IP address request,''  the router could assign it to 
the person or group designated as being responsible for this type of form 
at the next stop.

However, this name would appear only as the default value for the
``Assign to:'' field of the form, and could be overridden by the person 
filling out the form.

Whether such a user specified name is valid cannot be
checked by the router.   For many important forms, the ACLs are 
based on data and rules which this system will be unable to cope with, 
such as ``This form must be signed by your manager, AO, or PO.''

\chgbarbegin
\section{Support for Administrative Systems}
At the present time, many MIT administrative systems are based on an old, 
\chgbarend
centralized, model of computing.  Updating of the databases is done either 
as a batch process (reading in a tape from another system) 
or manually (keying in data from paper).

We would like to move toward systems which are more interactive.
Providing end-users the ability to interact in real time with the system
would be tremendously useful...For example, after you entered a request
into the system, you would be able to query the system for the status
of your request whenever you liked.
Also, by eliminating the slowness of routing physical pieces of paper
though campus mail, users will be able to get their work done more
quickly.  The existing EREQ system is a good example of this.

One way of doing this is to build it into the design of each new system,
as departments replace their existing ones in the natural course of
business.
\chgbarbegin
Unfortunately, since most departments 
\chgbarend
have systems completely incompatible with
an interactive transaction-based approach, and have so much already
invested in their current information systems that replacement of
them would take perhaps fifteen years, this doesn't seem feasible.

One factor in resistance to interactive systems
is the possible security threat 
posed by having administrative databases accessable over the net.
Reviewing bug reports doesn't require a high level of security, and
the consequences of an unauthorized person moving them through the
network would be minimal.  However, when the system is used for
more critical information, such as voucher approval, it is necessary
to incorporate some form of ``digital signature'' and table of
authorized users to ensure that only
the appropriate people interact with the database.  Furthermore, it
is important to be able to track the path of a form through the
system, and determine with certainty who did what, and when.

\chgbarbegin
Athena-created services such as Kerberos, and the ongoing work
on privacy-enhanced email, should provide mechanisms for
supporting whatever level of security is required.
We believe that this electronic form system will be able to supplement
the existing administrative systems, and that it will provide an
effective migration path towards more interactive systems.
\chgbarend

\section{Applications Existing Entirely Within the Router}
It would also be possible to build some applications which have
no existance other than as a collection of forms in the system.

For example, the Help Desk needs to be able to track and report on three
types of requests, namely
problem/trouble reports, 
network installations, and
IP address assignments.\footnote{
``Help Desk Database'', April 12, 1991, Joanne Costello}
A collection of forms and routes within the
electronic forms-routing system would suit their needs perfectly.  Note
that this is a case where there would be no outside database for the
routing system to interact with...The entire application would be defined
within the system.

Bug reports for Athena software are currently kept in the memory
of the programmer, in flat files, or, in exceptionally organized cases,
in discuss meetings.  There is no mechanism for filing bug reports,
running queries to see what bugs have been reported, or for ensuring
that bugs aren't forgotten about.
Again, a set of forms for reporting bugs could be arranged within the
forms-routing system.

\section{Further expansion}
An obvious limitation of this system is that it cannot route physical
objects such as receipts.  In addition, there are more complex
electronic objects which should be considered for inclusion in the
system, such as voice mail and scanned images.

\chgbarbegin
It must be possible to spawn child forms from an original form,
though this may not be implemented in the first version.  For example,
it's likely that a request for a network drop will be split into
several different forms, one for each subtask required.
\chgbarend

It would be worthwhile to ensure that the system can interact with email
and other forms of electronic communication.  For example,
mail sent to a specific mailing list could be examined, and if it
fit a predefined format, would be used to fill in (at least partially)
a form of a specific type.  The form would them be assigned to the
designated screener for the mailing list for further work.  The system
should also be able to initiate communications...sending zephyrgrams when a 
new form arrives is one example, as is sending reminder mail when
a critical form has been untouched for a certain time.

\section{Conclusion}
Constructing an integrated administrative system such as Penn State's
ISBS is not currently possible at MIT, 
due to the fragmentation of administrative information and databases.
But although we cannot immediately eliminate all administrative paperwork,
we {\em can} provide a forms-routing system with sufficient 
generality that it can serve as
a path towards this ultimate goal, while being a tool of significant
and immediate use in other areas of the university.

\chgbarbegin
The next step in this project is to identify some potential users of the
package and find out what they expect from an electronic forms system.
This work has already been begun.
We plan to use their expectations and requirements,
research into similar systems,
and our own beliefs as to what will make the system most generally 
usable, to chart the further design of the system.
\chgbarend
\end{document}