OneStart/EDEN – A
Description of IU's Transaction Processing/Recordkeeping Environment
Electronic Records
Project Archivist
Indiana University
Archives
August 26, 2001
Introduction
During
the last few years we have been hearing a lot about web portals and the
information and services they provide to their users.[1] According to Eisler in an article on portals
in higher education from Syllabus Magazine,
A
campus portal may be defined as a single integrated point for useful and
comprehensive access to information, people, and processes. While portals have a rapidly evolving set of
features and characteristics, they can be described as both personalized and
customized user interfaces providing users with access to both internal and
external information. Portals can be
used for a variety of activities which generally fit into three main categories
– gateways to information, points of access for constituent groups, and
community/learning hubs.[2]
With
their proliferation into all aspects of life, how can we, archivists and
records managers, leverage them in our efforts to capture, maintain, and
preserve electronic records (ER)? At
Indiana University we have been exploring their use as part of the second phase
of the IU Electronic Records Project. I
have been involved with the design and implementation of IU’s campus portal,
OneStart[3],
and the shared infrastructure, EDEN (Enterprise Development ENvironment), that
provides services to member applications.
Background
In
1998, Indiana University released its five-year Information Technology (IT)
Strategic Plan.[4] Among the recommendations and proposed
actions were the replacement of several enterprise wide applications and the
re-engineering of other legacy applications to web-enable them. Also, like many other colleges and
universities, IU is implementing PeopleSoft’s Human Resource Management System
(HRMS) and Student Information System (SIS).
The implementation of these software applications provided an excellent
opportunity to integrate all of the enterprise applications at IU. The integration plan involved a
transaction-processing environment that would provide access to these
applications through a coordinated, unified front end and an infrastructure
made up of components that would be shared among applications including a
workflow engine and a global inbox for administrative messages.
The
requirements gathering began in March 2000 with a Joint Application Design
(JAD) session involving IT developers and managers and representatives of
several key functional areas including Human Resources, Timekeeping, Student
Information, Financial Management, Accounts Payable, Purchasing, Electronic
Research Administration, and the Indiana University Information Environment. From this session and additional meetings
with these functional areas during the summer of 2000 a vision for the portal
emerged. It would provide a unified
front end to IU services with single sign-on and authentication and 24x7
availability, role-based customization, usability-tested personalization
features, application integration, an adaptive user interface, and a completely
user-centered environment. It would
also make use of a component-based design (CBD)/Web services methodology and
standards approach. This approach
allows for the development of a shared infrastructure.
OneStart
can be referred to as a “next generation” portal since it is more than an
information portal. Not only is it
flexible and responsive to change, it utilizes a distributed model for content
creation. OneStart provides the
framework for others to publish their services and content. The first iteration of OneStart, a pilot for
staff terminal services users, went live on May 11, 2001. A second iteration with some additional
functionality and a new interface was released August 23, 2001.
University
Archives Involvement
Where
does the University Archives and recordkeeping fit into OneStart and EDEN? In the initial proposal submitted to the
National Historical Publications and Records Commission (NHPRC), the project’s
goals in regards to the new PeopleSoft systems were to establish recordkeeping
requirements and metadata specifications, create business process models,
identify records, and incorporate the requirements and specifications into the
systems. Around the time I began
working on the ER project in April 2000, the director of the PeopleSoft
implementation thought our efforts would be better directed towards the new
transaction-processing environment. Her
feeling was that records would be created, modified, or deleted by users using
forms presented through the portal.
These forms would then use the workflow engine for routing and approval
before updating the PeopleSoft tables.
We jumped at this opportunity since this environment would allow us to
also capture records created by other applications utilizing the workflow
engine. Ultimately, our goal is to
build into the EDEN workflow engine the mechanisms for capturing records along
with all relevant metadata as they are created and for directing records to the
records management system.
Since
May 2000, I have been an active participant on the OneStart/EDEN core
development team. Recordkeeping is
viewed as both a separate application that will eventually be integrated like other
enterprise applications and as a set of requirements that the portal, workflow
engine, and other components need to incorporate. During the requirements gathering stage, I worked with smaller
teams concerned with document creation and workflow. I explained our current versions of the functional requirements
for recordkeeping systems and metadata specifications and worked with the teams
to incorporate these requirements.
During meetings with functional areas, I also was able to help flesh out
requirements related to specific application records and data management
needs. During this process I did a lot
of educating on the importance of electronic records management and received a
basic understanding of the technical concerns the other team members had to
consider.
In
addition to working with these two teams, I was also a member of the
development methodology team. As part
of the NHPRC project, we have been pushing the need for business process
modeling in every arena currently available to us in the university. By participating on this team, we have been
able to help shape the development methodology that OneStart, EDEN, and,
hopefully, other new applications will use during the analysis and design
phases of their development. Since the
portal project is ongoing, the methodology is a living document that is
reviewed at the end of each iteration of the application. Focusing on the business requirements and
defining the business processes or functions is key in this methodology. This will help identify the requirements
needed for the application. These
requirements are then mapped to business objects and usage scenarios. The business objects are then mapped to
components or services. It is important, however, to avoid implementation
details during this process. This is
the most difficult aspect for many programmers since they want to jump in and
start coding. Specific tasks such as
use cases, sequence diagrams, and class diagrams that are found in the
methodology are based mainly on the Unified Modeling Language (UML).[5]
From
Fall 2000 to Spring 2001, I continued to work with the portal developers first
writing use cases then helping turn the use cases into a portal prototype
designed to test the feasibility of some of our requirements and for usability
testing. I continued to provide as much
technical assistance as I was able including helping with screen design and
proofreading sequence diagrams. Once
the programmers began coding, I switched to working again on the workflow
engine, which had been delayed due to a lack of personnel. We began a new round of interviews with
functional areas such as Purchasing to make sure that the requirements
previously gathered were still valid and to see if there were requirements that
were missing. We also began developing
a new conceptual design for EDEN, explained in more detail below.
Current
Conceptual Design
As mentioned previously,
OneStart and EDEN are being developed using component-based development.[6] A component is a specific piece of enterprise
functionality that can be reused in future development and integration. As you
can see in the diagram below, some of the components that are part of EDEN
included a workflow engine, recordkeeping, security, and an inbox. A key difference between components and
objects is that components clearly separate specification from implementation
allowing for easier reuse. Components
also have published interfaces that should be independent of their
implementation in order to facilitate integration.
A component-based approach has several benefits. First, it creates a repository of reusable business functions
that also allows for the replacement of specific functions without affecting
the rest of an application. Secondly,
it aids rapid application development by assembling existing components and
services. Thirdly, CBD can improve the
agility, flexibility, and scalability of an application. Finally, as long as components agree upon
the protocol to be used (the language and the subject being talked about), an
application does not have to reach into another application's database for
information. They only interact through
their published interfaces.
Workflow
is "the automation of a business process, in whole or part, during which
documents, information or tasks are passed from one participant [human or
machine] to another for action, according to a set of procedural rules."[7] What we are calling a workflow engine is the
software that facilitates that automation.
As Chen notes in “The Paradox of Digital Preservation,” a recent article
in Computer, a journal of the IEEE Computer Society, “Starting from
creation and ingestion, we should integrate the workflow process with the
preservation process: appraisal, verification, maintenance and, eventually,
retirement.”[8] At Indiana University, we are attempting to
do this by utilizing the workflow engine.
What follows is a very high level overview of the engine and its
potential for electronic recordkeeping.
When
the IT community and functional areas at IU talk about the e-docs that will be
routed by the workflow engine, they are generally referring to electronic forms
that are connected to database records.
These electronic forms are much like the traditional paper forms they
replace. E-docs generally do not
include other file types such as scanned images although the engine will be
able to accommodate these. The workflow
engine will route e-docs for activities such as completion, approval, or
notification.
The
diagram below illustrates the current conceptual design for EDEN, the workflow
engine, the inbox and recordkeeping.
Since this is conceptual, very little concerning implementation will be
discussed. Also, as far as EDEN is
concerned, OneStart is just another application like the Financial Information
System (FIS) or the Human Resources Management System (HRMS). However, it does have a special relationship
since the portal is the user interface for the inbox and other EDEN services. For this reason, OneStart has been set to
the left of EDEN rather than grouping it with the other applications.
The
best way to explain the rest of the diagram is to use an example involving a
document from the HRMS. The HRMS will
have a component that represents a particular document type such as a Personnel
Action Form (PAF). The system will
register routing rules with the workflow engine on how the it should
route. The workflow engine routes an
XML representation of the document from node to node through the business
process. The HRMS owns the data and is
responsible for its storage and management.
However, the workflow engine does tell the HRMS how that should be done
in order to maintain the document's route.
All communication between the HRMS and the workflow engine is conducted
between their respective interfaces.
The
process begins when someone initiates a PAF for a new employee named Joe in the
HRMS. Whether Joe's PAF needs to be
routed to another node for completion or is ready to begin the approval
process, the HRMS sends a representation of the document to the workflow engine
when it is ready to be routed. The PAF
undergoes a discovery process to find the node where it needs to stop next
based on the routing rules mentioned above.
Nodes will have an associated inbox, which may be for a person, machine,
or another process. In this example,
the document is sent to a person's inbox by the workflow engine as represented
by the red line in the diagram. After
the employee selects Joe's PAF from his or her inbox, the workflow engine will
call on a HRMS component for a representation of the document. The component will request the workflow
engine to check the status of the PAF (the document's state and what actions
can be taken) and will then provide a representation of Joe's PAF that is
displayed through a OneStart channel.
After whatever action is taken, the discovery process begins again until
the PAF reaches its final node.
In
this conceptual design, recordkeeping functionality would be added by including
a recordkeeping node. To capture the
document when it becomes a record or evidence of a transaction, routing rules
could direct the document to that node.
The attached inbox would have a conduit (the orange line in the diagram)
that passes the document into a recordkeeping system or repository to be
managed. Each document in the
recordkeeping system would include the metadata attached at its creation in
addition to all metadata gathered whenever it is routed through the engine. Since the record has been captured as part of
its associated process, we can be assured that the metadata also contains all
of the appropriate contextual information that may be missing if captured at a
later date.
At
this time, IU does not have, nor plans to have any time in the near future, a
document management or recordkeeping system.
Having identified a means for capturing records from the various
university systems, we are now exploring a partnership with the Indiana
University Information Environment (IUIE), which is IU's data warehouse, in
order to provide a repository for these records. This is a fairly new and exciting effort that would allow us to
make use of existing university resources.
Conclusion
So,
where does IU’s portal efforts fit in with those at other colleges and
universities? Several schools have
developed or are developing portals but their numbers are still few. Most of the portals are simply information
portals without the middleware such as an integrated workflow engine. Some of the universities with more developed
portals are just now talking about adding this middleware layer. Also, IU is taking a unique development
approach. Instead of the portal content
being created by the portal team as Minnesota and Texas have done, content
creation will be distributed across the IU campuses and offices.
I
currently do not know of any college or university that is trying to
incorporate recordkeeping into their portal and shared infrastructure like we
are proposing at IU. If there are
colleges, universities, or corporations out there that are developing portals
with the infrastructure that we have described, we would certainly like to hear
from you.
Finally,
some archivists and records managers may question the value of becoming
involved in aspects that are not exactly related to electronic
recordkeeping. However, using my skills
set in ways that help others makes them more likely to help us as we try to
implement electronic recordkeeping practices at IU. It is by forming partnerships and sharing resources that we can
continue the work that we have begun with the grant money from NHPRC. This is key to ensuring that the
University's electronic records are captured and then maintained throughout
their lifecycle.