Return to the Toolkit for Managing Electronic Records

FBI Records Management Architecture:
Business Concept of Operations

Executive Summary

  1. Introduction.   Read this section to learn about implementing RM automation improvements as a critical component of the overall IT improvement initiative. Topics covered include:  1.1   Records Management Strategic Goal;  1.2   Records Management Division Organizational Structure and Mission; and, 1.3   Objectives of the Business Concept of Operations.

  2. Records Management Lifecycle.  Read this section to learn about the lifecycle of a record: creation, maintenance and use, and disposition.

  3. Records Management Conceptual Model
    Read this section to learn about the FBI’s overall objective to identify, acquire, and deploy a fully integrated application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records.  Topics covered include: 3.1   Metadata Capture; 3.2   Alignment with EA Service Layers; and 3.3   Next Steps

  4. Assumptions and Constraints.  Read this section to learn about this section the assumptions that affect the development and operation of the RM application and the constraints imposed on the design, development, and operation of the application because of conditions beyond the control of the project.  Includes: 4.1   Assumptions and 4.2   Constraints.

  5. Justification for Changes.     Topics covered include: 5.1   Correlation of Records Management and IT Lifecycle.(LCM); 5.2   Vital Records/Continuity of Operations Benefits; and, 5.3   Electronic Recordkeeping Benefits

  6. Technology Overview. Topics covered include: 6.1   Document and Records Management; 6.2   EDMS and ERMS Similarities and Differences; 6.3   Integrated EDMS and ERMS; and 6.4   Information Infrastructure Enabled by Metadata Capture.

LIST OF FIGURES

Figure 2-1.  Alignment of FBI Mission, Priorities, and Business Areas
Figure 2-2.  Records Management Lifecycle
Figure 2-3.  RMA Conceptual Model
Figure 2-4.  Metadata Capture Scenarios
Figure 2-5.  RMA Integration with FBI EA
Figure 2-6.  FBI IT Lifecycle Management Program

LIST OF TABLES

Table 2-1.  RMA Capability to Service Layer Mapping
Table 2-2.  IT Lifecycle Management Phases

LIST OF APPENDIXES

Appendix A:  Functional Requirements
Appendix B:  Stakeholders Interviewed
Appendix C:  References
Appendix D:  Glossary of Terms
Appendix E:  Acronyms
Appendix F:  FBI EA Principles
Appendix G:  FBI Metadata Requirements

Executive Summary

The senior leadership of the Federal Bureau of Investigation (FBI) recognizes the critical link between accomplishing the Bureau’s missions and effectively managing the organization’s records. The strategic goal for Records Management (RM) is to establish a state-of-the-art recordkeeping system. This Business Concept of Operations (ConOps) describes the conceptual model for that system.

Current System and Situation.

The FBI’s current recordkeeping system is paper-based and decentralized. This makes the RM lifecycle a costly and inefficient process. The FBI uses hundreds of computer applications that can produce records. The decentralized, stove-piped maintenance processes for these applications can cause significant delays in records processing and retrieval, make internal and external information sharing difficult, and impede the ability of employees to do work. Most FBI systems that generate records are not capable of identifying records eligible for transfer or destruction based on records retention schedules and disposition instructions. In this case, records disposition depends on manual processes from FBI employees. Currently, there are no enterprise-wide capabilities to export records and metadata in a format acceptable to the National Archives and Records Administration (NARA) or to maintain a record of all transfers and destructions.

Justification for Change.

Since 9/11, the FBI has been changing from a reactive organization to one that is more proactive. Currently, the number one priority of the FBI is to prevent the next terrorist attack. In this new environment, efficiency is paramount and the FBI cannot afford unnecessary delays in the management of information. The shortcomings of the current paper-based, decentralized system translate into additional costs and decrease the effectiveness with which the FBI operates. Sound records management accountability is essential to support the FBI’s mission.

Benefits.

 In addition to protecting vital records and helping to ensure Continuity of Operations, there are significant benefits that can be achieved by managing records electronically. Higher quality and more current information can be accessed to support more efficient and effective work processes. Potential benefits include more consistent development and maintenance of institutional knowledge, increased collaboration across the enterprise, faster decision-making and responsiveness to change, improved public service quality, more effective management of information as an asset, enhanced promotion of organizational learning and understanding, and reduced cost of operations.1

In addition, as the rate of Information Technology (IT) change accelerates, there are increasing concerns about the government’s ability to manage and preserve its records and to meet accountability and archival obligations. Using an enterprise Records Management Application (RMA) that is integrated within the Enterprise Architecture (EA) can address specific concerns such as preventing the loss of records that should be kept for legal and accountability purposes, achieving confidence in the authenticity and reliability of records, eliminating confusion between record versions, maintaining context to understand records properly, and controlling and planning for technological change that could make records inaccessible or incomprehensible.2

RM Conceptual Model.

 The FBI’s overall objective is to identify, acquire and deploy an application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. To achieve this objective, the FBI has developed an enterprise RM model that provides the framework for storing, accessing, and managing the FBI’s documentation, regardless of format, media, source, or location. In this model, an enterprise RMA will provide lifecycle management of the Bureau’s records.

From the user perspective, employees with the proper authorization will have access to FBI electronic records and documentation at their desktop. This desktop access will provide a more robust, user-friendly environment to create, access, and share information. The capabilities will also include creation, receipt, processing, dissemination, use, storage and final disposition of records.

In the model, an RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications. The RMA and metadata repository will also support the FBI’s DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI’s Paper Repository. By capturing required metadata, all documentation that may be created or received through the FBI’s investigative or business processes can be electronically managed in a legally acceptable manner, while safeguarding privacy and other sensitive information.

To be successfully implemented and effectively used by the Bureau, the RMA must integrate with existing and future systems within the Target EA. The integration of records, documents, data, evidence, and Freedom of Information and Privacy Act (FOIPA) management in a single solution is key to achieving the FBI’s vision of efficient and effective document management. This integration will be more explicitly described during Task 3: System Concept of Operations and Task 4: Integrate with EA.

Top of Page

1. Introduction


The FBI is the principal investigative arm of the Department of Justice (DOJ). To carry out its responsibilities, FBI Headquarters in Washington D.C. leads and provides support services to 56 field offices, approximately 400 satellite offices, and 45 offices located outside the United States. The FBI has approximately 11,400 Special Agents and over 16,400 support personnel. Following the terrorist attacks of September 11th, the FBI proposed fundamental changes in its priorities and business processes. These changes and new priorities are transforming the FBI from reactive to proactive. To accomplish the transition, the FBI needs to continue to make improvements in its use of IT. Implementing RM automation improvements is a critical component of the overall IT improvement initiative.

1.1 Records Management Strategic Goal

To address these issues, the FBI has made RM a priority. The senior leadership of the FBI recognizes the critical link between accomplishing the Bureau’s missions and effectively managing the organization’s records. The stated strategic goal for RM is to establish a state-of-the-art recordkeeping system. This goal directly supports the Director’s tenth priority ("upgrade technology to successfully perform the FBI’s mission"). The new RM system must ensure that accurate records from all activities of the FBI are created, maintained, and disposed of in accordance with all legal requirements. In addition, this system must meet requirements for timely information sharing with other government agencies, be responsive to requests for information under FOIPA, and have unquestionable accuracy and integrity including the use of digital signatures.

Figure 2-1: Alignment of FBI Mission, Priorities, and Business Areas

FBI Mission/ Priorities/Business

(Double click image to bring up the full screen presentation.)

1.2  Records Management Division Organizational Structure and Mission

The Records Management Division (RMD) was re-commissioned by the Director in February 2002 and is responsible for the overall RM program, with specific emphasis on identifying the requirements necessary to move the FBI from a paper-intensive organization to as paperless an organization as possible. The RMD is responsible for ensuring that official records are created, made available to the right people, when needed, for appropriate reasons, and then disposed of properly when their usefulness to the FBI has ended. In addition to a Front Office that consists of an Administrative Unit, Executive Secretariat, and Security Unit, the RMD contains a Records Policy and Administration Section (RPAS), a Records/Information Dissemination Section (RIDS), and a Records Automation Section (RAS).3 The RAS is responsible for assisting the FBI in its transition from a paper-based recordkeeping system to an electronic recordkeeping system.

1.3 Objectives of the Business Concept of Operations

The primary objectives for the RM Architecture Project are to develop a Business ConOps and a System ConOps as the basis for implementing an RMA within the EA. These documents can be used to generate consensus on the role of an RMA, identify possible obstacles to implementation and how they can be resolved, and specify the broad business and technical requirements for acquiring an RM application.

This Business ConOps provides an overview of the vision for how the application will fit within the environment and be used. The document references the framework, layers, and models used in the EA. The integration of the RM architecture with the EA will be more fully and explicitly described during Task 4 (Integrate with FBI Enterprise Architecture). By integrating the RM architecture with the EA initiative we will provide traceability from and to the high-level business goals and processes.

2. Records Management Lifecycle


The lifecycle of a record is: creation, maintenance and use, and disposition. In the first phase, a record is created when it is declared a record or captured as a record. Next, the records are maintained or used actively or inactively by the FBI until final disposition. In the disposition phase, the record is either destroyed or deleted according to schedule or legally transferred to NARA to be archived. The Records Management lifecycle is depicted in Figure 2-2.

Figure 2-2: Records Management Lifecycle

(Double click image to bring up the full screen presentation.)

Top of Page

3. Records Management Conceptual Model


The FBI’s overall objective is to identify, acquire, and deploy a fully integrated application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. With respect to the end-user, the goal is to give the FBI’s personnel a more robust, user-friendly environment to create, access, and share information, thereby completing work more efficiently and accurately.

FBI employees with the proper authorization will have access to FBI electronic records and documentation at their desktop and will be able to capture records from FBI applications with minimum intrusion on their normal work processes. Most of the RM aspects will be transparent to the end-user because they will be incorporated into normal workflow routines. The RMA will be integrated into the desktop operating environment to provide users with instant access to meaningful information about how they can identify official records and evidence through both on-line and browser-enabled transactions. Users will be able to view records, even if the FBI no longer supports the program that created the records.

In this environment, the RMA will provide an integrated electronic document and records management solution capable of managing the full range of FBI documentation, including electronic and paper documents and records, evidence, images, video and sound, and other information objects in a variety of formats. The RMA will facilitate desktop capability for the creation, receipt, processing, dissemination, use, storage, and final disposition of records. The RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications.

Figure 2-3: RMA Conceptual Model
 

RMA Conceptual Model

The RMA and metadata repository will also support the FBI’s DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI’s Paper Repository. For access to physical records, employees will request and gain access using a single streamlined process minimizing complexity, time, and cost.

This conceptual model provides the framework for storing, accessing, and managing the FBI’s documentation, regardless of format, media, source, or location. The RMA enabled by the metadata repository will provide lifecycle management of the Bureau’s records. The long-term vision is that most FBI electronic records will be stored in a central content repository. However, even in the near and medium-term, the RMA can provide central control of all FBI records through the metadata repository.

3.1 Metadata Capture

The main driver of success for the enterprise RM system will be the successful capture of required metadata. Bureau metadata requirements have already been identified by RMD (Appendix G). These metadata requirements need to be incorporated during the requirements phase of the IT Lifecycle Management for any application that will not fully integrate with the RMA. Integration with the RMA is the preferred capture method because RM software that meets the Department of Defense standard DoD 5015.2 automatically appends metadata to electronic information when the information is either saved or sent. Metadata will be required for all electronic information that has the potential to become a record in the future.

Figure 2-4: Metadata Capture

(Double click image to bring up the full screen presentation.)

In all three scenarios, metadata capture is the key to effective RM. Most records will eventually fall under Scenario 2. The FBI should continue to migrate in that direction with progressively fewer records being generated in paper form or managed by the redundant capabilities provided by ERKC applications. In the short to medium term, this conceptual model provides a realistic view of how Bureau records will have to be managed. The transition to this conceptual model will be described in more detail in Task 5: Transition Strategy.

A browser-based template will be used when automatic metadata capture is not possible. The template will be populated with existing Bureau information including the Classification Number, Classification, Program, and associated security and access codes. The disposition authorities currently in Microsoft Word will be used to set the length of time for retaining business information, and provide legal authority for keeping, transferring, or destroying business information at the end of the retention period.

The file categories will be organized by the Program/Program Codes section of FBI Investigative Classifications. The taxonomy will be based on the Federal Register Thesaurus with the terms organized into a subject tree. Using the browser template, responsible business program managers will address the topics within their purview. At a minimum, the responsible program manager will verify the security and access restrictions for the file topics and crosswalk the topics to not more than four of the topics from the subject tree of the Federal Register Thesaurus.

Using the completed templates, the RMA will be programmed to automatically complete as many of the metadata fields as possible. The Enterprise Architecture Performance Reference Model identifies the sign-off junctures in business process. These are the junctures where electronic information becomes official record and the mandatory metadata will be appended.

The RMA search tool will provide for the intelligent storage and rapid retrieval of documents and records. When processing user queries, the search tool will verify user access to determine which information, servers, and directories to search; use the metadata associated with the electronic information to identify and organize search results; provide full search results with drop down lists of categories of information pertinent to the query; and produce only information that the user is authorized to access.

With this metadata model in place, the RMA can electronically manage all documentation that may be created or received through the FBI’s investigative or business processes in a legally acceptable manner, while safeguarding privacy and other sensitive information.

3.2 Alignment with EA Service Layers

In the Target EA framework, a Service Layer is the collection of business oriented service categories that align service/component capabilities to a level in which they support the objectives and performance of the business components. A Service Component/Capability is a business-driven, functional capability that assists an organization with mission accomplishment and/or performance objectives. A Component-Based Architecture is a series of Service Layers that break down critical business functions to technical competencies. These competencies are then mapped to specific applications, processes, capabilities, and controls to create an overall logical view of an enterprise.

The initial concept for the FBI’s Component-Based Architecture has identified seven primary Service Layers: Security Services, Records Management Services, Network Services, Mission Support Services, Data Services, Legacy Integration Services, and Information Sharing Services. Each Service Layer will then be aligned to specific capabilities from the OMB Service Component Reference Model. In the FBI’s initial framework, the capabilities provided by the RMA generally fall under the Records Management Service Layer. However, some capabilities are more accurately aligned with other Service Layers including Mission Support, Data, and Information Sharing Services. An illustrative model is provided in the figure below.

Figure 2-5: RMA Integration with FBI EA

RMA Integration with FBI EA

As the figure above illustrates, the RMA capabilities are included in multiple Service Layers. A high-level mapping is presented in the table below.

RMA Capability to Service Layer Mapping

Service Layer RMA Capability/Function*
Records Management Capture – providing check-in capability through a system interface (i.e., the capability to manage records from their point of creation in other applications).

Classification – providing structured and controlled metadata to ensure more precise retrieval of information.

Version Control - uniquely identifying each information object and, once designated as a record, rendering it unalterable. Providing unique identifiers and links back to the original for changed or revised information objects.

Access and Retrieval - on-line searching and access to both physical archives and electronic records. Providing capability to display a list of "hits" resulting from searches. Ability to request physical records from the Paper Repository. Ability to track the progress and current location of records through bar-code technology.

Retention, scheduling, and disposal – capability to track and schedule as established in retention plans and disposition schedules. Capability to transfer archive records to NARA in acceptable formats.

Security Adequacy and authenticity of records - protecting against unauthorized alteration. Ensuring authentic, reliable, complete, unaltered and useable records. Ensuring legal sufficiency, trustworthiness, and non-repudiation.

Access controls – maintaining Access Control Lists (ACLs) at the user, role, and group levels.

Auditing – providing retrieval history by tracking all access to records including the requestor, time requested, time completed, and date.

Digital signatures – capturing electronic signatures that include who signed the record and approved the content, dates, and other identifiers.

Mission Support Workflow - capability to graphically manage the flow of work. Provides functionality to manage ad hoc workflows, standard procedures, and complex processes incorporating decision branching and parallel flows. Ability to perform actions such as identifying the process users want to create or breaking down existing processes; creating tasks with action, due dates, costs, start conditions and dependencies; routing documents to the appropriate persons for action and tracking response times; creating relationships between the workflow process and the relevant documents and/or records; and organizing tasks into standard procedures.

Search- provides for the intelligent storage and rapid retrieval of documents and records based on matching key word, subject, author, and other data elements to metadata and content repositories. Capability to verify user access to determine which information, servers, and directories to search; use the metadata associated with the electronic information to identify and organize search results; provide full search results with drop down lists of categories of information pertinent to the query; and produce only information that the user is authorized to access.

Data Document imaging - transforming a paper document into a digital image.

Archiving – providing consolidated storage, access, management, and viewing. Moving documents from a network file system to an electronic archive.

Information Sharing Metadata capture – capturing structured data about data that describes or specifies characteristics that need to be known about data in order to facilitate searching and cross-indexing.

Document management – organizing and managing documents, routing documents, automating related tasks, and facilitating distribution. Core functionality includes library services (e.g., check-in and checkout, version control, and document security) and cross-repository searching.

Top of Page

* Includes most major capabilities but does not represent a comprehensive mapping of RMA functionality to Service Layers. Comprehensive mapping of RMA capabilities to the Target EA will be completed during the EA Integration task.

In this model, the Records Management and Security Service Layers are mutually beneficial. Accordingly, the Enterprise Security Architecture Unit Information Assurance Section (ESAU/IA) is working closely with the EA Program Office and RMD personnel to ensure that the FBI's information assets are made available to authorized users while being protected against misuse. As the Target EA develops, these groups will work together to ensure consistent management of security policy, awareness, access control, and monitoring and compliance. The strategy of including Information Assurance principles in the overall governance of the FBI's information enterprise will help safeguard the confidentiality, integrity, and availability of records.

3.3 Next Steps

The integration of records, documents, data, evidence, and FOIPA management in a single solution is key to achieving the FBI’s vision of efficient and effective records management. To be successfully implemented and effectively used by the Bureau, the RMA must be integrated with the Target EA. This integration will be more explicitly described during Task 3: System Concept of Operations and Task 4: Integrate with EA.

The application inventory conducted during the baseline EA phase provides an initial frame of reference for the scope and magnitude of this integration. During the Target EA development, redundant applications and capabilities will be identified and the Target EA application list will be refined. In addition to eliminating applications that provide redundant capabilities, some applications will be identified that will not be refreshed at the end of their normal lifecycle if the capabilities they provide can be provided by other applications. The remaining applications will be prioritized for a phased integration with the RMA. This phased integration will be described further in the Transition Strategy (Task 5).

4. Assumptions and Constraints


In this section we identify the assumptions that affect the development and operation of the RM application and the constraints imposed on the design, development, and operation of the application because of conditions beyond the control of the project.

4.1  Assumptions

Assumptions include:

4.2 Constraints

Constraints include:

5. Justification for Changes


All government organizations need to keep accurate records of business decisions and transactions to meet the demands of accountability. In the public services sector, there are specific accountability requirements as well as the need to comply with government regulations. Records are evidence of an activity or transaction that are created by the daily work in the government. They must be captured, managed, and safeguarded in an organized system in order to retain their value as formal records. In this section, we provide some of the justifications for the proposed changes.

The FBI is changing from a reactive organization, to one that is more proactive. Prior to 9/11, the FBI’s role as the principle investigative arm of the DOJ was more reactive in nature. Currently, the number one priority of the FBI is to prevent the next terrorist attack. In this new environment, efficiency is paramount and the FBI cannot afford unnecessary delays in the management of information.

The current RM processes are manual and time consuming. The system is based on maintaining paper documents in physical file folders at numerous different locations. This paper-based, decentralized system has significant shortcomings, which translate into additional costs and decrease the effectiveness with which the FBI operates and provides services to the public.

The following list highlights a few of the shortcomings in the FBI’s current RM system.

These are just a few of the shortcomings of the current RM system that highlight the importance of implementing a new system. In the past, these shortcomings were undesirable but tolerable. Today, these shortcomings could potentially hinder the FBI’s ability to proactively provide for the nation’s security.

5.1 Correlation of Records Management and IT Lifecycle Management (LCM)

To implement and maintain an enterprise-wide capability, RM requirements should be considered early in the FBI’s IT LCM. These requirements can be initially considered as early as the Concept Exploration phase. At a minimum, they should be considered during the Requirements Development phase and continually reassessed throughout the remaining phases of the lifecycle. This concept is illustrated in Figure 2-6.

Figure 2-6: FBI IT Lifecycle Management Program
 

If RM requirements are not considered during the IT LCM, expensive and timely modifications may have to be made to systems to meet the stated RM requirements. RMD personnel play an important role in this process. The focus of RM personnel needs to shift away from more traditional responsibilities such as records inventorying and disposition scheduling and towards advocacy, training, promulgation and monitoring of policy, and facilitating the inclusion of RM requirements during the LCM of new systems. The phases of the FBI’s LCM are listed in Table 2-2. It is important to ensure that electronic RM requirements are recognized in determining the functional requirements for new or upgraded systems. By giving records management a higher priority in the design and development of information systems, many of the problems seen in existing systems can be prevented from developing in the first place. Functional requirements can be built into the design and implementation of electronic systems more easily (and less expensively) than maintenance changes. Where new systems or modifications to existing systems are planned, there is an excellent opportunity to influence the requirements specification and design in ways that enable effective RM in the future.4

IT Lifecycle Management Phases

Lifecycle Phase RM Consideration
1 - Concept Exploration Determine if the concept adheres to RM principles.
2 - Requirements Development Ensure that appropriate records capture requirements are included
3 - Acquisition Planning Identify solution providers and establish funding.
4 - Source Selection Solicit, evaluate, and select the best solution provider.
5 - Design Validate approach to electronic records capture and begin test planning.
6 - Development and Testing Build and test solution components.
7 - Implementation and Integration Assemble & test the "whole", train users, and transition to operations.
8 - Operations and Maintenance Support on-going capture and protection of electronic records.
9 - Disposal Plan and execute the transfer or migration of records.

5.2  Vital Records/Continuity of Operations Benefits

Vital records are those records identified as essential for the continuing conduct of an organization’s business, including the re-creation of its legal status and determining the rights and obligations of its stakeholders. When integrating electronic document management and electronic record management functionality into an EA, it is necessary to identify the vital records of the organization and take steps to ensure those records are retrievable in the event of an emergency or disaster. The security of vital records must be a part of an organization’s continuity of operations plan. A fully integrated RMA that protects vital records and ensures continuity of operations is a major cost avoidance and risk management choice for an organization.5

5.3  Electronic Recordkeeping Benefits

There are significant opportunities and potential benefits to be gained by managing records and documents electronically. Higher quality and more current information can be accessed to support more efficient and effective work processes. Potential benefits include:6

As the rate of IT change continues to accelerate, there are increasing concerns about the government’s ability to manage and preserve its records and to meet accountability and archival obligations. Using an enterprise RM application that is integrated within the EA can address these concerns. Specific concerns that can be addressed include:7

Top of Page

6. Technology Overview


Providing a brief overview of the relevant technology can help establish a common understanding of terminology and concepts. This common understanding will be important as the Bureau moves towards the enterprise RM vision. In addition, any future FBI procurement efforts and evaluation of vendor responses will benefit from a clear understanding and proper use of the terms.

There are many classes of systems and products that help organizations manage records. Enterprise Content Management (ECM) is the most inclusive system. ECM is a comprehensive system for managing the information used and produced by an organization. There are eight technology components to ECM: Integrated Document Management (IDM), imaging, electronic records management, workflow, document archival and retrieval, forms capture, web content management, and digital asset management.

IDM software securely organizes and manages documents, routes documents, automates related tasks, and facilitates distribution. Core functionality includes library services (e.g., check-in and checkout, version control, and document security) and cross-repository searching. The term is often used interchangeably with Electronic Document Management System (EDMS) but in this context IDM covers a broader range of capabilities. Imaging, records management, work process, and document archive and retrieval are the most relevant technology component additions to IDM. The leading IDM vendors have expanded their offerings, either directly or through third party integration, to include all of these components.

6.1  Document and Records Management

With the advances in IT, most organizations will require an information management system that has both EDMS and Electronic Records Management System (ERMS) capabilities. These are closely related capabilities that support the management of electronic information in different, but complementary ways. They may be found in individual applications or in an integrated software package.

6.2  EDMS and ERMS Similarities and Differences

The following section presents some of the similarities and differences between EDMS and ERMS.8

6.3  Integrated EDMS and ERMS

An integrated system can manage and maintain/retain records according to established requirements. Many EDMS and ERMS functions overlap. Both systems can retrieve, view, and print documents or records. However, neither system completely satisfies the need for lifecycle management of documents. Combining EDMS functionality with ERMS requirements provides for the reuse of electronic information while ensuring the integrity and retention of the electronic records.

There has been an industry movement towards a shared repository approach and integrated functionality between EDMS and ERMS. A shared repository approach allows an organization to build a content management framework with a secure collaborative environment. The value of the information held in the shared repository is increased because it is made available for use in multiple enterprise applications.9 We believe this is the longer-term technical vision that FBI should follow and that we will describe in greater detail in the System ConOps.

EDMS and ERMS have a very important relationship to an organization’s EA. Integrating EDMS/ERMS with other software applications used by the organization is important for current operations and IT planning. EDMS and ERMS are important components of the EA and can be integrated within the enterprise environment to support strategic goals and initiatives.10

6.4  Information Infrastructure Enabled by Metadata Capture

Incorporating metadata capture into the creation and maintenance processes for records increases the benefits of electronic information management systems. Metadata literally means data about data. It is information about records and the record assemblies in which they reside. It is structured, descriptive, catalogue data that systematically identifies various attributes of a record.

Ideally, metadata is captured automatically in a manner transparent to the end user. Retrospective capture of metadata is undesirable, expensive, and sometimes infeasible. If metadata is not accurately defined and captured, the record can become disconnected from the context and sometimes incapable of being located. Failing to attribute the appropriate metadata during the records creation and maintenance processes severely limits the ability to retrieve records.11 Metadata can be separated from the documents or records it describes so that users can search metadata instead of the documents or records themselves. In addition, it can be processed and accessed when the actual document or record is not available.

Metadata capture is the key to an effective RM system. The Bureau is producing all forms of electronic media and hard copy but it is not classifying that information in any corporate subject hierarchy. Metaphorically, this would be like the Library of Congress having all the books on the floor with no way of tracking the location. The lack of metadata associated with documents severely restricts the ability to search for documents. Files cannot be located because there are no metadata to search, corporate subject hierarchy to browse, or indexing tool to enable keyword searches.

Top of Page


Appendix A: Functional Requirements12

Table of Contents

A.1.   Security and Authentication

A.1.1   Adequacy of Records
A.1.2   Authenticity

A.1.2.1.   Legal Sufficiency and Evidentiality
A.1.2.2.   Preserving Trustworthy Records
A.1.2.3.   Non-repudiation Services

A.2.  Records Management Lifecycle

A.2.1.   Registration/Capture
A.2.2.   Classification
A.2.3.   Version Control
A.2.4.   Access and Retrieval
A.2.5.   Retention, Scheduling, and Disposal

A.3.  Document Management

A.4.  Workflow

A.5.  Image Management

A.6.  Management of Data from Programmatic Systems

A.7.  E-mail Management and Management of Other Desktop Applications

A.8.  Evidence Management

A.9.  Performance

A.10.  System Administration

A.11.  Error Diagnostics and Recovery

A.12.  Reporting and Audit Trails

A.13.  Skills and Training

A.14.  Vendor Support

A.15.  System Certification

In this section we describe the specific functional operations that will be provided by the RMA. One of the main goals of the RMA from a functional perspective is to ensure that official documentation and evidence processed through Bureau applications are captured, protected, and preserved. The RMA will be certified as a Department of Defense (DoD) 5015.2 certified record management application. The RMA will ingest and manage records from legacy and current FBI systems. The RMA will be able to export records to NARA according to existing guidance.

A.1.  Security and Authentication

The RMA will provide functionality to help ensure that the Bureau’s records have adequacy, authenticity, and legal sufficiency and that the FBI preserves trustworthy, secure records.

A.1.1.  Adequacy of Records

To be complete and accurate, the FBI’s records must be authentic, reliable, complete, unaltered and useable and the electronic systems that support them must be able to protect their integrity over time.

Authentic - the FBI must be able to prove that a record is what it purports to be and that it has been created or sent by the alleged person and at the time purported. Therefore, the RMA will have the capability to protect records against unauthorized addition, deletion, alteration, use, or concealment. The creation, receipt, and transmission of records will be controlled to ensure that records creators are authorized and identified.

Reliable - the FBI must be able to trust the content of a record as an accurate representation of the transaction to which it attests. Therefore, the RMA will be able to capture a record immediately at its point of creation.

Complete and unaltered - the FBI must be able to protect a record against unauthorized alteration and to monitor and track any authorized annotation, addition, or deletion. Therefore, the RMA will have the capability to identify any additions or annotations that may have been made to a record after it was created, under what circumstances additions or annotations were authorized, and who was authorized to make them.

Useable - the RMA will provide the capability for the FBI to locate, retrieve, render, and interpret a record and understand the sequence of activities in which it was created and used for as long as the evidence is required.

System integrity - the RMA will allow the FBI to implement control measures, such as access monitoring, user verification, authorized destruction, and disaster mitigation to prevent unauthorized access, destruction, alteration, or removal of records and to protect them from accidental damage or loss. The application will have access and security controls to restrict unauthorized access and will record the associated activities. The RMA will allow authorized changes to classification with audit and tracking capabilities.

A.1.2.  Authenticity of Records

For the FBI’s electronic records to be acceptable, they must have integrity and authenticity. Therefore, the RMA will be able to preserve a record’s content, context, and structure. The recordkeeping requirements for individual business processes will determine what content, context, and structure of its records need to be preserved over time. The RMA will help ensure the integrity of those records once they are filed in the RMA for as long as they need to be retained.

A.1.2.1.  Legal Sufficiency and Evidentiality

The FBI’s records must meet several criteria in order to be legally sufficient to serve as evidence of a transaction, decision, or other activity. For an FBI record to be legally sufficient, the RMA must enable the FBI to demonstrate that the record was made at or near the time of the transaction, kept in the course of the regularly conducted activity, made by the regularly conducted activity as a regular practice, and remains unaltered since its filing (or that any change and the rationale for the change is captured as metadata).

A.1.2.2.  Preserving Trustworthy Records

The RMA will help ensure that FBI records remain reliable, authentic, and useable for as long as the record is needed. There are special considerations when dealing with electronically processed records that the RMA must be capable of meeting.

Content: Electronic signatures must be captured as part of a record’s content. These signatures indicate who signed a record, whether that person approved the content of the record, and may include dates and other identifiers.

Context: Some electronic signature technologies rely on individual identifiers that are not embedded in the content of the record, trust paths, and other means to create and verify the validity of an electronic signature. This information is important to the context of the record because it provides additional evidence to support the reliability and authenticity of the record.

Structure: The physical and logical format and the relationships between the data elements comprising the record need to remain physically and logically intact so that the complete record could be revalidated at a later time if needed. The RMA would need the capability to retain any encryption algorithms to electronically signed records.

A.1.2.3.  Non-repudiation Services

The RMA must have the capability to provide non-repudiation services. Non-repudiation is one of the essential security services in computing environments, being mainly applied in message handling systems and electronic commerce. There will be several FBI electronic transactions supported by the RMA (e.g., electronic approvals as a part of case management workflow, searching sensitive files, and requesting records from content repositories). The FBI will need the capability to provide acceptable evidence that the persons who performed the transactions were indeed the persons they purported to be. Password logs alone will not provide adequate evidence because they can be repudiated based on a claim of loss, theft, or unauthorized access to a terminal already accessed but unattended. However, any system that relies on passwords can be augmented to make it acceptable by including biometrics or tokens. On its own or in conjunction with other Bureau technologies, the RMA will be able to identify and authenticate users, authorize users to perform functions as required, preserve integrity of transaction content, and provide audit trail for all transactions.

A.2.  Records Management Functions

The RMA will be based on a DoD 5015.2 certified COTS product that provides the following functions either as part of the DoD certification or in addition to it. If the FBI already has deployed an enterprise solution for a specific function (e.g., the FBI may have acquired an image management package), the RMA will provide the option of interacting with the existing solution rather than providing redundant functionality.

The RMA will provide the capability to manage the official records. The RMA will manage the transfer of records to a records center maintained and operated by the FBI, regardless of media storage or other characteristics. The basic records management functionality required of Federal systems that capture and maintain Federal records are also described in the products of NARA’s Fast Track Guidance Development Project. For records management functionality, the RMA selected will have to provide all of the capabilities described in the DoD and NARA requirements. However, the following capabilities are of specific interest to the FBI.

A.2.1.  Registration/Capture

The application will provide users with check-in capability through a system interface (i.e., the capability to manage records from their point of creation in other applications) by use of a Universal Document Locator Number (UDLN) that will carry with it such information as classification, retention, and security access.

A.2.2.  Classification

Classification will be completed during check-in by providing structured and controlled metadata to ensure more precise retrieval of information.

A.2.3.  Version Control

The application will provide users with check-in capability through a system interface (i.e., the capability to manage records from their point of creation in other applications) by use of a Universal Document Locator Number (UDLN) that will carry with it such information as classification, retention, and security access.

A.2.4.  Access and Retrieval

The application will provide on-line searching of and access to both physical archives and electronic records. At a minimum, the RMA will provide the capability to display a list of "hits" resulting from searches. The list should provide sufficient information to identify and locate the document, and must include the document’s file type. The RMA also must allow users to request physical records from the FBI’s Paper Repository. The RMA shall provide the users with the browser capability to select (i.e., "double-click on") either "URGENT" or "NORMAL" and send a request by e-mail. For urgent requests the Repository staff will pull the record, scan it, and e-mail it to the requestor. For normal requests, the Repository staff will pull the record and ship it to the requestor. The RMA will track the progress and current location of the document through the use of bar-coding technology and workflow capabilities.

A.2.5.  Retention, Scheduling, and Disposal

Retention, scheduling, and disposal will be capable of being completed as established in the FBI’s records retention plan and disposition schedule. The transfer of archival records to NARA will be completed in formats they can accept.

A.3.  Document Management

Document Management will provide the capability to manage the production of documents in the FBI’s workflow, desktop, Web, and high-speed scanning environments. The document management capabilities will include providing an XML-authoring environment for multi-media, and the capability to manage the conversion of paper documents to digital format. The RMA will also provide document input and processing (i.e., creation, versioning, indexing, editing, saving, storing, creating a container, rendering, and deleting).

The application will provide for document retrieval and display (i.e., browsing, retrieving, checking in/out, and displaying). Display includes the requirement that documents can be viewed as they were created without changes to format or structure. The application will have document review and approval (i.e., annotation, workflow, and electronic signature) capabilities. Additional document management capabilities will include search (metadata fields and full text), storage and administration (configuring, auditing, reporting, maintaining user account base, creating access security rights, managing backup and recovery, printing, administering e-mail and fax integrations), and redaction.

A.4.  Workflow

Workflow will provide the capability to graphically manage the flow of work. It will provide functionality to manage ad hoc workflows, standard procedures, and complex processes incorporating decision branching and parallel flows. The workflow capability will be graphically oriented with simple objects for drag and drop as well as connection capability for simple construction of workflow charts to perform actions such as identifying the process users want to create or breaking down existing processes; creating tasks with action, due dates, costs, start conditions and dependencies; routing documents to the appropriate persons for action and tracking response times; creating relationships between the workflow process and the relevant documents and/or records; and organizing tasks into standard procedures. Procedures may have responsibility assigned to them. Overall responsibility may be assigned or specific tasks or sub-processes may be assigned down to the specific unit or individual.

A.5.  Image Management

Image Management will provide the capability to manage scanned images as individual documents that can be related to other documents and managed as a collection. The image management capability will manage multiple renditions of the image and will restrict access to the image if required. Image Management capabilities also include input interface from scanners and video/digital camera; conversion to digital formats (TIFF, or MPEG, or JPEG); creation of associated minimum profile data (metadata); automated indexing and profiling capability; management of images and their related OCR versions; storage of versions and multiple renditions of documents; and retrieval through full text, structured metadata, and object searches.

A.6.  Management of Data from Programmatic Systems

The RMA must be capable of controlling documents in the content repository and case management applications as well as documentation from other FBI programmatic applications such as the Laboratory Information Management System (LIMS) and the Electronic Surveillance (ELSUR) program. Using ELSUR as an example, ELSUR management means providing the capability to manage the documentation related to the collecting of raw data by the FBI’s ELSUR program, and the FBI’s subsequent analysis, transcription, production, and use of the data collected. Management includes all of the capabilities set forth in NARA’s Fast Track Requirements for electronic records management and electronic recordkeeping systems.

A.7.  E-mail Management and Management of Other Desktop Applications

E-mail management will provide the capability to distinguish, capture, and manage records sent through the FBI’s e-mail system. This will include the capability to differentiate among informal, in-process, serialized, and official documentation. While Electronic Communications at the FBI are routinely and formally serialized and uploaded to an existing Electronic Case File, records will probably continue to be created, disseminated, or received through e-mail. In other cases, records necessary to document Bureau activities may be created using desktop applications such as PowerPoint, Word, Excel, or other approved packages. If these records are not serialized, the RMA will provide the ability to file these documents as records with the required metadata. To ensure that these records are preserved, the RMA must provide the capabilities to:

A.8.  Evidence Management

Evidence Management will provide the capability to capture and track both electronic and paperwork processes and actions related to the management of evidence gathered by the FBI, including documentation of any laboratory processing or other analysis of the evidence. Additionally, the RMA will have the capability to allow the FBI to compile a composite record that captures and tracks all actions taken with regard to the evidence (preserving the who, what, when and where data) and linking it back to the evidence. For example, the RMA will be able to create a "chain of custody" record for any FBI evidence, relate back to a piece of evidence the results of any test performed on it, or link evidence to any case in which it was used.

A.9.  Performance

The RMA will support Trilogy users with 24x7 availability and provide a user-friendly interface. The application will contain comprehensive, user-friendly training/help support. The application will have backup and rebuild capabilities.

As the Target EA is developed, the FBI may need to consider developing additional performance requirements such as:

A.10.  System Administration

The RMA will be browser enabled and hardware independent to ensure long-term availability. The RMA will be deployed in an n-tier, client-server architecture, and integrate with Oracle, Microsoft, and other software supporting the FBI’s financial, personnel, high-speed scanning, and other business support systems.

A.11.  Error Diagnostics and Recovery

Additional performance requirements with regard to error diagnostics and recovery need to be developed. For example, availability requirements could include:

A.12.  Reporting and Audit Trails

The application will have auditing capabilities that provide for quality control, assurance of records authenticity and integrity, and support computer security. These capabilities will include maintaining retrieval history by tracking all access to records including the requestor, time requested, time completed, and date.

A.13.  Skills and Training

In the transition from paper-based to electronic recordkeeping, there is a shift in emphasis from direct management of the record as a physical artifact towards the design of the infrastructure in which the record is created, captured, and managed by a combination of the individual end user, software systems, and management procedures. For records management and IT staff, this shift in emphasis is likely to require a new range of records management skills to manage new kinds of systems in new contexts. For organizations, this involves the development of multi-skilled and multi-purpose project and operational teams that bring together a range of different skills and expertise.

In an electronic recordkeeping environment, new record-making skills are required of the end users as creators and users of records. They will have greater responsibility for correctly identifying and dealing with records in its earliest stages of creation. This will require a significant cultural change in attitudes and behavior towards creating and managing records.

The organization will be responsible for developing the record-keeping infrastructure, and providing policy, guidance, and training opportunities for the end user who creates and uses electronic records. Because the primary job of the end user creating electronic records is not recordkeeping, the recordkeeping process must be as transparent as possible for the end user. This lets the end user focus on the mission at hand, while records creation and management happen in the background.

There are different risks involved with electronic recordkeeping compared with the traditional paper-based system. If the end user does not properly carry out the correct action when creating a record, the record may be effectively lost, simple because it cannot be found. There are significant training implications for the implementation of enterprise-wide electronic records management and they must be taken into consideration in the transition process.13

A.14.  Vendor Support

The FBI should consider developing additional performance requirements that may also be tied to vendor support levels. Examples of these requirements could include:

A.15.  System Certification

The RMA will have to meet the ERKC requirements and relevant security requirements. The FBI may also want to consider developing certification requirements that address flexibility, expansion, design, and construction.

Top of Page


Appendix B: Stakeholders Interviewed

Name Title
William L. Hooton Assistant Director, Records Management Division
Harold M. Hendershot Deputy Assistant Director, Records Management Division
Dr. Michael Lee Miller Section Chief, Records Automation Section
Marie Allen Section Chief, Records Policy and Administration Section
Debra O’Clair Assistant Section Chief, Records Policy and Administration Section
Dr. Elizabeth Fugitt Unit Chief, Records Management Application Unit
Gerald Whitmore Unit Chief, Records Disposition Unit
William Burrows Unit Chief, Records Compliance Unit
Marilyn Moore Executive Secretariat
Kathy Meman Policy and Procedures Unit
Elaine Watson Records Management Centers Unit
Markus Most Records Management Application Unit
Teresa Sharkey Records Disposition Unit

Appendix C: References

This Appendix contains the list of previous work products and policy, process, technology, and other background documents that we referenced in preparing this document.

Electronic Recordkeeping (ERK) Draft System Certification Report Version 0.7, prepared by SRA International, Inc., May 6, 2004.

Draft Enterprise Architecture Principles, EA Program Management Office, no date provided.

RMA Metadata Comparison, September 28, 2004.

Recordkeeping Questionnaire for New and Redesigned Systems and Applications, no date provided.

FBI Electronic Recordkeeping Certification Manual Version 1.0, prepared by SRA International, Inc., April 30, 2004.

Basic Functional Requirements for Electronic Recordkeeping (ERK) for Automated Systems/Applications in the FBI, March 3, 2003 – Revised April 18, 2003.

Federal Bureau of Investigation, Enterprise Records Management Application, High-Level Functional Requirements, revised February 2003.

Government Computing News, "Beat the E-Records Glut: Agencies dig in to get control of a mounting pile of e-records", Walker, Richard W., September 27, 2004.

Government Computing News, "NARA prepares for a new era in records management", Miller, Jason, September 27, 2004.

Department of Defense, Design Criteria Standard for Electronic Records Management Software Applications, DoD 5015.2-STD, June 19, 2002.

Report on Current Recordkeeping Practices within the Federal Government, prepared by SRA International, Inc. for the National Archives and Records Administration, December 10, 2001.

National Research Council, A Review of the FBI’s Trilogy Information Technology Modernization Project, Computer Science and Telecommunications Board, National Academies Press, Washington, D.C., 2004.

U.S. Department of Justice Office of the Inspector General, The Federal Bureau of Investigation’s Implementation of Information Technology Recommendations, Audit Report 03-36; September 2003.

U.S. Department of Justice Office of the Inspector General,An Investigation of the Belated Production of Documents in the Oklahoma City Bombing Case, March 19, 2003.

U.S. Department of Justice Office of the Inspector General,The Federal Bureau of Investigation’s Management of Information Technology Investments, Audit Report 03-09, December 2002.

FBI Strategic Plan, 2004 – 2009.

FBI Draft Strategic Plan FY 2004-FY2010 – Version 0_10g (redacted)

RM Policy at FBI, no date provided.

The Information Technology Investment Evaluation Guide,"Assessing Risks and Returns: A Guide for Evaluating Federal Agencies' IT Investment Decision-Making", GAO/AIMD-10.1.13, February 1997.

The Office of Management & Budget (OMB) Memorandum 97-02, Funding Information Systems Investments, October 25, 1996. This memorandum is also commonly known as "Raines Rules."

OMB Circular No. A-11,Planning, Budgeting, and Acquisition of Capital Assets.

Uniform Subject Filing System (June 1995) and Public Law 98-497 (amended records management statutes by dividing responsibilities between NARA and GSA).

Records Disposal Act of 1943, as amended by the Act of July 6, 1945 (governs the disposal of records deemed to have insufficient value to warrant their further preservation).

Title 8 of the General Accounting Office (GAO) Manual for Guidance to Federal Agencies (describes GAO concerns with agency fiscal and program records and identifies those records whose proposed disposition must be approved by GAO).

44 U.S.C. parts 2904, 3101, and 3301, 36 C.F.R. parts 1220 and 1222 (establishes records management responsibilities at Federal agencies) and 36 C.F.R. parts 1230, 1232, and 1234 (electronic records).

RMD Section of Information Technology Strategic Plan (Word Document).

Records Management Division Organization and Administration Memorandum, February 5, 2003.

Public Record Office, United Kingdom, e-Government Policy Framework for Electronic Records Management, 2001.

Public Record Office, United Kingdom, Management, Appraisal and Preservation of Electronic Records, Vol. 1: Principles, 1999.

Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems, ANSI/AIIM/ARMA, TR48-2004, July 4, 2004.

What You Should Know About Enterprise Content Management, M. Gilbert, D. Logan, K. Shekda, G. Landers, and K. Chin, July 24, 2002, Gartner, Inc.

Records Management Architecture: Current State Evaluation, prepared by BearingPoint, Inc. for the Federal Bureau of Investigation, November 2, 2004.

Enterprise Architecture: Integrated Baseline Architecture Report Draft Version 0.1, prepared by BearingPoint, Inc. for the Federal Bureau of Investigation, October 13, 2004.

Top of Page


Appendix D: Glossary of Terms

Application. The software product that results from the creation of a program, often used as a synonym for the programming (source) code that creates it.

Archive and retrieval. Provides consolidated storage, access, management, and viewing. Documents are moved from the network file system to an electronic archive. The documents may be compressed and archived to "near-line" or "offline" storage. Near-line storage includes media such as CD-ROM. Tape backup is an example of offline storage.

Audit Trail. An electronic means of tracking interactions with records within an electronic system so that any access to the record within the electronic system can be documented as it occurs or afterward. May be used to identify unauthorized actions in relation to the records, e.g., modification, deletion, or addition.

Component Based Architecture. A series of Service Layers that break down critical business functions to technical competencies. These competencies are then mapped to specific applications, processes, capabilities, and controls to create an overall logical view of an enterprise.

Content. The subject matter of a document.

Context. The environment and web of relationships in which a document was created and used (for example, how a document relates to others in a group of documents.

Create. In electronic records, the action or result of filing a new record and its associated metadata.

Delete. The process of permanently removing, erasing, or obliterating recorded information from a medium, especially a reusable magnetic disk or tape.

Destruction. In records management, the primary type of disposal action. Methods of destroying records include selling or salvaging the record medium and burning, pulping, shredding, macerating, or discarding it with other waste materials.

Disposition. Range of processes associated with implementing retention, destruction, or transfer decisions. Those actions taken regarding records no longer needed for the conduct of the regular current business of the organization.

Document. Official records, personal papers, classified information in written form, other written materials, and copies thereof, regardless of form, content, or ownership. Structured units of recorded information, logical or physical, not fixed as records.

Electronic Mail Message. A document created or received on an electronic mail system including brief notes, more formal or substantive narrative documents, and any attachments, such as word processing and other electronic documents, which may be transmitted with the message.

Electronic Mail System. A computer application used to create, receive, and transmit messages and other documents. Excluded from this definition are file transfer utilities (software that transmits files between users but does not retain any transmission data), data systems used to collect and process data that have been organized into data files or data bases on either personal computers or mainframe computers, and word processing documents not transmitted on an e-mail system.

Electronic Record. Record or electronic storage media, produced, communicated, maintained and/or accessed by means of electronic equipment.

Electronic Recordkeeping System. An electronic system in which records are collected, organized, and categorized to facilitate their preservation, retrieval, use, and disposition.

Electronic Records Management. This technology enables an organization to assign specific life cycles to individual documents. The records can come from multiple channels including e-mail, Web pages, scanned documents, custom applications, fax documents, and paper. Most products can be used as stand-alones but they are usually matched with Integrated Document Management products.

Enterprise Architecture. A strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. An enterprise architecture includes a baseline architecture, target architecture, and a sequencing plan.

File. An arrangement of records. The term is used to denote papers, photographs, photographic copies, maps, machine-readable information, or other recorded information regardless of physical form or characteristics, accumulated or maintained in filing equipment, boxes, or machine-readable media, or on shelves, and occupying office or storage space.

Format. For electronic records, format refers to the computer file format described by a formal or vendor standard or specification. For non-electronic records, the format refers to its physical form.

Lifecycle. The records lifecycle is the life span of a record from its creation or receipt to its final disposition. It is usually described in three stages: creation, maintenance and use, and final disposition.

Media Type. The material or environment on which information is inscribed.

Metadata. Metadata is structured data about data; it is a term that describes or specifies characteristics that need to be known about data in order to build information resources such as ERK systems and support records creators and users.

Permanent Record. Any Federal record that has been determined by NARA to have sufficient value to warrant its preservation in the National Archives of the United States.

Recordkeeping Requirements. All statements in statutes, regulations, and agency directives or authoritative issuances, that provide general and specific requirements for Federal agency personnel on particular records to be created and maintained by the agency.

Recordkeeping System. A manual or automated system in which records are collected, organized, and categorized to facilitate their preservation, retrieval, use, and disposition.

Records. All books, papers, maps, photographs, machine readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business. Documents created, received, and maintained as evidence and information by an agency, organization, or person, in pursuance of legal obligations or in the transaction of business. Documentation of the organization, functions, policies, decisions, procedures, and essential transactions.

Records Capture. The recognition of a record resulting in its inclusion in a system that manages records operations.

Records Center. An establishment maintained and operated by the Archivist or by another Federal agency primarily for the storage, servicing, security, and processing of records which need to be preserved for varying periods of time and need not be retained in office equipment or space.

Records Maintenance and Use. Any activity involving location of records of a Federal agency or the storage, retrieval, and handling of records kept at office file locations by or for a Federal agency.

Records Management. The field of management responsible for efficient and systematic control of the creation, receipt, maintenance, use and disposition of records, including processes for capturing and maintaining evidence and information of business activities and transactions in the form of records.
Alternative definition: The planning, controlling, directing, organizing, training, promoting, and other managerial activities involved with respect to records creation, records maintenance and use, and records disposition in order to achieve adequate and proper documentation of the policies and transactions of the Federal Government and effective and economical management of agency operations.

Records Management Application. Software used by an organization to mange records. An RMA’s primary management functions are categorizing and locating records and identifying records due for disposition. RMA software also stores, retrieves, and disposes of electronic records stored in its repository.

Records Retrieval. The process of recalling specific records from storage.

Records Schedule or Schedule. (a) An SF 115, Request for Records Disposition Authority, that has been approved by NARA to authorize the disposition of Federal records; (b) A General Records Schedule (GRS) issued by NARA; or (c) A printed agency manual or directive containing the records descriptions and disposition instructions approved by NARA on one or more SF 115s or issued by NARA in the GRS.

Records Series or Series. File units or documents arranged according to a filing system or kept together because they relate to a particular subject or function, result from the same activity, document a specific kind of transaction, take a particular physical form, or have some other relationship arising out of their creation, receipt, or use, such as restrictions on access and use.

Records Storage Facility. A records center or a commercial records storage facility, as defined in this section, i.e., a facility used by a Federal agency to store Federal records, whether that facility is operated and maintained by the agency, by NARA, by another Federal agency, or by a private commercial entity.

Records Systems. Information systems that capture, maintain, and provide access to records over time.

Referential Integrity. Ensuring that all references are updated or deleted as necessary when a key reference is changed in a database environment.

Repository of Electronic Records. A direct device on which the electronic records and associated metadata are stored.

Retention Period. The time period records are kept according to operational, legal, regulatory, and fiscal requirements.

Scanning. Imaging is a form of scanning technology that refers to transforming a paper document into a digital image. Capturing and processing information contained in forms is another application of scanning technology. When a form is scanned, key fields are captured, verified, and written to a database. Forms capture relies on OCR, bar code recognition, and other recognition technology to capture the content.

Scheduled Records. Records whose final disposition has not been approved by NARA.

Service Component/Capability. A component (or capability) is a business-driven, functional capability that assists an organization with mission accomplishment and/or performance objectives.

Service Layers. The collection of business oriented service categories that align service/component capabilities to a level in which they support the objectives and performance of the business components.

Storage. Measures for keeping records under defined conditions and permitting their retrieval.

Structure. The use of headings and other devices to identify and label parts of a document, and the use of visual emphasis (emboldening, italics) to convey part of the meaning of the content.

System. An integrated aggregation of end items, interfaces, and support functions designed to fulfill a specific mission requirement. A system may include equipment, trained personnel, facilities, data and procedures, and software. For project purposes, a system is typically defined as the highest level of hardware organization composed of multiple subsystems. The term is also used to describe a disciplined and consistent approach to accomplish a task (e.g., a failure reporting system).

Temporary Records. A temporary record is any record that has been determined by the Archivist of the United States to have insufficient value (on the basis of current standards) to warrant its preservation by the National Archives and Records Administration.

Unscheduled Records. Records whose final disposition has not been approved by NARA.

Vital Records. Essential Bureau records needed to meet operational responsibilities under national security emergencies or other emergency or disaster conditions (emergency operating records) or to protect the legal and financial rights of the Government and those affected by Government activities (legal and financial rights records).

Work process management. This technology is also referred to as workflow, work management, and process automation software. These tools automate processes and the interrelationship between sub-processes, tasks, participants, and management. Most IDM software includes some workflow functionality (e.g., review/approval routing and e-mail notification). If additional processing and control features are needed, some vendors integrate well with third-party workflow packages.

Top of Page


Appendix E: Acronyms

Acronym Meaning
ACS Automated Case Support
AD Assistant Director
ConOps Concept of Operations
COTS Commercial of the Shelf
DocLab Document Conversion Laboratory Unit
DoD Department of Defense
DOJ Department of Justice
EA Enterprise Architecture
ECM Enterprise Content Management
EDMS Electronic Document Management System
ELSUR Electronic Surveillance
ERK Electronic Recordkeeping
ERKC Electronic Recordkeeping Certification
ERMS Electromic Records Management System
ESAU/IA Enterprise Security Architecture Unit Information Assurance Section
FBI Federal Bureau of Investigation
IATO Interim approval to operate
ID Identification (as in User ID)
IDW Investigative Data Warehouse
IRM Information resource management
IS Information system
IT Information technology
KM Knowledge management
NARA National Archives and Records Administration
NATO No approval to operate
OMB Office of Management and Budget
RM Records management
RMA Records management application
RMD Records Management Division
RMP Risk mitigation plan
RO Records Officer
SDLC System Development Life Cycle
U.S.C. United States code
VCF Virtual Case File

Appendix F: FBI EA Principles

Table 2-3: FBI EA Principles

1. The FBI's EA will comply with applicable laws, legislative mandates, executive orders, federal regulations, and other federal guidelines.

The FBI must abide by laws and regulations, and external policies regarding the development of architectures and the collection, retention, management, and security of data. Changes in the law (e.g., Clinger-Cohen Act), regulations (e.g., Federal records management regulations), and changes in policy (e.g., OMB Circular A-130) may drive changes in architectural processes or applications. The FBI EA will be benchmarked against appropriate oversight (GAO and OMB) and other applicable mission partners from the Intelligence Community (IC).

2. There is only one official EA for the Bureau and it will be designed, maintained, and updated through a well-defined governance process to ensure consistency with FBI strategic plans and objectives.

The interim and target architectures have the most value when they are aligned with FBI's strategic plans (including the IT Strategic Plan) and executive-level direction. As the strategic plan changes so will the future environment and target architectures. FBI IT programs are governed under a single directive utilizing five governance boards throughout a project's lifecycle.

3. The FBI's EA will evolve and require transition planning to support the objectives prescribed by FBI's annual program plans.

FBI's performance information will be used to improve organizational processes and help establish priorities for the Bureau’s EA. FBI’s architecture will constantly evolve to meet future objectives consistent with stakeholder and customer expectations. All IT investments will be aligned with the EA and FBI mission priorities.

4. Data and information are valued as an enterprise asset to promote both internal and external sharing. The Target EA will support the management and control of records, ensure data integrity, and will enhance and accelerate effective decision-making. Additionally, the EA will provide and manage legally acceptable electronic records with non-repudiation and maintain a chain-of-custody in accordance with our IT governance policies.

Data and information, as a corporate asset, are essential to an organization's vision, mission, goals, and work activities. The more efficiently the FBI gathers, stores, retrieves, and shares data and information the more productive the Bureau will be. Viewed as a corporate asset, data and information can enhance the efficiency and effectiveness of the service delivery. FBI data and information are subject to all the policies, procedures, and requirements of records management to ensure data integrity, authenticity, accessibility, and records control.

5. FBI data will conform to a standardized set of data elements and definitions and will be managed through a central data governance policy.

Sharing of data implies common definitions and understanding which facilitates interchanges with FBI partners and stakeholders. Effective information sharing and exchange depends on a shared definition of standard data elements throughout the Bureau.

6. The FBI's EA will be centrally managed to support the development of enterprise solutions, support business functions independent of the organizational units performing the work, and to manage for interoperability and reduced infrastructure costs.

Enterprise solutions are an effective way to provide required IT capabilities to multiple functional areas. Enterprise-wide solutions will provide the Bureau economies of scale advantages by optimizing volume purchasing, reducing redundancy, reducing the need for unnecessary resources, and maximizing the value of enterprise licensing. Technical administration and support costs are better controlled when limited resources can focus on shared processes and systems.

7. Security, confidentiality, and privacy will be practiced and designed into all architectural elements; balancing mission, exigency, accessibility, information sharing, and ease of use with protection of data.

The FBI's information assets must be available to authorized users while being protected against misuse. These goals will be met through the consistent management of security policy, awareness, access control, monitoring and compliance; by including Information Assurance as a key part of the overall governance of the FBI's information enterprise; and by designing defensive-depth into the FBI's Security Architecture. This strategy will safeguard the confidentiality, integrity and availability of information; ensure business continuity and reduce business damage by preventing and minimizing the impact of security incidents; and enable information sharing in a manner, which protects information and computing assets. The statutory, policy and regulatory mandates, which guide the FBI's information safeguarding strategy, include the Federal Information Security Management Act (FISMA), Privacy Act of 1974, Presidential Decision Directive (PDD) 63, OMB A-130 (App. III), and Director of Central Intelligence Directives (DCID).

8. The target operational environment will be a paperless, multi-media environment with the capability to manage and control analog and digital files to support investigations, intelligence requirements, and provide evidence for the courts.

The FBI EA must be designed and managed to support all FBI mission areas effectively while providing the advantages and efficiencies that Bureau mission owners expect from their IT investments. The target EA will be designed to support the Director’s priorities and the FBI mission owners.

9. Enterprise-wide standards will enable interoperability, scalability of systems, and contain a limited number of products resulting in a reduced amount of technical skills required to support FBI's business operations as well as a cost advantage resulting from a reduced number of licensing agreements.

Standardization and the resulting reduction in product selection minimizes support and maintenance costs, and more importantly, simplifies training of workforce skills to meet current and future business requirements.

10. All IT investments will use industry-proven, mainstream technologies that are aligned with EA and Bureau priorities.

Target architecture should be populated by technologies that are aligned with the FBI’s mission & strategic plan and are tested to meet the requirements they were procured for in terms of capabilities, functionalities, scalability, and compatibility with the existing enterprise infrastructure.

11. A goal of the target EA is to maximize the FBI’s ability to share information across systems, security domains, and between partner agencies.

When considering new technologies for the target architecture, FBI governance review boards should consider technology interfacing and their ability to share information between systems, security enclaves, and even inter-agency.

12. The FBI EA will enable information sharing with the Bureau’s federal, state, local, and international partners.

In addition to making the FBI more efficient internally, the EA must enhance the ability for the Bureau to interact with its mission partners at all levels. The FBI and its mission partners will benefit from an interoperable and scalable EA to facilitate effective information and data sharing.

Top of Page


Appendix G: FBI RMA Metadata Requirements

Individual Documents

Element Definition/Descriptions
Unique RMA Identifier An unambiguous system-generated data element that identifies a particular record.
Contributor Record ID Unique ID provided by the Contributing System which identifies a particular record within that system.
File Number Identifies the classification, sub-classification (alpha), Office of Origin, and Case number.
Serial Number assigned to the document within the Case ID.
Document Type Code indicating the type of document. "TYPE"
Document Date Generally the date appearing on the face of the document. In the case of e-mail, it is date sent.
To / Addressee The recipient(s) of the document.
From / Author – Individual The originator of the document. The individual who creates, sends, signs the document.
From / Author – Organization The organization to which the originator of the document belongs.
Title / Subject / Topic of Document Generally the "name" of the document (e.g., the title of an EC or memorandum, the subject line of an e-mail, the title of a report, briefing, spreadsheet, etc.)
Description / Abstract / Notes A brief narrative description about the record, which usually contains keywords.
National Security Classification Identifies the classification level for the security classification. The document classification reflects the highest classification in the document.
Other Restrictions Identifies a record to which a legislative or regulatory restriction has been applied (i.e., Rule 6(e), FOIA, litigation matters).
Record Status Indicates the distinction between the official record, a copy, duplicates, etc. The default would be Records. Generally inherited from the file classification or file number.
Document Disposition Those actions taken regarding Federal records after they are no longer required to conduct current Agency business. Generally inherited from the file classification or file number.
File Classification Disposition The disposition assigned to the file classification number. Can be permanent, disposable, sample/select – undetermined, sample/select – permanent, sample/select – disposable, or unscheduled.
Selection Criteria If the disposition is sample/select – permanent, this identifies the criterion/criteria used to make that determination.
Records Schedule Identification Identification of the approved disposition authority. Generally linked from the file classification.
Entry Date The date the record was entered into the system.

Batch Documents (Managed at the file level or higher)

Element Definition/Descriptions
Individually Entered Data Elements
File Number Identifies the classification, sub-classification (alpha), Office of Origin, and Case number
Volume Number / Sub-part of the Case File Identifies the location of the record within the sub-sets of a physical case file.
Batch Generated Data Elements
Record Status Indicates the distinction between the official record, a copy, duplicates, etc. The default would be Records.
Document Disposition Those actions taken regarding Federal records after they are no longer required to conduct current Agency business. Generally inherited from the file classification or file number.
File Classification Disposition The disposition assigned to the file classification number. Can be permanent, disposable, sample/select – undetermined, sample/select – permanent, sample/select – disposable, or unscheduled.
Selection Criteria If the disposition is sample/select – permanent, this identifies the criterion/criteria used to make that determination.
Retention The length of time that a record must be kept before it is destroyed, which is determined by scheduling.
National Security Classification Identifies the classification level for the security classification. The document classification reflects the highest classification in the document.
Other Restriction Identifies a document to which a legislative or regulatory restriction has been applied, (i.e., Rule 6(e), FOIA, litigation matters).
Scanning Project ID Identifies the title of the Scanning Project.
System Generated Data Elements
Unique RMA Identifier An unambiguous system-generated data element that identifies a particular record.
Entry Date The date the record was entered into the system.

Footnotes

1 Public Record Office, United Kingdom, e-Government Policy Framework for Electronic Records Management, 2001, p. 6.

Public Record Office, United Kingdom, Management, Appraisal and Preservation of Electronic Records, Vol. 1: Principles, 1999, p. 10.

For a more detailed description of the responsibilities of the sections, reference the FBI Draft Strategic Plan FY 2004-FY2010 – Version 0_10g (redacted) pp. 139 – 140, Records Management Division Organization and Administration Memorandum dated February 5, 2003, and the Records Management Architecture: Current State Evaluation, November 2, 2004.

4  e-Government Policy Framework for Electronic Records Management, p. 16.

Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems, ANSI/AIIM/ARMA TR48-2004, July 4, 2004, p. 11.

e-Government Policy Framework for Electronic Records Management, p. 6.

7  Management, Appraisal and Preservation of Electronic Records, Vol. 1: Principles, p. 10.

Ibid, p. 25.

Framework for Integration of Electronic Document Management Systems and Electronic Records Management Systems, p. iv.

10  Ibid, p. 10.

11  Ibid, pp. 14-15.

12  This discussion of the functional requirements was taken primarily from the High-Level Functional Requirements dated February 2003. That document defines the functional requirements and many of the performance and system requirements for the RMA.

13  e-Government Policy Framework for Electronic Records Management, p. 20.

Top of Page