The importance of architecture in ERM software selection: here are five elements that can help organizations establish well-defined and robust management of all content.

[ILLUSTRATION OMITTED]

When considering electronic records management (ERM) software products, records managers tend to focus on their functionality. However, all ERM products perform approximately the same functions. Their true differences lie deep within their design--in their architecture. Understanding those differences can inform ERM software selection decisions, but--more importantly--it can affect an organization's overall strategy for managing electronic records because a product's architecture will help determine what is possible, at what cost, and in what timeframe.

ERM Functionality

All ERM software products provide basic functionality that allows organizations to

* Declare records

* Classify records and attach retention periods

* Store records

* Search and retrieve

* Enforce retention and disposition

* Place and process tax, legal, or other holds

* Maintain retention rules

* Produce reports

To perform these functions, the ERM software is concerned with four important components:

1. The electronic records themselves--which must be kept secure and protected against unauthorized access so their integrity and authenticity are preserved

2. Metadata--which manages information about the records that is crucial for their control. For example, metadata would include attributes that identify a record, as well as a date from which to calculate retention.

3. A classification scheme--which provides categories for keeping similar records together. Often called a file plan, the classification scheme may also assist in limiting access to certain types of records, and it may provide a mechanism for placing legal or other holds on certain classes of records.

4. Records retention rules--which govern how records are managed. Retention rules are the expression of the organization's policy regarding its records.

How each ERM software product handles these components, as well as how it interfaces with other software applications, form the basis for its architecture.

Architecture Defined

Simply put, an architecture is the conceptual description of how a system works. At the basic level, architecture describes the components the system comprises. Other levels describe what these components do and how they interact.

In the ERM world, architecture models must consider how the ERM software product interacts with various electronic source applications that contain the records to be managed. Source applications can include office applications that produce electronic documents, document or content management systems that may have their own metadata and document stores, and enterprise databases that manage structured data in rows and columns. It is the combination of ERM software with source applications that delivers solutions for managing electronic records.

An ERM software product's architecture has implications in many organization areas. From an information technology perspective, architecture can affect overall system cost, system scalability, and the resources and time required for its installation, integration, and maintenance. Records managers and business users can be affected by architecture in areas such as system speed and ease of use. When considering ERM software products, it is important to be able to differentiate among architecture models and to recognize each model's implications for what will be required to manage electronic records effectively.

ERM Architecture Models

ERM architecture models are defined by whether the components--that is, the records, metadata, classification scheme, or retention rules--reside in the ERM product, in the source applications, or in both.

There are basically four architecture models that describe current ERM software products. Each model has been named to reflect the way it approaches electronic records management elements. Figures 1 through 4 provide graphic representations as an aid to understanding differences among models, and figure 5 is a summary of the differences among models.

Each architecture model has tradeoffs for records managers, and these are discussed within the model's description. More importantly, however, each model has implications for an enterprise's business strategy, information technology, and risk response abilities, and these are discussed in succeeding sections.

1. Single Repository Model--In this model (see figure 1), all components of records management are kept within one system--the ERM software. Records and metadata move out of source applications to the ERM software's repository and database, respectively. This is an approach favored by many early ERM software products, most likely in response to the DoD 5015.2 requirement (based on archives theory) that records are more secure if they are retained in a protected repository.

The trade-off is that moving the records and metadata to the ERM software may make them inaccessible and unsearchable from within the source application, a situation that is not popular with end-users. Document management systems, for example, generally have better search capabilities than ERM products. Also, moving documents to the ERM system may actually compromise security because many document management systems have better security capabilities than do ERM products.

2. Replicated Model--In a replicated approach (see figure 2), classification scheme and retention rules are maintained within the ERM software, but records and metadata are essentially copied and kept in both the ERM software and the source application. This creates a burden on the organization to keep records and metadata synchronized in both places to ensure that both systems contain exactly the same information at all times. This can be difficult, particularly where versioning of electronic documents occurs in document management systems. The implication is that the ERM system's records repository could contain a different version of the record than resides in the document management system's repository, leading to questions about which repository contains the official record.

3. Catalog Model--In a catalog model (see figure 3), records remain in the source application repository, but metadata about the records is kept in both the source application and the ERM software system. While this is something of an improvement over the replicated model, the difficulty for the organization is in ensuring that metadata is always synchronized between the two applications. Changes, additions, or corrections made to metadata in the source application would not necessarily be reflected in the ERM system unless, and until, some synchronization routine is run on a regular basis. Unsynchronized metadata can mean that searches conducted in both the ERM system and in the source applications would not produce the same results.

[FIGURE 1 OMITTED]

[FIGURE 2 OMITTED]

[FIGURE 3 OMITTED]

4. Delegated Model--In a delegated model, (see figure 4), sometimes referred to as a federated approach, records and metadata remain in their source application, but the ERM software acts as an engine to associate a classification scheme and retention rules with the records. While this approach prevents the burdens associated with synchronizing records or metadata in two different systems, it has one significant implementation requirement: in order to work, the native or source application must be able to accept an application programming interface so the ERM system can overlay its classification scheme and retention rules on the source application. Older, mainframe-based systems may not be able to do this.

A summary of architecture models appears as figure 5.

ERM Architecture Models and the Enterprise

Most software selection processes involve considering a particular department's functional requirements along with some standard technical requirements and considerations. ERM systems, on the other hand, require organizations to take an enterprise approach to be successful. Because electronic records governance requires an understanding of business strategy, information technology, legal, and compliance needs, ERM product architectures affect how--or if--solutions will be possible for a wide range of issues including:

* Business Strategy Issues

--Outsourced systems

--Multiple model coexistence

* IT Issues

--Size/scalability

--Application integration

--ERM system programming

--Record/metadata synchronization

--Application programming

* Risk Response Issues

--Search ease

--Search speed

--Record retrieval speed

--Hold processing ease

[FIGURE 4 OMITTED]

[FIGURE 5 OMITTED]

Business Strategy Issues--Although it may not be obvious at first, there are global business strategies that present issues for ERM product installations. One is system outsourcing. While many companies outsource systems based upon return on investment expectations, they are not absolved from responsibility for the outsourced records. Can the records or metadata in outsourced systems be replicated if an ERM product architecture requires it? Beyond that, can the systems communicate to exchange classifications, retention rules, holds, and retention trigger events?