A Framework for EDMS/ERMS Integration

(1)

5 4 The Information Management Journal • November/December 2004

A Framework

for EDMS/ERMS Integration

Integrating electronic document management systems (EDMS) and electronic records

management systems (ERMS) ensures records are designated as such and receive the

special treatment and protection they deserve

J. Timothy Sprehe

At the Core

This article

• introduces the 2004 technical

report, Framework for Integration

of Electronic Document Manage-ment Systems and Electronic Records Management Systems

• explores the reasons for integrating

EDMS and ERMS

• discusses three approaches to

inte-grating EDMS and ERMS

ssume that an organization has decided it must have electronic records manage-ment systems (ERMS) capability. Records man-agers, information technology (IT) managers, attorneys, and executives have examined the costs and benefits of con-tinuing to keep records in physical for-mat in the face of an exponential increase in electronic documents within the organization. They have experienced the staggering costs of discovery when faced with litigation. An emergency or disaster has impressed upon them the difficulty of recovering normal business operations when they depend on paper records alone.

With the decision made to acquire an ERMS, records managers, and IT man-agers confer and discover these basic realities:

1. Integration: An ERMS does not generate records, for the most part. Records come from other applica-tions in the organization. Assum-ing it has examined the market-place and selected a commercial-off-the-shelf (COTS) ERMS, a key task will be to integrate it with

sys-tems in which the organization’s records are created and declared. 2. ERMS Standards: In the United

States, the de facto ERMS standard is DoD 5015.2-STD, version 2, Design Criteria Standard for Electronic Records Management Applications. The Department of Defense (DoD) operates a testing and certification program for 5015.2 so that COTS vendors of ERMS can receive a multi-year cer-tification attesting that their prod-uct meets the requirements of 5015.2. All federal agencies require 5015.2 in ERMS, as do many state agencies. Commer-cial enterprises have also widely adopted 5015.2. Other excellent ERMS standards exist, but 5015.2 is currently pre-dominant in the United States. In most contexts, 5015.2 ensures that

A

(2)

purchasers acquire a product that contains certain basic records man-agement functionality.

3. EDMS Standards: Standards for electronic document management systems (EDMS) are less formal-ized than ERMS standards. For example, ODMA – the Open Document Management API (applications program interface) – is an open, voluntary industry de facto standard. In practice, pur-chasers of EDMS/ERMS know what functionality they are getting with respect to ERMS but must look carefully at what a particular product means by EDMS. One EDMS product may have “thin” EDMS functionality and another may have “robust” EDMS function-ality. Purchasers of EDMS products find themselves in much more of a “buyer beware” situation than do purchasers of 5015.2-certified ERMS products.

In the face of these realities, a group of interested individuals and organizations worked with AIIM International to form the C30 Standards Committee on Integrated EDMS/ERMS. The commit-tee is comprised of representatives from ARMA International, federal agencies including the National Archives and Records Administration, representatives from software vendors and systems inte-gration companies, and other interested parties.

From the beginning, the committee’s larger ambition was to create functional requirements for the integration of ERMS with the full range of applications that make up enterprise content man-agement (ECM). That is, the committee recognized that, within an enterprise, ERMS must be integrated with the full range of all IT applications that generate records, not just EDMS. In addition to EDMS and ERMS, a given enterprise’s content management applications could include workflow, imaging, Web publish-ing, digital asset management, electronic forms management, and many other IT

applications. Each of these IT applica-tions may generate records that are des-tined for the organization’s ERMS and so integration must occur between the applications and the ERMS.

Not wishing to spread its wings so far as to preclude a first flight, the C30 Committee restricted its work to EDMS/ERMS integration. On one hand, the committee believed that EDMS was the most common IT application to be

for a comprehensive set of “best prac-tices” in EDMS/ERMS integration.

In 2004, the committee completed its first technical report, Framework for Integration of Electronic Document Man-agement Systems and Electronic Records Management Systems (ANS/AIIM/ARMA TR48-2004). For its first technical report, the committee settled on a framework that would set forth the basic conditions for EDMS/ERMS integration. The frame-work is by no means definitive or exhaus-tive. In disseminating its first technical report, the C30 committee is soliciting comments from interested parties that will assist it in extending its work. Common Understanding

The committee relied on the following definitions:

• Electronic Document Management System (EDMS): The electronic man-agement of electronic documents contained in an IT system, using computer equipment and software to manage, control, locate, and retrieve information in the electronic system. • Electronic Records Management System (ERMS): The electronic manage-ment of electronic and non-elec-tronic records contained in an IT system using computer equipment and software according to accepted principles and practices of records management.

• Integration: The combination of sev-eral software applications such that data can be transferred from one application to others through a con-sistent interface so as to better coordi-nate tasks and merge information. • Metadata: Data describing context,

content, and structure of documents and records and their management through time. Metadata is literally data about data.

• Reference Model: An identification of the top-level abstractions that under-lie IT systems, defining common ter-minology and concepts that allow the architectures of existing and future

November/December 2004 • The Information Management Journal 5 5

integrated with ERMS. On the other hand, the committee hoped that, if it could arrive at functional requirements for EDMS/ERMS integration, those requirements could quite possibly be applied with some ease to other IT applications.

The committee began its work in pur-suit of functional requirements that might constitute a formal standard. As work progressed, this goal appeared beyond the committee’s immediate reach in large part because the applications technology is relatively new and has not achieved a satisfactory level of maturity. By the same reasoning, the committee abandoned for the time being the search

Merging the

functionality

of EDMS with the

requirements

of ERMS provides

for the reuse of

electronic

information

and ensures the

integrity and

retention of the

electronic records.

(3)

systems to be described and com-pared. The reference model provides a conceptual and functional frame-work within which independent experts may proceed with discussions and agreements.

The business decision to acquire or develop integrated EDMS/ERMS results from the need to ensure that documents in an EDMS that qualify as records will be designated as such and given the spe-cial treatment and protection they require. EDMS and ERMS each perform some unique functions and have certain functions in common. For example, both EDMS and ERMS retrieve, view, and print documents or records. Neither system’s approach completely satisfies the

• EDMS and ERMS share common functionality

• EDMS and ERMS share common metadata

The reference model above (Figure 1) illustrates the shared map of an integrat-ed system’s components, showing how components interact with one another. The model consists of 13 numbered components. Each component has key business activities that are integral to the overall functionality of an integrated EDMS/ERMS. For each component, activities must be defined, metadata ele-ments must be compared, and potential areas of integration must be identified.

Both EDMS and ERMS environments

FIGURE 1: An Integrated EDMS/ERMS Reference Model

SettingStandards

imply a chronological order. That is to say, each enterprise may choose to iden-tify the top-level components and com-ponent activities in its own way. The C30 committee believes, however, that a high-level reference model that is similar or analogous to the one illustrated is essen-tial for integrated EDMS/ERMS.

Metadata, the central oval in the figure, can be thought of as the common lan-guage that information architecture components use to interoperate and integrate their functions. Metadata is a summary of the form and content of a document/record and pertains to the meaning and context of data. The C30 Committee’s technical report surveys the literature on metadata and presents a model set of metadata.

Reference Model Components: An Example

TR48 enumerates the various activi-ties that comprise each model compo-nent and indicates whether a particular activity occurs in an EDMS, an ERMS, or both. For example, under “Content Creation and Capture,” the first compo-nent listed in Figure 1, the first step is to define content, then create or receive content, which may require converting paper content, capturing e-mail, or gen-erating content automatically. Content may be enhanced by linking it to other sources, annotating, editing, and trans-lating it into a language other than the source language. Content may be revised to different versions and transformed into different renditions.

Finally, content may be formatted in various ways. Documents may be created and changed in EDMS, but records may not be edited or altered in an ERMS envi-ronment. Copies of records may be retrieved into an EDMS in order to cre-ate new content or aggregcre-ate content into new documents and new records. Both documents and records may be translat-ed and formatttranslat-ed, so any systems that are supporting both activities – integrated or independent – must be able to version and link associated content.

Table 1 (pg. 58) shows the detailed

Metadata

8. User Management 9. Search & Browse 10. System Configuration 11. System Administration 12. System Management 13. Management Reporting 2. Content Management

3. Records & Asset Management 4. Content Organization 5. Content Use Management 6. Metadata Management 7. Content Repurposing & Publishing 1. Content Creation & Capture

have functional and technical compo-nents that are similar or identical. This is true of repository management, data-base support, application modules, and functional processes. However, the shar-ing or co-ownership of data, potentially both application and object metadata, as well as actual electronic objects, is typi-cally required for two systems to operate in an integrated manner.

The model and its components are intended as an illustrative example. It is not definitive, exhaustive, or intended to need for full lifecycle management of

document-based information, however. Merging the functionality of EDMS with the requirements of ERMS provides for the reuse of electronic information and ensures the integrity and retention of the electronic records.

Framework for EDMS/ERMS Integration

Integration of EDMS/ERMS is achieved when both of the following conditions are met:

(4)

Activity Description Occurs in EDMS Occurs in ERMS

1. Define content Define what content consists of X 2. Convert paper content Capture/scan paper-based information

into digital format X X

3. Create or receive content Compose document content or receive

document content from elsewhere X X (receive only) 4. Capture e-mail Import/save e-mail messages and attachments X X 5. Generate content automatically Invoke established devices to provide previously

created/received content X 6. Link content Associate present content with other

information sources X X

7. Annotate content Annotate a document, including the association

of that annotation with the document X 8. Edit content Add to, delete from, or otherwise modify content X 9. Translate content (language) Render content in a language other than the

source language X

10. Version content Alter created/received content enough that it

is considered a different version X 11. Transform content (renditions) Render content by transformation such as

changing text to presentation slides X 12. Format content Change the physical appearance/arrangement of

content or computer format (e.g., RTF, ASCII, etc.) X

TABLE 1 Content Creation and Capture: Component Details

order to maximize the benefits derived from IT systems.

TR48 synthesizes the various national and international sources on EDMS/ ERMS metadata and presents four sets of metadata elements:

1. Document/Record Description – con-sists of audience, author/creator/ originator, contributor(s), coverage/ scope, date available, date closed, date created, date cutoff, date declared/ filed, date modified, date received/ acquired, date published, descrip-tion/abstract, document type, for-mat/ application, from/sender/origi-nator, key words, language, location, media type, office of origin, origina-tion organizaorigina-tion, publisher, rendi-tion number, version number, rela-tionships/links, signed by/signator, source, status, subject, title, to/ addressee/cc/bcc, unique identifier, user-defined fields, and vital record indicator

activities of the content creation and capture component and lists whether the activities occur in an EDMS, an ERMS, or both.

Other similarities and differences between the two systems include:

• Documents may be created, edited, altered, deleted, or saved in an EDMS. Saved documents may be declared records and copies of such documents may be exported to the control of an ERMS. An ERMS per-mits export of records to an EDMS but does not permit the editing, altering, or deleting of records in the ERMS environment.

• Copies of records imported into an EDMS may be combined and aggre-gated in order to create new docu-ments. These new documents may be declared records.

• IT systems in which documents are created may or may not have EDMS

and ERMS functionality, but as a best practice such systems should be capable of exporting their docu-ments to EDMS and ERMS. Metadata

In the broadest sense, metadata can be used to describe the core set of ele-ments needed for the effective retrieval and management of information. It may also include information structures such as the technical standards, formats, and interconnection policies that are required to render the information in a human-readable fashion. Metadata is essential to sharing data across IT appli-cations in order for integration to occur. It is essential to the management, acces-sibility, and security of electronic docu-ments and records common to all busi-nesses and organizations. In managing electronic information, the capture of appropriate metadata must be integrat-ed into the process of creating and maintaining the document or record in

(5)

November/December 2004 • The Information Management Journal 5 9

2. Access Controls – consists of acces-sibility, rights, security classifica-tion, and supplemental markings 3. Retention/Disposition Instructions –

consists of disposal, disposal action, disposal action date, file code/number, and category code/ number

4. History or Audit Trail – consists of change history (succession of values), date accessed, date copied, date moved, date reformatted, preservation, transaction log, and preservation and migration history Implementation Approaches

Once an enterprise has agreed on its EDMS/ERMS reference model and determined a list of mandatory enter-prise-wide metadata, the next step is to acquire the software systems necessary to achieve EDMS/ERMS capability. The fol-lowing three general approaches come from the viewpoint of both contempo-rary enterprise situations and software systems development in industry:

Approach 1: Stand-Alone EDMS and ERMS Integration

An organization wants to add ERMS capability to an EDMS it already has, or the converse may be true: The enterprise has implemented an ERMS and then decides to add EDMS capability.

Approach 1 describes the integration of a stand-alone EDMS with a stand-alone ERMS. The acquiring organization selects the EDMS and ERMS that best satisfy its requirements. The two are integrated, either by EDMS or ERMS vendor, or by a third-party integrator. Figure 2 below depicts this approach.

In this scenario, the EDMS has its own user interface and its own repository/ server architecture. Similarly, the ERMS has its own user interface and repository/ server architecture. The “cloud” in Figure 2 illustrates the integration occurring between the two and the technical plat-form implementing the integration.

Documents in the EDMS are declared and classified as records direct-ly into the ERMS. Enterprises taking this approach may want to consider other factors, such as:

• The enterprise enjoys the full benefits derived from state-of-the-art EDMS and state-of-the-art ERMS. Enter-prises need only acquire one system: either an EDMS or an ERMS depending on which one is already in place.

• The life cycle of documents is divided and managed by the two systems. The life cycle of non-records is captured and managed in the EDMS and ends at the point of record declaration. The life cycle of records managed in the

FIGURE 2: Stand-Alone EDMS and ERMS Integration

Access

TR48 Online

In August 2004, AIIM International published the (ANSI/AIIM/ARMA TR48-2004) Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems. The technical report defines, describes, and differentiates the two most common types of information sys-tems used to manage electronic document-based information with current technology – electronic document management systems (EDMS) and electronic records management systems (ERMS) – and provides a framework for their integration. It presents an integrat-ed EDMS/ERMS top-level reference model and describes general approaches to implementing the model. The report also includes a bibliography, references, acronyms, and definitions.

TR48 is the first endeavor of the joint AIIM/ARMA C30 Committee. The report’s value lies ultimately in its acceptance by practitioners.The committee invites comments on TR48 from all quarters. Interested parties may send comments to [email protected] C30 Standards Committee’s Web site, www.aiim.org/standards.asp?ID= 24484, includes all documents and proceedings. Participation in the committee – in person, by telecon-ference, or by e-mail – is open to all interested parties.

TR48 can be purchased from the ARMA International Bookstore at www.arma.org/bookstore/product-detail.cfm?ProductID=1479.

(6)

ERMS begins at the point of record declaration. Both systems employ audit logs to capture the activities associated with their documents. • Dual databases: Both products

employ their own database manage-ment system to store the data neces-sary for each system independently of the other. Tightly integrated solu-tions share the same database resource.

• Dual repositories: Each product typ-ically uses its own repository. Documents that are non-records are wholly under the control of the EDMS, while records are wholly under the control of the ERMS. • Dual search and retrieval tools: Each

product provides its own search and retrieval tools. Depending on the tightness of the integration, the search tools provided by one prod-uct may be configured to search the data managed by the other product. • Support issues: Responsibilities for support, maintenance, and timing of upgrades may be divided among multiple vendors.

Approach 2: Fully Integrated EDMS/ERMS

In Approach 2, the enterprise acquires a full-featured EDMS with all the tools required to perform ERMS

functions built into the system design. Figure 3 above depicts integrated EDMS/ ERMS.

In this approach, the EDMS/ERMS user interface is integrated, as is the repository/server architecture. Typic-ally, a single vendor or vendor partner-ship supplies the integration for com-mercially available applications. Factors to consider with this approach include:

• Use of a single database, a single document repository, and a single user interface for search and retrieval

• The enterprise has complete cradle-to-grave lifecycle management via a

single application

• Responsibilities for support, main-tenance, and timing of upgrades rest with a single vendor

Approach 3: Integrating ERMS into an EDMS Repository/Server

A third approach for integrating EDMS and ERMS functionality incor-porates ERMS software modules that initially identify and categorize records within the application in which they are originally created. Subsequent to the identification and protection of the records within those applications, information is sent to a metadata server that tracks the retention and other life-cycle management aspects of the record while the record continues to reside in the original repository of the applica-tion in which it was created. Figure 4 below shows this approach.

In this solution, the records engine provides tools required to manage the enterprise file plan, retention schedule, and disposition processing. The records interface is provided to records staff and administrators. The end-user inter-face is provided by the records-enabled business application. The EDMS has its own user interface and repository/serv-er architecture. A “back-office” ERMS repository/ server architecture manages records objects in the EDMS’ reposito-ry/server architecture.

FIGURE 3: Integrated EDMS/ERMS

FIGURE 4: Integrating ERMS into an EDMS

(7)

SettingStandards

J. Timothy Sprehe is president of Sprehe Information Management Associates, a Washington, D.C.-based consulting firm offering services in electronic records management systems and enterprise content management systems. He may be contacted at [email protected].

For More Information

ANSI/AIIM TR 2-1998. Glossary of Document Technologies. Washington, D.C.: AIIM International, 1998.

The Black Forest Group. Requirements for Document Management Services Across the Global Business Enterprise. AIIM International, April 1999.

The Dublin Core Metadata Initiative. Available at www.niso.org/standards (accessed 27 September 2004).

Hollingsworth, David. “The Workflow Reference Model.” Hampshire, U.K.: The Workflow Management Coalition. January 1995. Available at www.wfmc.org/standards/ docs/tc003v11.pdf (accessed 27 September 2004).

ISO 15489, Information and Documentation – Records Management, Part 1: General, Part 2: Guidelines. Available at www.iso.org/iso/en/CombinedQueryResult.Combined-QueryResult?queryString=ISO+15489 (accessed 27 September 2004).

Joint Interoperability Test Command, Records Management Application. Available at http://jitc.fhu.disa.mil/recmgt/index.htm (accessed 27 September 2004).

Model Requirements for the Management of Electronic Records (MoReq). MoReq Specification. March 2001. Available at http://europa.eu.int/ISPO/ida/export/files/ en/635.pdf (accessed 27 September 2004)

U.K. Public Records Office, Requirements for Electronic Records Management Systems, 2002. Available at www.pro.gov.uk/recordsmanagement/erecords/2002reqs/ (accessed 27 September 2004).

Open Document Management API (ODMA). Available at www.infonuovo.com/odma/ (accessed 27 September 2004).

Web-based Distributed Authoring and Versioning (WebDAV) Specifications. Available at www.webdav.org/specs/ (accessed 27 September 2004).

Factors relevant to this approach include:

• The enterprise avoids redundant records storage, recovery, and backup process technologies across both the EDMS and the ERMS, in that the actual record is preserved in one location – the application of origin. • Because the metadata server points

to records that always reside in their original applications, the reduction of file transfers between EDMS and ERMS environments makes for con-siderably less network traffic. • Each application server requires

application integration.

• Records protection becomes a func-tion of the applicafunc-tion and organiza-tion that hosts the system wherein the records reside.

Software vendors are prepared to offer solutions for any of the three approaches outlined, depending on the situation in which a given industry finds itself. In general, the industry is moving toward the unified EDMS/ ERMS approach as a single-product solution. Stand-alone ERMSs are disap-pearing from the marketplace. Moreover, the integrated EDMS/ERMS itself is moving toward ECM, which entails EDMS/ERMS integrated with whatever other software systems create documents and/or records. These sys-tems span a wide spectrum: financial management, human resources man-agement, litigation support, image management, CAD-CAM, and many others.

The message of TR48 is that any enter-prise successfully achieving an integrated EDMS/ERMS will go through the processes of creating a common EDMS/ERMS reference model and devel-oping a common set of EDMS/ERMS metadata in some shape or manner. Enterprises that founder on the path to integration will ultimately trace the causes of their difficulties to the lack of a shared map for EDMS/ERMS and the deficien-cies in metadata linking the two.