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

1

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

2

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

3

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.

4

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.

5

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 blueprints that form the framework for your E-R program.

6

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?

7

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.

8

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

9

Translating These Requirements into an Implementation Strategy

Two 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

10

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?

11

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.

12

What Is Conceptual Modeling?

• Conceptual models show what a system does or must do. They are implementation-independent models; that is, they depict the system independent of any technical implementation.

13

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.

14

Useful Models for Archivists

• Business process decomposition descriptions or diagrams
• Business Event Diagrams
• Business process data flow diagrams
• Object Modeling — Unified Modeling Language (UML)

15

Timekeeping

16

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.

17

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.

18

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 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.

19

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.

20

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.

21

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.

22

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.

23

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 activity can be managed at the sub-function level or for many processes within a function.

24

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.

25

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.

26

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.

27

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.

28

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.

29

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.

30

Implementation Strategies

Automated systems offer:

• There are many strategies for incorporating Recordkeeping Functionality into Data and Information Systems.

31

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?

32

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?

33

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.

34

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.

35

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

36

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.

37

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.

38

Building Recordkeeping Functionality into Systems

Another implementation strategy:

• Whenever possible, build recordkeeping functionality into enterprise-wide applications rather than into individual applications.

39

OneStart / EDEN:
A Description of IU’s Transaction Processing / Recordkeeping Environment

40

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

41

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

42

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.

43

OneStart & EDEN Component-Based Development

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.

45

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

46

Conceptual Design —
EDEN Workflow Engine

47

Conceptual Design —
Routing an E-Doc

48

Conceptual Design —
Workflow and Electronic Recordkeeping

49

IU Electronic Recordkeeping Project

<http://www.indiana.edu/~libarch/ER/>

OneStart / EDEN

Portal

<http://onestart.iu.edu/>

Project Web Site

<http://onestart.iu.edu/project/>^*

50