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.

Assume that an organization has decided it must have electronic records management systems (ERMS) capability. Records managers, information technology (IT) managers, attorneys, and executives have examined the costs and benefits of continuing to keep records in physical format 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 managers confer and discover these basic realities:

1. Integration: An ERMS does not generate records, for the most part. Records come from other applications in the organization. Assuming it has examined the marketplace 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 certification attesting that their product meets the requirements of 5015.2. M1 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 predominant in the United States. In most contexts, 5015.2 ensures that purchasers acquire a product that contains certain basic records management functionality.

3. EDMS Standards: Standards for electronic document management systems (EDMS) are less formalized than ERMS standards. For example, ODMA--the Open Document Management API (applications program interface)--is an open, voluntary industry de facto standard. In practice, purchasers 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 functionality. 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 committee is comprised of representatives from ARMA International, federal agencies including the National Archives and Records Administration, representatives from software vendors and systems integration 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 management (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 publishing, digital asset management, electronic forms management, and many other IT applications. Each of these IT applications may generate records that are destined 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 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 pursuit 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 for a comprehensive set of "best practices" in EDMS/ERMS integration.

In 2004, the committee completed its first technical report, Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems (ANS/AIIM/ARMATR48-2004). For its first technical report, the committee settled on a framework that would set forth the basic conditions for EDMS/ERMS integration. The framework is by no means definitive or exhaustive. 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 management 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 management of electronic and non-electronic records contained in an IT system using computer equipment and software according to accepted principles and practices of records management.

* 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 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 underlie IT systems, defining common terminology and concepts that allow the architectures of existing and future systems to be described and compared. The reference model provides a conceptual and functional framework 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 special 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 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:

* EDMS and ERMS share common functionality

* EDMS and ERMS share common metadata

The reference model above (Figure 1) illustrates the shared map of an integrated 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 elements must be compared, and potential areas of integration must be identified. Both EDMS and ERMS environments have functional and technical components that are similar or identical. This is true of repository management, database support, application modules, and functional processes. However, the sharing or co-ownership of data, potentially both application and object metadata, as well as actual electronic objects, is typically required for two systems to operate in an integrated manner.

[FIGURE 1 OMITTED]

The model and its components are intended as an illustrative example. It is not definitive, exhaustive, or intended to imply a chronological order. That is to say, each enterprise may choose to identify the top-level components and component 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 essential for integrated EDMS/ERMS.

Metadata, the central oval in the figure, can be thought of as the common language 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 activities that comprise each model component and indicates whether a particular activity occurs in an EDMS, an ERMS, or both. For example, under "Content Creation and Capture," the first component 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 generating content automatically. Content may be enhanced by linking it to other sources, annotating, editing, and translating 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 environment. Copies of records may be retrieved into an EDMS in order to create new content or aggregate content into new documents and new records. Both documents and records may be translated and formatted, 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 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 permits 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 aggregated in order to create new documents. 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 documents to EDMS and ERMS.

Metadata

In the broadest sense, metadata can be used to describe the core set of elements 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 applications in order for integration to occur. It is essential to the management, accessibility, and security of electronic documents and records common to all businesses and organizations. In managing electronic information, the capture of appropriate metadata must be integrated into the process of creating and maintaining the document or record in 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- consists 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, description/abstract, document type, format/ application, from/sender/originator, key words, language, location, media type, office of origin, origination organization, publisher, rendition number, version number, relationships/links, signed by/signator, source, status, subject, title, to/ addressee/cc/bcc, unique identifier, user-defined fields, and vital record indicator

2. Access Controls--consists of accessibility, rights, security classification, 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 enterprise-wide metadata, the next step is to acquire the software systems necessary to achieve EDMS/ERMS capability. The following three general approaches come from the viewpoint of both contemporary 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.

[FIGURE 2 OMITTED]

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 platform implementing the integration.

Documents in the EDMS are declared and classified as records directly 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. Enterprises 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 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 management system to store the data necessary for each system independently of the other. Tightly integrated solutions share the same database resource.

* Dual repositories: Each product typically 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 product 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.

[FIGURE 3 OMITTED]

In this approach, the EDMS/ERMS user interface is integrated, as is the repository/server architecture. Typically, a single vendor or vendor partnership supplies the integration for commercially 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, maintenance, 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 incorporates 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 application in which it was created. Figure 4 below shows this approach.

[FIGURE 4 OMITTED]

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 interface is provided by the records-enabled business application. The EDMS has its own user interface and repository/server architecture. A "back-office" ERMS repository/server architecture manages records objects in the EDMS' repository/server architecture.

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 considerably less network traffic.

* Each application server requires application integration.

* Records protection becomes a function of the application and organization 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 disappearing 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 systems span a wide spectrum: financial management, human resources management, litigation support, image management, CAD-CAM, and many others.

The message of TR48 is that any enterprise successfully achieving an integrated EDMS/ERMS will go through the processes of creating a common EDMS/ERMS reference model and developing 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 deficiencies in metadata linking the two.

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.CombinedQueryResult?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).

TABLE 1 Content Creation and Capture: Component Details

                                                   Occurs     Occurs
Activity                Description                in EDMS    in ERMS

1. Define content       Define what content           X
                        consists of

2. Convert paper        Capture/scan paper-based      X          X
   content              information into digital
                        format

3. Create or receive    Compose document content      X      X (receive
   content              or receive document                    only)
                        content from elsewhere

4. Capture e-mail       Import/save e-mail            X          X
                        messages and attachments

5. Generate content     Invoke established            X
   automatically        devices to provide
                        previously created/
                        received content

6. Link content         Associate present             X          X
                        content with other
                        information sources

7. Annotate content     Annotate a document,          X
                        including the
                        association of that
                        annotation with the
                        document

8. Edit content         Add to, delete from, or       X
                        otherwise modify content

9. Translate content    Render content in a           X
   (language)           language other than the
                        source language

10. Version content     Alter created/received        X
                        content enough that it
                        is considered a
                        different version

11. Transform content   Render content by             X
    (renditions)        transformation such as
                        changing text to
                        presentation slides

12. Format content      Change the physical           X
                        appearance/arrangement
                        of content or computer
                        format (e.g., RTF,
                        ASCII, etc.)

At the Core

This article

* introduces the 2004 technical report, Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems

* explores the reasons for integrating EDMS and ERMS

* discusses three approaches to integrating EDMS and ERMS

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 systems 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 integrated 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 [e-mail]. The 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 teleconference, 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.

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 [e-mail].