Digital Government Institute Electronic Records Management Conference March 2004 AIIM Technical Repo

1
Digital Government InstituteElectronic Records
Management ConferenceMarch 2004AIIM
Technical ReportFramework for the Integration
ofElectronic Document Management Systems
andElectronic Records Management Systems
2
Agenda

• Part A High Level Reference Model Catherine
  Dodge Impact Innovations
• Part B Metadata for Integration Bill
  Manago MDY Advanced Technologies
• Part C Implementation Approaches Jon
  Barrett Hummingbird

3
Acronyms

• EDMSElectronic Document Management System
• ERMSElectronic Records Management System

4
Part AHigh Level Reference Model

• Catherine Dodge
• Practice Director, ECM Solutions
• Impact Innovations
• Phone [phone]
• Email catherine.dodge_at_impactinnovations.com
• Impact Innovations Group Proprietary
  Confidential

5
Agenda Reference Model

• Framework for Integration of EDMS / ERMS
• What is a High Level Reference Model?
• Integrated EDMS / ERMS Reference Model
• 13 Functional Components
• Functional Component Example

6
Framework for Integration of EDMS/ERMS

• Integration
• the combination of several software applications
  such that data can be transferred from one
  application to others through a consistent
  interface so as to better coordinate tasks and
  merge data
• Integration Framework -
• EDMS and ERMS systems share common functionality
  
• (High Level Integrated Reference Model)
• AND
• EDMS and ERMS systems share common metadata
• (Metadata for Integration)

7
Standards

• EDMS Standards
• Open Document Management API
• Web-based Distributed Authoring and Versioning
• Black Forest Group, Document Management Services
  Across the Global Business Enterprise
• Dublin Core Metadata Initiative
• Workflow Management Coalition

• ERMS Standards
• ISO 15489 (Information and Documentation
  Records Management)
• DoD 5015.2 (Design Criteria Standard for
  Electronic Records Management Applications)
• UK PRO (United Kingdom Public Records Office)
• MoReq (Model Requirements for the Management of
  Electronic Records)

Plus Other Sources
8
What is a High Level Reference Model?

• Shared map of the components of an integrated
  systems. Each component represents
• Key business activities (functional components)
  that are integral to overall business
  functionality
• Points of integration between EDMS / ERMS
• Functional or technical components that are
  similar or identical
• Comparison of metadata elements(sharing or
  co-ownership)

9
Integrated EDMS/ ERMS Reference Model Disclaimer

• The model is an illustrative example
• The model is not definitive, exhaustive or
  intended to imply a chronological order
• Each enterprise will have a different view of the
  model as presented based on their own business
  drivers

• However

10
Integrated EDMS/ ERMS Reference Model

• the committee believes that
• a reference model that is similar or analogous
  to the one presented in this report is essential
  for integrated EDMS/ERMS systems.
• The reference model provides a framework for
  you as you look to either integrate or procure an
  integrated EDMS/ERMS system.

11
Integrated EDMS/ERMS Reference Model
12
Integrated Model Functional Components

• Content Capture and Capture
• Content Management
• Records and Asset Management
• Content Organization

13
Integrated Model Functional Components

• Content Use Management
• Metadata Management
• Publishing, Aggregation and Syndication
• User Management

14
Integrated Model Functional Components

• Search and Browse
• System Configuration
• System Administration
• Workflow Management
• Management Reporting

15
Functional Component Example(Create and Capture
Content)
16
Next Steps.

• We need your feedback!
• Is this useful?
• What else would be meaningful?
• Develop further into Technical Models
  and/orTechnical Standards
• Best Practices
• Expand to accommodate Approaches that make sense
  when integrating other Enterprise Content
  Management (ECM) applications to ERMS such as
• Workflow / Business Process Management
• Web Content Management
• Collaboration
• etc.

17
Part BMetadata for Integration

• Bill ManagoDirector, Records Management Best
  PracticesMDY Advanced Technologies, Inc.21-00
  Route 208 SouthFair Lawn, NJ 07410Phone (201)
  475 4772Email Bmanago_at_mdy.com

18
Definition 1

• The simplest useful definition of metadata is
  structured data about data. This very general
  definition includes almost a limitless spectrum
  of possibilities ranging from human-generated
  textual description of a resource to
  machine-generated data that may be useful only to
  software applications.
• Dublin Core Metadata Initiative, 02/07/1997

19
Definition 2

• Perhaps a more useful big picture way of
  thinking about metadata is as The sum total of
  what one can say about any information object at
  any level of aggregation. In this context, an
  information object may be comprised of a single
  item, or it may be an aggregate of many items.
• Dr. Ann J Gilliland Swetland in Introduction to
  Metadata

20
Definition 3

• The Macquarie Dictionary defines the prefix
  Meta- as meaning among, together with,
  after or behind. That suggests the idea of a
  fellow traveler that metadata is not
  fully-fledged data, but is a kind of
  fellow-traveler with data, supporting it from the
  sidelines. It describes the information resource
  or helps provide access to the resource.
• Dr. Warwick Cathro National Library of
  Australia, August 1997

21
Purpose

• Content Identify the name of the work, who
  created it, who formatted it and other
  descriptive information.
• ContextProvide unique identification and links
  to organizations, files, or databases which have
  more extensive descriptive metadata about the
  work.
• StructureExplain the technical environment
  needed to view the work, including applications
  and version numbers, decompression schemes, other
  files that may be linked to it, etc.

22
Function of Metadata

• Assist with the retrieval of records
• Improve the management of records
• Document transactions relating to a record
• Provide contextual and descriptive information
  that is essential to the integrity of records
• Facilitate the sharing of information
• Facilitate interoperability between applications
  and organizations

23
Objective

• To define a common core set of metadata elements
  within an integrated document and records
  management system, enabling users to begin saving
  these common elements. The elements are directly
  tied (linked or encapsulated) to the digital
  object for better understanding of that object.

24
The GlueIntegrated EDMS/ERMS Reference Model
25
Sources

• Dublin Core
• DoD 5015.2 Standard
• Public Record Office UK
• MoReq
• MS Word
• WordPerfect

26
Organization

• Document/Record Description
• Access Controls
• Retention/Disposition Instructions
• History

27
Document Description

• Audience
• Author/Creator/Originator
• Contributor
• Coverage/Scope
• Date Available
• Date Closed
• Date Created
• Date Cutoff
• Date Declared/Filed

• Date Modified
• Date Received/Acquired
• Date Published
• Description/Abstract
• Document Type
• Format/Application
• From/Sender/Originator
• Key Words
• Language

28
Document Description (continued)

• Location
• Media Type
• Office of Origin
• Originating Organization
• Publisher
• Rendition Number
• Version Number
• Relationships/Links

• Signed By/Signatory
• Source
• Status
• Subject
• Title
• To/Addressee/CC/BCC
• Unique Identifier
• User Defined Fields
• Vital Record Indicator

29
Access Controls

• Accessibility
• Rights
• Security Classification Markings
• Supplemental markings

30
Disposition Instructions

• Disposal Actions
• Disposal Instructions
• Disposal Action Dates
• File Code Numbers
• Category Code Numbers

31
History/Audit Trail

• Change History
• Date Accessed
• Date Copied
• Date Moved
• Date Reformatted
• Preservation Activity
• Transaction Log
• Migration History

32
System Requirements

• Extract metadata elements automatically from
  records when they are captured
• Permit metadata values to be retrieved and
  captured from lookup tables
• Allow creator of records to manually enter
  pertinent metadata
• Support the validation of metadata entered by
  users or imported from other systems
• Logically link metadata to records, files and
  classes
• Allow for the modification and reconfiguration of
  metadata sets

33
Part CImplementation Approaches

• Jon Barrett
• Federal Program Manager
• Hummingbird
• Phone [phone]
• Email jon.barrett_at_hummingbird.com
• Impact Innovations Group Proprietary
  Confidential

34
Agenda Implementation Approaches

• Overview
• The Challenge
• The Method
• The Results Approaches to Implementation
• Approach 1 Integration of Stand-alone Systems
• Approach 2 Integrated System
• Approach 3 ERMS Server in Control
• Using the Approaches to Implementation
• Where to from here ?

35
Overview - Implementation Approaches

• The first two sections Functionality and
  Metadatadescribe the what.
• The Implementation Approaches section deals with
  the how
• Three broad approaches are described

36
The Challenge

• This was arguably the most contentious
  section.Why ?
• The Committee had to describe approaches that
  were
• Useful to the reader in describing both current
  andfuture implementation options.
• Independent of Deployment architecture.
• Independent of Repository architecture.
• Did not favor one vender over another.
• Could describe Vendor (COTS) or Custom Built
  systems.

37
The Method

• Do not attempt to develop a full set of Technical
  Models,hence general approaches.
• Do not define Technical Standards.
• Does not attempt to answer the 64,000 question
  When does a document become a Record ?.It
  assumes that at some stage in the information
  lifecyclea Document becomes a Record.
• To the committees knowledge, all EDMS/ERMS
  implementationsfall into one of these three
  approaches.
• Do not judge or rank each approach.

38
Approach 1 Integration of Stand-alone Systems
EDMSRepository/Server
ERMSRepository/Server
Integration
EDMSUser Interface
ERMSUser Interface

• The EDMS has its own User Interface and its own
  Repository/Server architecture.
• The ERMS has its own User Interface and its own
  Repository/Server architecture.
• An Integration is provided between the two
  systems.The approach described in this technical
  report is independent of the specifics of how the
  integration is achieved, or the technical
  platform(s) it is implemented on, hence the
  integration cloud.

39
Approach 1 Integration of Stand-alone
SystemsAttributes Factors

• Documents are Copied or Moved (some approaches
  support either or both) from the EDMS to the
  ERMS.
• Best of Breed Approach
• Leverage Existing Investments in either EDMS or
  ERMS by adding on the missing component.
• Typically, the systems use different Search
  Retrieval tools.
• Considerations must be given to product lifecycle
  issues such assupport, maintenance,
  compatibility, and ownership of the integration
  software.
• Example
• MDY

40
Approach 2 Integrated System
EDMS ERMSRepository/Server
EDMS ERMSUser Interface

• The EDMS and ERMS User Interface is integrated.
• The EDMS and ERMS Repository/Server Architecture
  is integrated.
• For commercially available applications, the
  solution often is supplied by a single vendor or
  a vendor partnership.

41
Approach 2 Integrated SystemAttributes Factors

• Single Repository Architecture.May or may not
  use a single Repository.
• Typically use a single Search Retrieval tool.
• The approach now taken by most of the leading
  Content Management vendors.
• Lowers technology risk and usually lowers the
  overallcost of an integrated solution.
• Examples
• Documentum
• Hummingbird
• OpenText
• Tower Software

NoteVendors may support multiple approaches
42
Approach 3 ERMS Server In Control

• The EDMS has its own User Interface and its own
  Repository/Server architecture.
• A back office ERMS Repository/Server
  architecture manages (from a Records Management
  perspective) objects in the DM Repository/Server
  architecture.

43
Approach 3 ERMS Server In Control Attributes
Factors

• The single ERMS may support multiple EDMS Systems
• Requires multiple integration bridges
• The Record is preserved in the original EDMS
  application.
• Low network traffic when a Document becomes a
  Record
• The ERMS keeps stubs that point to the EDMS.
• Key implementation factor is the level of control
  the ERMS can have over the EDMS system(s).
• Does not require end-user interaction for a
  Document to become a Record
• The newest and least implemented approach

44
Using the Approaches to Implementation

• A common way to describe EDMS/ERMSimplementations
  at a conceptual level.
• Can be used to describe
• Current Systems
• Future Systems
• Is a useful tool when discussing implementation
• With all key stakeholders
• IT
• Records Management
• Business Groups
• Executive
• As a basis for Business Process discussions
• As a basis for Technical discussions
• As a basis for Security Discussions

45
Where to from here ?

• The committee has not decided on where to take
  the Approaches next.Some ideas
• Develop further into Technical Models
  and/orTechnical Standards
• Expand to accommodate Approaches that make sense
  when integrating other Enterprise Content
  Management (ECM) applications to ERMS such as
• Workflow / Business Process Management
• Web Content Management
• Collaboration
• etc.