Federal Records Management

FBI Records Management Architecture: Current State Evaluation

Return to the Toolkit for Managing Electronic Records

FBI Records Management Architecture:
Integrate with FBI Enterprise Architecture

1.0 Introduction

2.0 Enterprise Architecture (EA) Overview

2.1 Baseline Architecture

2.1.1 Cross-Cutting Capabilities: Privacy, Security, and Records Management
2.1.2 Privacy
2.1.3 Security
2.1.4 Records Management

2.2 Target Architecture

2.2.1 Business Reference Model
2.2.2 Data Reference Model
2.2.3 Service Component Reference Model
2.2.4 Technology Reference Model


Appendix A: FBI Enterprise Architecture Principles
Appendix B: Best Practices for Electronic Records
Appendix C: Glossary of Terms
Appendix D: Acronyms


Table 4-1: Records Management in the Target Business Reference Model
Table 4-2: Target RM Processes
Table 4-3: Records Data Area and Classes
Table 4-4: RMA Capability to Service Domain Mapping


Figure 4-1: Federal Enterprise Architecture Framework
Figure 4-2: Federal Enterprise Architecture Reference Models
Figure 4-3: Federal Enterprise Architecture Service Reference Component Model
Figure 4-4: Information Management Systems

1.0 Introduction

The Records Management (RM) Architecture Project has developed a Business Concept of Operations (ConOps) and a System ConOps as the basis for implementing a Records Management Application (RMA) within the Federal Bureau of Investigation (FBI) Enterprise Architecture (EA). These documents will 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 RMA.

This document, Integrate with FBI EA, provides an overview of the FBI Baseline and Target Architectures and describes how RM will integrate with the Target EA. The document references the framework, layers, and models used in the EA. By integrating the RM architecture with the EA, we provide traceability from and to the high-level business goals and processes.

The remainder of this document is organized as follows:

2.0 Enterprise Architecture Overview

The FBI has initiated a major effort to align the many facets of its Information Technology (IT) infrastructure, modernization, and direction due to the radically changing environment under which it operates. The foundation element of this effort is the creation of an EA. By providing an overview of EA goals, objectives, and terminology, we establish a common framework from which to discuss the integration of records management into the target environment. In this context of integrating into the Target EA, Records Management is defined as "the planning, controlling, directing, organizing, training, promoting, and other managerial activities involving the life cycle of information, including creation, maintenance (use, storage, retrieval), and disposal, regardless of media."1

The EA describes the planned design for the Bureau's implementation of technology that directly supports the business functions, missions and priorities of the Bureau. The Target EA will include effective measures to ensure the successful use of technology and present a planned view of consolidated infrastructure and common services that may be leveraged across the enterprise. The principles for the EA program are re-iterated in Appendix A of this document.

In support of the EA effort, the Records Automation Section (RAS) has documented best practices for electronic records to guide how the EA will support the Record Management Division's (RMD) business and technology requirements. These best practices are listed in Appendix B. Execution of the EA Program is being completed through a structured, phased approach that is consistent with the key reference models of the Federal Enterprise Architecture (FEA). The FBI EA team began this approach by creating a baseline architecture and is in the process of developing a target architecture.

The baseline architecture was developed to serve as a reference for documenting, discussing, and maturing the EA structures, relationships, and processes. Its ultimate goal is to provide a foundation for further analysis to ensure that key investments, particularly those in the FBI's IT, represent the critical elements of both a responsive and planned approach.

The target architecture will represent the desired future state business and technology environments for the Bureau within the context of strategic direction and provide direct support for business goals and priorities. The purpose of the target architecture is to align the various business, application, data, and technologies identified in the baseline business architecture with strategic opportunities.

The transition from the baseline architecture to the target architecture is an iterative process. Neither the baseline nor the target architecture remains constant. Therefore, the transition is a never-ending process. Transitioning from baseline to target architecture requires a strategy and the means to implement it. The transition strategy for RM will be discussed in Task 5.

2.1 Baseline Architecture

The FBI EA Team has developed a baseline architecture that depicts the current business and technology environments at the Bureau. This summary of the baseline architecture provides the context to understand how the FBI documented and organized its current state. This understanding will help facilitate the integration of RM requirements into the target EA.

The baseline architecture consists of four layers that contain information on the FBI's business, data, applications, and technology. These layers are decomposed into models that characterize the information contained in each architecture layer; key relationships among architecture layers, mission and priorities, stakeholders, and FBI organizations; cross-cutting components that affect the entire architecture, such as privacy, security, and records management; and issues and opportunities confronting the FBI. These layers are depicted in Figure 1 and are further described below. The baseline architecture has been populated with information in each of these layers, as well as the key linkages and interrelationships between the various layers of the architecture. The links between the layers provide insight into how a change in one element of the architecture might affect other elements in other layers of the EA. By analyzing these linkages within and between the layers of the architecture, the FBI can begin to identify opportunities for simplification, standardization, cost savings, and improvement. 2

Figure 1: Federal Enterprise Architecture Framework

Federal Enterprise Architecture Framework

  • Business Layer - The business layer describes how work is currently performed within the FBI. The work is described and aligned with strategic goals and objectives of the FBI to show how they support the fundamental mission of the Bureau. Each of the FBI's eight business areas is further described with its identifying relationship to the key stakeholders that have vested interests in either the delivery of services or processes performed within that business area. The business layer is mapped to the FEA Business Reference Model (BRM).
  • Data Layer - The data layer identifies the data that underlie the business need. It defines information independent of who produces it, when it's produced, where it is physically kept, in what form it is kept, or how it is transmitted. The FBI EA Team has identified eight data areas and 63 data classes, but currently has not developed an organization-wide data model due to the complexity of the data architecture.
  • Application Layer - The application layer contains all the applications that support the FBI's business. The applications enable the business processes to achieve their mission by providing access to needed data in a useful format. One of the primary goals of the baseline application architecture is to identify opportunities to eliminate application redundancy and enhance enterprise-wide information sharing. The FBI EA Team has mapped the application layer to the FEA Service Component Reference Model (SRM).
  • Technology Layer - The technology layer contains all the technologies that comprise the FBI's IT infrastructure. The applications supporting FBI business processes are in turn supported with technology and infrastructure. The technology layer was developed by creating an inventory of technical assets of the FBI. It was then mapped to the FEA Technical Reference Model (TRM).

The models that were created are effective management tools for describing and comparing layers of the current EA environment. They provide a framework for organizing the large amount of information necessary to describe each architectural layer. The models also establish a common vocabulary and information set, serve as tools to help identify duplication and incompatibility, and create a basis for transitioning to the target environment.

2.1.1 Cross-Cutting Capabilities: Privacy, Security, and Records Management

Agencies are coming under increased pressure to provide assurance to the public, media, and Congress that classified or sensitive information is protected and secure and that essential business transactions and policies are properly documented. The capability to provide this assurance affects all layers of an EA. The FBI's EA can help identify sensitive and essential business information and the means by which information is collected, used, and shared by the Bureau and stakeholders. Integration of privacy, security, and records management into the EA facilitates:

  • Identifying and prioritizing critical assets (i.e., applications, hardware, software, and processes) of the enterprise.
  • Managing privacy, security, and records concerns as the enterprise evolves to an FBI E-Government environment (e.g., through audit, access control, non-repudiation, and other capabilities).
  • Addressing privacy, security, and records management in systems development and integration.
  • Providing reasonable assurance to Congress, the Office of Management and Budget (OMB), and the public that sensitive information and essential business information is safe, secure, and documented.

2.1.2 Privacy

The FBI's EA should support the identification and analysis of privacy information. Privacy concerns begin with the data architecture layer. Data classes or entities should have the ability to be flagged as containing privacy information. Processes and applications that manipulate or transport data are identified through the data's architecture links to the business and application layers. Processes and systems can then be assessed to determine the controls required to protect the data. The target architecture should identify the need for a common set of data criteria and taxonomy and provide a basis for the creation of an over-arching data privacy initiative.

2.1.3 Security

Security is the means by which data are protected. The extent and types of required protection drive the FBI's security principles and posture. A well-defined security strategy ensures that all necessary physical, administrative, and technical safeguards are in place and synchronized with the overall IT architecture and business culture. 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 while allowing for the appropriate level of collaboration and information sharing that is key to the successful completion of the Bureau's missions. This strategy will need to be comprehensive and implemented across all layers of the Bureau's EA.

2.1.4 Records Management

RM is the means by which the Bureau's business transactions and policies are adequately and properly documented. The new RM system must integrate with the EA and ensure that accurate records from all activities of the FBI are created, maintained, and disposed of in accordance with all legal requirements. Like privacy, all data classes and entities that contain records should be flagged as part of normal processes during the operation of any application that manipulates or transports records. These processes and applications can then be assessed to determine the controls required to ensure proper RM in the target environment.

RM and Security capabilities are mutually beneficial. Accordingly, the Enterprise Security Architecture Unit Information Assurance Section (ESAU/IA) is working closely with the EA Program Office and the 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, monitoring and compliance.

2.2 Target Architecture

The target architecture describes a notional end state that will be needed to support the missions, goals, and priorities of the FBI through the effective use of technology. The high-level, enterprise-wide target architecture represents the target state for the Bureau within the context of strategic direction. The target architecture is an over-arching strategic document that will help measure how well technology is being used by the FBI and allow the FBI to create common services and environments that realize greater efficiency and economies of scale.

The FBI's Target EA will help address challenges and opportunities such as:

  • Leveraging the advances in technology and systems engineering to increase the efficiency of FBI's IT spending, including consolidation of infrastructure (e.g., server hardware), reduction of applications performing duplicative services, introduction of re-usable components to shorten system delivery time, and reduce maintenance and training costs.
  • Improving and automating information exchanges with stakeholders in support of required information sharing and analytical needs.
  • Developing more effective performance measures that are aligned with strategic outcomes.

The target architecture will be based on the Federal Enterprise Architecture reference models. The models, developed by the OMB to facilitate efforts to transform the Federal Government into one that is citizen-centered, results-oriented, and market-based, will serve as a guide to create the framework necessary to drive the FBI's architecture into the desired future state. The FEA is a business-based framework for Government-wide improvement in its value to the citizen. It is being constructed through a collection of interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. The FBI's Target EA is being mapped to the FEA Reference Models. These models are illustrated in Figure 4-2.

Figure 4-2: Federal Enterprise Architecture Reference Models

Federal Enterprise Architecture Reference Models

The FEA's five reference models are described below. 3

  • Performance Reference Model (PRM) - Standardized framework to measure the performance of major IT investments and their contribution to program performance. The FBI PRM is being developed as part of the overall EA effort. Currently, the model framework is not yet well developed. Therefore, we do not address it in this document.
  • Business Reference Model (BRM) - Function-driven framework for describing business operations of the Federal government independent of the agencies that perform them.
  • Service Component Reference Model (SRM) - Business and performance-driven functional framework that classifies service components with respect to how they support business and/or performance objectives.
  • Technical Reference Model (TRM) - Component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities.
  • Data Reference Model (DRM) - Model describing, at an aggregate level, the data and information that support program and business line operations.

The first Target EA iteration will leverage the existing Business Architecture and focus on the applications and technology aspects of the architecture that will be needed to drive the architecture into the desired state. Some of the considerations for the development of the target architecture are:

  • The FBI mission environment is already constructed along functional lines and minimal organizational change is supported/necessary.
  • The FBI data environment is evolving with several complimentary efforts that will be progressing in parallel with the Target EA development. The outcome of these initiatives will be integrated into the Target EA as appropriate.
  • The Target EA is an iterative process that establishes the vision and blueprint for future business operations and supporting IT. The purpose of the Target EA is to integrate the various business, application, data, and technologies identified in the baseline business architecture.

The target architecture describes the future environment as one that is service-based and component driven. This will allow for greater flexibility in design and create a balance in the level of detail necessary to provide meaningful guidance on which to base architecture and investment decisions.

In order to achieve this goal, each reference model of the architecture is defined at differing levels of granularity in the target architecture. For many organizations, the business model is the most stable and definable of all EA models. Since the data reflects the information used by the business, it may also be relatively stable and remain consistent over time. Conversely, the service and technology models are often the least stable models of the EA. They reflect functional capabilities and applicable technologies to support the future business.

The target architecture mapping and tables we provide here include the areas most closely related to RM. This information can help generate organizational consensus on the role and functionality of the RMA, as well as the functionality that could be provided outside of the RMA as part of an integrated package from a commercial software vender.

2.2.1  Business Reference Model

The BRM will probably resemble its business baseline model more closely than any other and will also feature the greatest level of detail of all target models. It is based on the business strategies to achieve the FBI's goals and objectives and will shape the development of each of the remaining models. The BRM is linked to the DRM and will reflect an optimized business environment.

Since 9/11, the FBI has realigned its organization and evaluated its mission to come up with new goals and objectives to guide it into the future. These goals and objectives are reflected in the baseline EA document. Because the mission of the FBI has been reevaluated and is not expected to change in the near future, the baseline business layer can be used as the starting point for the target BRM. The FBI Baseline Business Model depicts the major business areas, their underlying functions, and the more granular sub-functions carried out within the FBI. Table 4-1 maps the RM sub-functions to their higher-level functions and business areas. In the first half of the table, under the Counter-Terrorism, Counter-Intelligence, Cyber Crime, and Criminal Investigation Business Areas, "Manage Intelligence/Records/Evidence" is a sub-function that directly supports a specific critical function for that business area. Under the Administration Business Area, "Provide Records Management" is a cross-cutting function that accounts for RM across all parts of the Bureau.

Table 4-1: Records Management in the Target Business Reference Model 4

FBI Business Area FBI Function FBI Sub-Function Description BRM Sub-Function


Conduct Counter-Terrorism Centered Operations

Manage Intelligence /Records /Evidence

Includes all aspects of the custody of information, intelligence, and physical artifacts to include control of access, integrity of sources and information, validation, chain of custody, retention and disposition policies, authentication, and other factors that ensure the both the safe storage, pedigree, and usefulness of its content.

Record Retention


Conduct Counter-Intelligence Centered Operations

Cyber Crime

Conduct Cyber Centered Operations

Criminal Investigation

Conduct Criminal Centered Operations


Provide Records Management Support for Paper and Electronic Records

Establish Records Policies

Includes the storage, processing, monitoring, and disposition of FBI's records.

Record Retention

Provide Records Review and Dissemination

Includes records storage, access control, chain of custody, monitoring, retention, authentication, validation, and disposition.

Provide Document Automation and Conversion

Includes name processing against criminal warrant databases.

Provide Lifecycle Management of Records

Includes policies and procedures for records storage, access control, chain of custody, monitoring, retention, authentication, validation, and disposition.

Records Retention/ Central Records and Statistics Management

Manage Freedom of Information / Privacy Act Inquires

Includes records classification and authentication/validation for authorized distribution to appropriate accessible customers.

Official Information Dissemination

Manage National Name Check Program

Includes the processing of public access requests for information.

RM in the Administration Business Area is representative of RM throughout the Bureau. The content of records may change based on business area, but the RM process should be consistent.

The core RM processes fall under the sub-function "Provide Lifecycle Management of Records". Capturing required metadata is critical to the ability to perform this sub-function, which is described at the process level in Table 4-2. As described in the Business Concept of Operations and System Concept of Operations for the RMA, there will be three main metadata sources: paper records, records from applications that have met Electronic Recordkeeping Certification (ERKC), and records from applications that are fully integrated with the RMA. 5 These three sources correspond to the three processes in Table 4-2.

Table 4-2: Target RM Processes

Provide Lifecycle Management of Records Sub-Function

Process/Activity Description
Manage Paper Records Includes paper records that come from a document received in hard copy format or a document generated by an application that has not achieved ERKC.
Creation Paper document is created or captured, determined to meet requirements of a record, and stored in its paper form as an official record in the paper repository. To integrate with the RMA, the record's required metadata is manually entered and sent to the RM metadata repository.
Maintenance and Use Paper record is maintained and stored in the paper records repository, while its associated metadata is maintained and stored in the metadata repository. Using the RMA search capability, record's existence and location is determined. When requested, record can be scanned and sent electronically if urgent, or bar-coded for tracking and shipped in paper form for routine requests. When returned, paper record is sent back to the paper records repository. If a paper record is scanned, it is then managed as an electronic record by the RMA and stored in the content repository.
Disposition The RMD is notified by the RMA that paper record is due for disposition review. The RMD authority determines if the paper record should be destroyed, have the destruction delayed, or sent to NARA for permanent storage.
Manage Records within an ERKC Application Includes electronic records generated by applications that have achieved ERKC.
Creation Electronic document in native application is created or captured, determined to meet requirements of a record, and stored in electronic form as an official record. The record's required metadata is automatically captured by the native application and exported to the RM metadata repository.
Maintenance and Use Electronic record is maintained and stored in the ERKC application's repository, while its associated metadata is maintained and stored in the metadata repository. Using the RMA search capability, record's existence and location is determined. Record can be retrieved from the desktop if the ERKC application is networked. Otherwise, the record is retrieved by logging into the ERKC application/system.
Disposition The RMD is notified by the RMA that electronic record is due for disposition review. The RMD authority determines if the electronic record should be destroyed, have the destruction delayed, or sent to NARA for permanent storage.
Manage Records using an enterprise RMA Includes electronic records generated from applications that are fully integrated with the RMA.
Creation Electronic document in RMA integrated application is created or captured, determined to meet requirements of a record, and stored in its electronic form as an official record in the content repository. The record's metadata is automatically captured by the RMA and stored in the RM metadata repository.
Maintenance and Use Electronic record is maintained and stored in the content repository, while its associated metadata is maintained by the RMA and stored in the metadata repository. Using RMA search capability, record's existence and location is determined. Record can be automatically retrieved from user's desktop.
Disposition The RMD is notified by the RMA that electronic record is due for disposition review. The RMD authority determines if the electronic record should be destroyed, have the destruction delayed, or sent to NARA for permanent storage.

2.2.2 Data Reference Model

If the information that the FBI requires to perform its mission does not dramatically change, the baseline data architecture and links to the business layer remain fairly stable. However, the relationship between the data and the application layers may show a dramatic transformation in the target architecture. These changes will be represented by new data-to-application links and the associated descriptive information reflecting where data is created, referenced, or updated. Links between the data and technologies may also be established to identify how data will be maintained (e.g., by data stores that are independent of the applications that manipulate the data).

Currently, the data that the FBI requires to perform its mission resembles the baseline data architecture. The data area and classes that contain records are listed in Table 4-3.

Table 4-3: Records Data Area and Classes

FBI Data Areas and Data Classes

Data Area Data Class Applications
Records FOIPA Requests Information to manage the processing of public access requests for information


Investigative Records Information supporting investigative activity requiring retention


Intelligence Records Information supporting intelligence activity requiring retention


Evidentiary Records Documents and other media to support prosecution requiring retention


Corporate Records Official correspondence, communication and transactions requiring retention


The EA Team will be conducting a thorough review of the data that will be contained in the DRM. As shown in Table 3, records data comes from multiple applications. RM is concerned about capturing required metadata, regardless of the origin of the data. Once the metadata is captured, the information can be managed as a record. Once the data and applications that will produce records in the Target EA are identified, the RMD will coordinate with Program and IT Project Managers to ensure metadata and capture requirements are incorporated in the structure and categorization of data that have the potential to become a record.

2.2.3  Service Component Reference Model

In the Target EA framework, a Service Domain 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 Domains that break down critical business functions into 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 is consistent with the seven primary Service Domains of the FEA SRM: Customer Services, Process Automation Services, Business Management Services, Digital Asset Services, Business Analytical Services, Back Office Services, and Support Services. Each Service Domain will then be aligned to specific capabilities from the FEA SRM. In the FBI's initial framework, the capabilities provided by the RMA generally fall under the Digital Asset Services Domain. However, some capabilities are more accurately aligned with other Service Domains including Support, Process Automation, and Back Office. The FEA SRM is illustrated in Figure 4-3.

Figure 4-3: Federal Enterprise Architecture Service Reference Model

Federal Enterprise Architecture Service Reference Model

In the FBI's RM Conceptual Model, an enterprise RMA will provide lifecycle management of the Bureau's records. There are many classes of systems and products that help organizations manage records. Figure 4-4 illustrates these information management systems and their components using standard industry terminology. Enterprise Content Management (ECM) is the most inclusive system. ECM refers to a comprehensive system for managing the information used and produced by an organization.

Figure 4-4: Information Management Systems

Figure 4-4: Information Management Systems

The subset of ECM capabilities that securely organizes and manages documents, routes documents, automates related tasks, and facilitates distribution is generally often bundled together and referred to as Integrated Document Management (IDM) software. Core functionality includes library services (e.g., check-in and checkout, version control, and document security) and cross-repository searching. Most IDM products offer additional technological capabilities such as scanning, electronic records management, workflow management, and document archive and retrieval.

Electronic records management is a subset of both ECM and IDM. 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 RM products can be used as stand-alones, but they are usually matched with additional IDM functionality. This IDM functionality is closely aligned with the RMA Service Component/Capability set that the FBI wants to acquire. Table 4-4 maps RMA related components and capabilities to their Service Domain, Service Type, and Application in the Target EA.

Table 4-4: RMA Capability to Service Domain Mapping

Service Domain Service Type RMA Component/Capability TargetApplication
Digital Asset Services Records Management Declare - allow information to be designated as a record.
  • Designates specified information as records, either manually or automatically.
  • Assigns unique identifiers to records and their associated metadata. The application prevents any modification of a record's unique identifier, once it is defined.
  • Captures record metadata automatically and reliably links metadata to the records.
IDM (RM module)
Capture - providing 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.
  • Imports records from sources outside the application along with all required associated metadata.
  • Able to link with systems that provide records management control over the records without physically transporting them to the RMA.
IDM (RM module)
Classification - providing structured and controlled metadata to ensure more precise retrieval of information.
  • Accepts an FBI-specific scheme for organizing records.
  • Users can select categories in which records are filed and assign records to these categories.
  • Supports assignment of Vital Record indicators.
  • Supports linking of related records.
  • Supports the capability for users to create and edit file plans, including categories and sub-categories. Prevents deletion of non-empty folders.
  • Can assign a status to records to prevent destruction.
  • Supports global changes to metadata, file plans, and records retention schedules.
  • Executes disposition instructions.
  • Stores metadata for records not contained in the system and can identify records by physical location.
IDM (DM/RM module)
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. IDM (RM module)
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.
  • Ensures that all access privileges (permissions and restrictions) are enforced on all retrievals.
  • Retrieve records and their associated metadata and retrieve records based on defined links.
  • Provides a sufficiently powerful range of search features and options, as needed to meet agency requirements

IDM (RM module)

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.
  • Identifies records eligible for transfer or destruction based on records retention schedules and disposition instructions (i.e. automatically detects when a record's retention period will pass, notifies the Records Officer that the record is eligible for disposition, and stipulates whether the record is eligible for transfer or destruction).
  • Exports records and metadata to be transferred in a format acceptable for transfer to NARA.
  • Deletes records to be destroyed so they cannot be physically reconstructed or otherwise retrieved.
  • Maintains a record of all record transfers and destructions and provides certifiable proof of transfer or destruction. All records of transfer or destruction are treated as records.
IDM (RM module)
Digital Asset Services Document Management Document imaging - transforming a paper document into a digital image. IDM (Scanning module)
Document Review and Approval/Document Revision - 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. IDM (DM module)
Library/Storage - providing consolidated storage, access, management, and viewing. Moving documents from a network file system to an electronic archive. IDM (RM module)
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. IDM (DM/RM module)
Support Services Security Management

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

  • Prevents the overwriting of records. Records are never edited, but new versions are created and linked to the source.
  • Prevents deletion of indices, categories, and other pointers to records.
  • Provides an automatic method to detect any alteration of records or metadata.
  • Provides audit trails of all add, update, deletion, and retrieval activity.
  • Maintains appropriate backup copies of records and recordkeeping systems.
  • Protected by adequate recovery/rollback and rebuild procedures so that records may be recovered or restored following a system malfunction.
  • Provides users the capability to read and accurately interpret all records and metadata in the system throughout their useful life. Capability to continuously sample older records for the ability to machine-read records and their metadata, and reports failures to machine-read.
  • Enables migration of records and metadata to new storage media or formats in a way that the content is retained and understandable in order to avoid loss due to media decay or technology obsolescence.
  • Ensures that captured metadata remains linked to appropriate records without alteration throughout the useful life of the records. Supports the capability to continuously sample records to verify that metadata remains associated with records and to output results of the sampling process.
IDM (RM module)
Access controls - maintaining Access Control Lists (ACLs) at the user, role, and group levels.
  • Controls access so that only authorized individuals are able to retrieve, view, print, copy, or edit records or other entities (e.g., metadata, file plan, etc.) in the recordkeeping system.
  • Identifies individuals and groups of users and allows different access privileges to be assigned to individuals or groups.
  • Maintains the integrity of redacted records and assures that redacted material is not accessible on sealed records.
IDM (DM/RM module)
Audit Trail Capture and Analysis - providing retrieval history by tracking all access to records including the requestor, time requested, time completed, and date.
  • Provides access to summary reports and detail level audit trail information. Supports the capability to continuously compile and output periodic and on-demand reports of summary and detailed audit trail information.
  • Tracks all records activity (e.g., requestor and type of activity) and system functions. Detects, records, and outputs any unsuccessful attempts to access records or metadata, or conduct other system functions. Tracks information such as user ID, date and time of failed attempts.
  • Manages audit trail information as records in order to prevent editing of audit logs.
IDM (RM module)

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

IDM (DM/RM module)
Process Automation Tracking and Workflow 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. IDM (Workflow module)
Back Office Services Data Management

Metadata Management - 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.

IDM (DM/RM module)

To be successfully implemented and effectively used by the Bureau, the RMA must be integrated with the Target 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. Applications that provide redundant capabilities may be evaluated for possible elimination. Others may not be refreshed at the end of their normal lifecycle if the capabilities they provide can be provided by other applications, capabilities, or services. The remaining applications will be prioritized for a phased integration with the RMA. This phased integration and migration plan will be described further in the Transition Strategy (Task 5).

2.2.4 Technology Reference Model

The TRM will be developed through defining the technologies to be used to meet the future business needs. The TRM and the standards profile are essentially composed of models, standards, and guidance in the use of best practices. The TRM will not specify particular products and versions, but will instead be used as a tool to aid in developing technology solutions over time.

Currently, the office of the Chief Technology Officer (CTO) is reviewing the Bureau's data needs. That effort will be integrated into the Target Architecture so that the FBI can determine the standards and technologies that will be used to define the future state. A key consideration for the RMD is that storage technology standards can impact potential RM solutions. For example, a single repository, multiple repositories (federated), or independent repositories have different imVial RM solutions. Therefore, the RMD's efforts will be closely aligned with the CTO's efforts and will be reflected within the future state architecture.

Appendix A: FBI Enterprise Architecture 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.

Appendix B: Best Practices for Electronic Records

  1. Records Management is an aspect of the entire information management lifecycle. Accordingly, Records Management is not a separate process but instead, an integral, cross-cutting feature of the Enterprise Architecture.

  2. Records are created in the course of business and meet the statutory definition of a record.

  3. Records Management systems will support the capture of a record and its associated metadata at any point in the lifecycle of the document. The capture of records related metadata will be supported in system design and will be as automated and transparent to the end-user as possible.

  4. Records Management systems will support access control, non-repudiation, audits, alteration prevention, and evidentiary standards.

  5. The content of records will be accessible in machine-readable form to allow the re-use of the information and knowledge sharing. Because users search "information" not "records", the distinction needs to be transparent to the user (i.e., the Records Management architecture will support an enterprise-wide search capability).

  6. The FBI EA and Records Management systems will be flexible enough to support both electronic records and the migration of paper records. Records Management systems will support NARA requirements that records can be transformed or migrated to support preservation and long-term storage.

  7. Any Records Management application will use industry standard interfaces to support integration with existing applications within the FBI and future applications that may be deployed.

  8. Records Management systems will be able to support new and emerging technologies and information types. The records will be separable from the technology that created them (i.e., the technology may change but the records will be able to survive on their own by using non-proprietary formats and open industry standards).

  9. All IT systems will be evaluated and, when appropriate, certified by the Electronic Recordkeeping Certification process.

Appendix C: Glossary of Terms6

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. d

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

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

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.c

Disposition. Those actions taken regarding records no longer needed for the conduct of the regular current business of the agency.b

Document. Information set down in any physical form or characteristic. A document may or may not meet the definition of a record.c

Electronic Record. Any information that is recorded in a form that only a computer can process and that satisfies the definition of a Federal record in 44 U.S.C. 3301.b

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

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.d

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.c

Metadata.Data describing stored data: that is, data describing the structure, data elements, interrelationships, and other characteristics of electronic records.c

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.b

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

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 and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of the data in them.a

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.b

Records Management.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.a

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. c

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.b

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

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.d

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).d

Appendix D: Acronyms

BRM Business Reference Model
ConOps Concept of Operations
CTO Chief Technology Officer
DocLab Document Conversion Lab
DRM Data Reference Model
EA Enterprise Architecture
ECM Enterprise Content Management
ERKC Electronic Recordkeeping Certification
ERM Electronic Records Management
ESAU/IA Enterprise Security Architecture Unit Information Assurance Section
FEA Federal Enterprise Architecture
FBI Federal Bureau of Investigation
FOIPA Freedom of Information and Privacy Acts
GRS General Records Schedule
IDM Integrated Document Management
IT Information Technology
LCM Life Cycle Management
NARA National Archives and Records Administration
OMB Office of Management and Budget
PRM Performance Reference Model
RAS Records Automation Section
RM Records Management
RMA Records Management Application
RMD Records Management Division
SRM Service Component Reference Model
TRM Technical Reference Model


[1] Design Criteria Standard for Electronic Records Management Software Applications, Department of Defense, DoD 5015.2-STD, June 19, 2002, pp. 16-17, which reference Section 2901 of title 44, United States Code, "Definitions".

[2] For a detailed description of the FBI's Baseline EA, refer to Enterprise Architecture: Integrated Baseline Architecture Report Draft Version 0.11, Federal Bureau of Investigation, October 13, 2004.

[3] The FEA reference model descriptions can be found at the FEA Program Management Office web site. For more detailed information, visit http://www.feapmo.gov/.

[4] The information in Table 1 was taken from the FBI's Baseline Architecture report. For a more complete description of the FBI's business areas and functions, refer to Enterprise Architecture: Integrated Baseline Architecture Report Draft Version 0.1, Federal Bureau of Investigation, October 13, 2004.

[5] Reference the Business Concept of Operations, December 20, 2004 and System Concept of Operations, January 3, 2005 for a more detailed discussion of the conceptual model underlying these three metadata sources.

[6] These definitions were taken directly from the following sources.

  1. Title 44, United States Code, Section 3301.
  2. Title 36, Code of Federal Regulations, Chapter XII, Subchapter B.
  3. Design Criteria Standard for Electronic Records Management Software Applications, Department of Defense, DoD 5015.2-STD, June 19, 2002.
  4. Enterprise Architecture Integrated Baseline Architecture Report, Federal Bureau of Investigation, Version 2.0, Appendix A, December 13, 2004.