IMPLEMENTING AN ELECTRONIC
RECORDS PROGRAM: LESSONS
LEARNED FROM THE INDIANA
UNIVERSITY ELECTRONIC RECORDS
PROJECT
Philip Bantin
Indiana University Archivist
Director of the IU Project
bantin@indiana.edu
How to Implement an Electronic
Records Strategy


Theories abound regarding
electronic records
management
What we all desperately need
are case studies on HOW
institutions are developing and
implementing electronic
records programs
Implementing E-R Programs
Preliminary Step #1


Records professionals must define their
primary and unique contributions to
managing digital resources
To do this the profession must not only
define itself, but also articulate the
mission of archives/records
management in relation to the goals
and objectives of other related data and
information management professionals
Preliminary Step #1
Define: What is a Record?


Records reflect business processes or
individual activities; a record is not just
a collection of data, but is the
consequence or product of an event
Records provide evidence of these
transactions or activities. In other
words, recorded documentation cannot
qualify as a record unless certain
evidence about the content and
structure of the document and the
context of its creation are present and
available
Preliminary Step #1
Define: What do archivists/records
managers contribute?


The IU Archives team has defined its
mission and its contribution as the
identification and appraisal of records
generated in the context of business
processes, and the creation of systems
that capture, manage, and preserve
these records
In other words, records and
recordkeeping systems are our main
and primary responsibilities
Preliminary Step #2
Define System Requirements



What are the basic requirements for a
recordkeeping system? What functions
will the system perform?
What types of documentation or
metadata must be present to ensure the
creation of authentic and reliable
records?
These are your blue-prints that form the
framework for your e-r program
Preliminary Step #2
Define System Requirements







Of prime importance is addressing the questions:
Is the system capturing business records?
Is the system ensuring that all necessary record
metadata documenting business processes are
captured?
Is the system maintaining inviolate records protected
from accidental or intentional deletion or alteration?
Is the system preserving records with long-term
value?
Is the system implementing retention and disposal
decisions?
Is the system ensuring the future usability of the
business records?
Preliminary Step #3
Forming PARTNERSHIPS with other
Information Professionals


Goal: Find some means of
involving your program in the
authorized and routine review
of information systems.
Align your program with
professionals who routinely
design and review information
systems
Preliminary Step #3
Forming PARTNERSHIPS with other
Information Professionals




Based on experience, I have
found three partners most
valuable:
Decision support personnel
Systems analysts
Internal auditors – Particularly
the IS auditors
Translating these Requirements into
an Implementation Strategy



2 Primary Steps
1) Develop a methodology, a set of
steps that will allow you to design
or analyze a system according to
your sets of recordkeeping
requirements and metadata specs
2) Develop a strategy for
implementing your
recommendations
Analysis of Information
Systems


My experience would indicate that
traditional records management
strategies established for paper
records will have to be altered in
significant ways to accommodate
electronic records.
How?
Analysis of Information
Systems

The most important and profound
change will be the creation of an
overall strategy that views
CONCEPTUAL MODELS and SYSTEM
DOCUMENTATION as the primary
tools for dealing with many or
most of the issues the profession
faces in attempting to manage
records in automated
environments
WHAT IS CONCEPTUAL
MODELING?

Conceptual models show what
a system does or must do.
They are implementationindependent models; that is,
they depict the system
independent of any technical
implementation.
Business Process Models


These models provide the tools for
identifying records, and for undertaking
most steps in the systems design and
analysis process.
Depicting or modeling the business
processes and/or workflow activities is
the critical first step in the analysis
process; all other activities build off the
results of these models or descriptions
of the business processes.
USEFUL MODELS FOR
ARCHIVISTS
•
•
•
•
Business process decomposition
descriptions or diagrams
Business Event Diagrams
Business process data flow
diagrams
Object Modeling – Unified Modeling
Language (UML)
Timekeeping
Data Flow
From student
Hours worked
Complete
Timesheet
Completed
Timesheet
Approve/
Disapprove
Timesheet
Approved
Timesheet
Final
Approve/
Disapprove
Timesheet
New
Timesheet
Timesheet
Disapproved
Timesheet
To Payroll
Final
Timesheet
Disapproved
Timesheet
Correct
Timesheet
Create
Timesheet)
Recordkeeping System
From system
Models and Documentation Data



Examples:
Data Models: A depiction of a system’s
data in terms of entities (types of things we
want to document) and relationships
(properties or characteristics of an entity)
Data Dictionary: A repository of information
about the definition, structure, and usage of
data that may include the name of each data
element, its definition (size and type), where
and how it is used, and its relationship to
other data
Documentation - System


Descriptions of how an information
system works from either a
technical or end-user perspective
Procedure Manuals; Descriptions of
Security and Authorization
Procedures; Descriptions of
Procedures for Migrating, Purging,
Exporting, and Restoring Data
Analysis of System:
Is the system capturing records?



Answer this by:
Examining and/or creating Business
Process models
Record creation occurs at the business
transaction level, and the actual records
to be analyzed are are those documents
received as inputs to the system and
those records created as a result of the
outputs generated in response to some
business event or workflow activity.
Record Capture


For analyzing record capture, analysis
and documentation will occur at the
Business Event or Record Level rather
than at a the level of a function or of
high level business process
To be effective, analysis of business
processes will have to drill down to the
business transaction that directly
created the record.
Record Capture



Why is this necessary?
Because we cannot assume these
records and their metadata will be
captured by the automated system
Unlike paper records, we cannot assume
an electronic record (and its metadata)
once created, viewed and used in some
business transaction will be captured
and saved.
Record Capture




Is this level of analysis realistic? YES
But only if archivists employ a
methodology based largely upon
conceptual models.
Also recognize that the vast majority of
these transactions are repeatable, and
once you have identified the
transaction, you do not have to do it
again.
In this sense, each repeatable
transaction forms a record series.
Analysis of System:
How Will We Know if the System is
Maintaining Inviolate Records?



Examine procedure manuals and
workflow models relating to routing,
inputting, updating, saving and deleting
records, and system security
procedures.
Analyze each major business
transaction and the records it produces
in terms of these procedures
For many records this activity can be
managed at the sub-function level or for
many processes within a function
Analysis of System:
Is the system preserving records?



Examine procedure manuals relating to
backing-up, migrating, purging,
exporting and restoring data
Analyze each major business
transaction and the records it produces
in terms of these procedures
For many records this could be managed
at the sub-function level or for many
processes within a function
How Will We Know When We Have a
Complete, Authentic, and Reliable
Record?




Examine any models or documentation on
data and metadata
Determine on the basis of your metadata
specifications and business process models
which metadata elements need to be present
Some metadata can be assigned at the
aggregate level, i.e., there is a core set of
metadata that will be assigned to all records
produced by a business function/sub-function
However, some business processes will
require more detailed documentation
Analysis of System:
Is the system implementing
retention and disposal decisions?



Review any existing disposition
schedules and laws, policies and best
practices related to recordkeeping
Analyze transactions, and if necessary
individual records, identified in your
business process models, to determine
how long records of this business
process must be retained.
Examine documentation on data and
data models to determine what types of
informational value may be present in
records
Analysis of System:
Is the system ensuring the
usability of business records?



Review any procedures that define
access and use of records, and training
procedures
Analyze each major business
transaction and the records it produces
in terms of these procedures
Access and security: For many records
this can be managed at the sub-function
level or for many business processes
within a function
Review and Analysis of New
Systems


Involvement in Design Stage
makes the process much easier to
implement
In many cases, designing a new
system involves incorporating
your requirements or specifications
and the results of your business
process models into the design of
the new system
Review and Analysis of
Existing Systems




Normally a more time consuming, more
difficult process
Involves not only specifying your
requirements and metadata specifications and
your list of records to be captured
It also requires an analysis of how the
present system is managing the data
It involves analysis of “What is” as depicted
by models and system documentation with
“What Should Be” as defined by your
requirements, specifications and models
Analysis and Documentation



Automated systems offer:
1) Opportunities to define records more
precisely and more completely than
ever before, and we can realistically
achieve this if we employ conceptual
models
2) Threats to the very existence of
records if we do not modify our
traditional methodologies
Implementation Strategies

There are many
strategies for
incorporating
Recordkeeping
Functionality into Data
and Information Systems
Implementation Strategies



Issues to consider:
Should recordkeeping be
incorporated into the specific
application or should
recordkeeping be a separate
but integrated system?
How to combine record content
and metadata?
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS



A key implementation strategy:
Automate records
management functions to the
greatest extent possible.
What does this mean for each
of the issues related to
capture, documentation,
disposition, preservation, and
usability?
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS


Capture of Records and
Metadata – Implementation
Strategy: Design systems so
that the capture of records and
metadata occur within the
context of an automated
workflow or business process
engine
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS


Capture of Metadata
Strategy: Develop automated
audit trails documenting all
business processes, including
activities relating to the
creation, updating or revision,
deletion, and access and use of
records
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS





Disposition of Records
Develop an automated, schedule-driven
process
Automated retention and destruction of
records
Automated notification and approval of
designated personnel in advance of
disposition activities
Automated interruption of disposition
activities for records that become the
subject of litigation
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS



Preservation of Records
Automated schedule of when
the copying and conversion of
records will occur
Automated notification and
approval of designated
personnel in advance of
preservation activities
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS



Usable and Meaningful Records
System assembles as a unit all
components of a record,
including relevant metadata,
notes, attachments, etc.
System maintains a
relationship or link between
the records of related business
processes
BUILDING RECORDKEEPING
FUNCTIONALITY INTO SYSTEMS
Another implementation
strategy:
 Whenever possible, build
recordkeeping functionality
into ENTERPRISE-WIDE
applications rather than
into individual applications

OneStart/EDEN
A Description of IU's Transaction
Processing/Recordkeeping
Environment
Portals and Recordkeeping
How can archivists and records managers,
leverage portals in our efforts to capture,
maintain, and preserve electronic records?
At Indiana University . . .
OneStart
Campus portal
EDEN
(Enterprise Development ENvironment)
Shared infrastructure
Portals in Higher Education
“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.”
David L. Eisler, “A Portal’s Progress”
Syllabus Magazine, September 2000
Background – IU’s IT Strategic
Plan


Five-year Information Technology (IT)
Strategic Plan released 1998
Replacement or re-engineering of several
enterprise wide applications


PeopleSoft’s HRMS and SIS
Excellent opportunity to integrate all of the
enterprise applications at IU through a
transaction-processing environment

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
OneStart & EDEN Component-Based Development
OneStart
Desktop
Adaptable
Personalized
Customized
User Interface
Application
Delivered
Channels
Other
IUIE
FIS
SIS
HRMS
Applications
Other Content
Services
Users
Record
Keeping
Security
Workflow
Infrastructure
EDEN
Application
Services
Conceptual Design – Advantages of
Component-Based Development




Creates a repository of reusable business
functions that also allows for the replacement
of specific functions
Aids rapid application development by
assembling existing components and services.
Can improve the agility, flexibility, and
scalability of an application.
As long as components agree upon the
protocol to be used, an application does not
have to reach into another application's
database for information.
Conceptual Design – Workflow
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.”
http://www.e-workflow.org/
“Starting from creation and ingestion, we should integrate
the workflow process with the preservation process:
appraisal, verification, maintenance and, eventually,
retirement.”
Su-Shing Chen “The Paradox of Digital Preservation”
Computer (IEEE Computer Society), March 2001
Conceptual Design – EDEN Workflow Engine
Applications
EDEN
Portal
(Infrastructure)
FIS
(User Interface)
Inbox
HRMS
OneStart
Workflow
Engine
Purchasing
Preference
Engine
Recordkeeping
Conceptual Design – Routing an E-Doc
Applications
EDEN
Portal
(Infrastructure)
FIS
(User Interface)
Inbox
HRMS
OneStart
Workflow
Engine
Purchasing
Preference
Engine
Recordkeeping
Conceptual Design – Workflow and Electronic
Recordkeeping
Applications
EDEN
Portal
(Infrastructure)
FIS
(User Interface)
Inbox
HRMS
OneStart
Workflow
Engine
Purchasing
Preference
Engine
Recordkeeping
IU Electronic Recordkeeping
Project
http://www.indiana.edu/~libarch/
ER
OneStart/EDEN
Portal
http://onestart.iu.edu
Project Website
http://onestart.iu.edu/project