Federal Records Management

Federal Enterprise Architecture Records Management Profile

ATTENTION! This product is no longer current. For the most recent NARA guidance, please visit our Records Management Policy page.

Version 1.0

Initial Public Release Sponsored By:

National Archives and Records Administration
Office of Management and Budget
Architecture and Infrastructure Committee, Federal Chief Information Officers Council

December 15, 2005

PDF Version Available

Executive Summary

In performing their missions, Federal agencies produce records that are important business assets supporting Government operations. Agencies must manage their records throughout the records life cycle from creation through final disposition. By identifying and embedding records management requirements within their enterprise architectures, agencies will realize benefits such as compliance with relevant laws and regulations, consistent records management practices across the agency, improved customer service, and real cost savings.

In the current business environment, however, Federal agencies are using disparate and inefficient processes to manage their records, thereby exposing their organizations to considerable risk in their business operations and mission-related responsibilities. To address this problem, agency decision-makers need guidance to help them define records management requirements and apply records management policies and procedures consistently across the enterprise.

Establishing a Records Management (RM) Profile in the Federal Enterprise Architecture (FEA) provides agency decision-makers with a framework for incorporating statutory records management requirements and sound records management principles seamlessly into agency work processes, enterprise architectures, and information systems. The RM Profile identifies the following objectives:

1. Use the FEA as the common Government-wide framework for identifying records management requirements.

2. Identify records management issues and requirements and link them to their implementing technologies and business processes.

3. Build records management requirements into agency information technology (IT) governance processes for capital planning, enterprise architecture, business process design, and the systems development life cycle.

4. Establish a concise and coherent body of records management resources that places this information in the proper context within the FEA.

The RM Profile is a framework that overlays, or cross-cuts, the inter-related FEA reference models: the Business Reference Model (BRM), Service Component Reference Model (SRM), Technical Reference Model (TRM), Data Reference Model (DRM), and Performance Reference Model (PRM). The RM Profile provides an overview of the FEA and explains how the reference models provide a context for applying effective records management practices. Additionally, the RM Profile includes a description of how each reference model currently addresses records management and how agencies can use the various records management resources in the RM Profile to improve their records management programs. The illustration below summarizes the records management resources cited in Chapter 3 and shows how they align to each of the five FEA reference models.

To apply the RM Profile effectively, there are a number of issues and resources that agencies must first consider when:

Re-designing business processes and/or consolidating to a Line of Business,
planning new systems of records, or
enhancing existing systems.

Included in the RM Profile are sample questions that highlight many of the key issues relevant to each FEA reference model. Where appropriate, these questions refer agencies to the relevant records management resources where answers or additional guidance can be found. In addition, the RM Profile includes three scenarios that demonstrate hypothetical applications of some of the FEA reference model/records management-related questions. As listed below, these scenarios represent two distinct tracks that agencies might choose, and a third option that represents a hybrid approach combining elements of the first two:

An agency can opt for a DoD 5015.2-STD certified Records Management Application (RMA) that provides records management functionality for capturing, managing, accessing, storing, and dispositioning records.
Another option is to explore a component-based architecture (CBA) that uses records management service components (RMSCs) to accomplish similar functionality.
A third option is to develop RMSCs as part of mission applications and link them to RMAs already being used by the agency.

The Records Management Profile is a work in progress that will continue to evolve as more records management resources are identified and the technologies supporting the FEA mature. Though the Architecture and Infrastructure Committee (AIC) of the CIO Council has neither reviewed nor approved any next steps, the following proposed actions do provide an indication as to where future work on the RM Profile might lead.

Explore the on-going governance process for the RM Profile with NARA, the AIC, and the FEA Program Management Office.
Discuss potential areas of collaboration with other FEA Profile projects (e.g., Security and Privacy, Geospatial).
Expand RM resources in RM Profile to include agency best practices, recently completed NARA guidance, other International standards, and related guidance.
Discuss best approaches to promoting the use of the Profile by agencies.
Implement the RM Profile at an agency in a limited scope pilot or test case to refine the approach and evaluate the usefulness of the RM Profile.
Incorporate records management requirements into the RM Profile as they relate to vital records, Continuity of Operations (COOP), and disaster recovery processes.

Executive Summary

Table of Contents

Acknowledgements

Chapter 6: Next Steps

Appendix A: Selected Resources

Appendix B: Glossary

Appendix C: List of Exhibits

Appendix D: List of Acronyms

Acknowledgments

The National Archives and Records Administration, the Office of Management and Budget, and the CIO Council would like to acknowledge the following for their innovative ideas, thought-provoking comments, and overall dedication and commitment to the development of this product.

Our Government partners -

Federal Agency Representatives of the Electronic Records Policy Working Group (ERPWG) and the Federal Records Council (FRC)

Chief Architects Forum

National Association of State CIOs (NASCIO)

Our industry partners -

Booz Allen Hamilton Inc.

SRA International, Inc.

The Industry Advisory Council (IAC)

Chapter 1: Introduction

1.0 OVERVIEW

In performing their missions, Federal agencies produce records that document and support agency processes, activities, and decisions. Agencies must manage these records from creation through final disposition as integral assets to Government operations. Indeed, agencies that identify and embed these requirements within an enterprise architecture will realize benefits such as legal and regulatory compliance, consistent records management practices across the agency, improved customer service, and real cost savings.

Today, many Federal agencies use disparate and inefficient processes to manage their records, often managing them as afterthoughts when creating new records or systems of records. In many cases, agency business resources and information technology resources are not integrated. The failure to manage records effectively exposes agencies to considerable risks to business operations and mission success. ¹

To address this problem, agency decision-makers need guidance to help them:

(1) Define records management requirements, standard operating models, and business rules for each stage of the records life cycle and the systems development life cycle, and

(2) Apply records management policies and procedures consistently across the enterprise regardless of the format and media of the records, process or project scope, technology or application.

Establishing a Records Management (RM) Profile in the Federal Enterprise Architecture (FEA) provides the framework for embedding common and consistent records management procedures and practices into agency business processes. Currently, the RM Profile is a high-level concept. As the FEA and concepts associated with each of the reference models mature, the RM Profile will evolve to reflect emerging records management standards, technologies, and guidance.

1.1 RM PROFILE CONTEXT

The development of a RM Profile within the FEA originated in initiatives supporting the President's Management Agenda for electronic Government. In 2003, the Interagency Committee on Government Information (ICGI) was formed under Section 207 of the E-Government Act of 2002 (P. L. 107-347) with a mandate to recommend policies and procedures to improve the management of Government information and records to the Director of the Office of Management and Budget (OMB) and the Archivist of the United States.

Concurrent with the ICGI's work, but completed as a separate product, OMB and the Federal Chief Information Officer (CIO) Council's Architecture and Infrastructure Committee (AIC) produced The FEA Security and Privacy Profile Phase I Final (Draft). ² Issued in July 2004, the Security and Privacy Profile specified the need for an additional view of the FEA highlighting Federal security and privacy issues and requirements.

Building on that work, in December 2004, the ICGI's Electronic Records Policy Working Group (ERPWG) recommended that the National Archives and Records Administration (NARA) create a similar view patterned after the Security and Privacy Profile. ³ As with security and privacy requirements, records management requirements need to be linked at all levels of the FEA. NARA, OMB, and the Federal CIO Council's AIC support the creation of an RM Profile as a cross-cutting overlay of the FEA to tie records management considerations and requirements to the five FEA reference models.

In separate but related initiatives, NARA has proposed various strategies and guidance to support records management in agencies, including incorporating records management considerations early in work processes and system planning. These strategies include products released by the EPRWG, the Electronic Records Management (ERM) E-Gov Initiative, the Records Management Re-design Initiative (RMI), and the Electronic Records Archive (ERA) project. For more information on these initiatives, please see the documentation at: http://www.archives.gov/records-mgmt/initiatives/.

1.2 VISION FOR THE RM PROFILE

NARA, OMB, and the Federal CIO Council's AIC envision the RM Profile as a framework to ensure that agencies incorporate statutory records management requirements and sound records management principles seamlessly into agency work processes, enterprise architectures, and information systems. The RM Profile is a cross-cutting guide that uses relevant FEA reference model information (i.e., context and conditions) to help business process owners identify and integrate records management requirements into all aspects of agency business operations.

1.3 OBJECTIVES OF THE RM PROFILE

To accomplish this vision, NARA, OMB, and other Federal and industry partners are designing the RM Profile as an overlay for each FEA reference model. Agencies should use the Profile to identify records management issues, risks, benefits, and challenges during business process and IT investment planning. The Profile supports agency compliance with NARA policies and procedures and other records management requirements (e.g., OMB Circular A-130). ⁴ Based on an agency's assessment of risk, the Profile provides "an understandable, consistent, repeatable, scalable, and measurable methodology using relevant FEA reference model information (i.e., context and conditions) to help business owners"establish an appropriate set of records management controls.

The RM Profile identifies the following specific objectives:

Objective 1: Use the FEA as the common Government-wide framework for identifying records management requirements. By combining records management policies and procedures with the foundation of the FEA reference models, the RM Profile promotes a standardized means of implementing records management in agency enterprise architectures across the Government. Every line of business in the FEA should incorporate records management requirements and functionality.

Objective 2: Identify records management issues and requirements and link them to their implementing technologies and business processes. The RM Profile ensures that agencies evaluate records management issues and requirements during agency planning processes. Agencies should integrate these requirements into all areas of business operations, especially before the implementation of systems and supporting processes.

Objective 3: Build records management requirements into agency IT governance processes for capital planning, enterprise architecture, business process design, and the systems development life cycle. For agency IT managers and enterprise architects in particular, the RM Profile is a useful guide for building records management requirements into IT governance processes for capital planning, enterprise architecture, business process design, and the systems development life cycle.

Objective 4: Establish a concise and coherent body of records management resources that places this information in the proper context within the FEA. A key objective of the RM Profile is to bring together relevant records management resources (e.g., NARA, OMB, and GSA) as a concise body of knowledge that will inform and guide agency decision-makers. In this sense, it is a communication tool. Further, by placing these resources within the context of the FEA, they become more meaningful and understandable to senior agency decision-makers who are familiar with OMB's FEA framework.

1.4 INTENDED AUDIENCE

The RM Profile is intended for all business owners and program managers who make informed decisions about IT services, cost targets, and business risks. It applies equally to both the RM and IT communities in the Federal Government and serves as a primer and a resource for agencies developing integrated approaches to managing their data, records, and information. The following individuals should use this RM Profile to support effective decision-making:

(1) Chief Information Officers (CIO). Agency CIOs evaluate the impact of applying management, operational, and technical controls and present options and/or recommendations resulting in appropriate solutions. The RM Profile brings together records management and IT issues to inform decision-making.

(2) Enterprise Architects. The Agency Enterprise Architect supports the acquisition, use, and management of an agency's IT capabilities from varying perspectives (business, data, applications, security, etc.), including records management services. Enterprise Architects ensure that records management is integrated into the Enterprise Architecture and into all phases of IT solution development. The RM Profile can help Enterprise Architects who are familiar with the FEA achieve this goal.

(3) Records Management Officers (RMO). While agency RMOs may be familiar with the specific records management requirements affecting their agency's business, the RM Profile can add value to their understanding by describing these requirements in the context of the FEA. Knowledge of the FEA reference models will better prepare agency RMOs to speak to agency IT staff about integrating records management requirements into agency business processes.

(4) Program/Project Managers. Agency program and project managers are concerned with both strategic and tactical issues affecting the mission of the agency. From Line of Business managers to content owners, the RM Profile is useful as a model that guides decision-making to ensure that risks are mitigated, appropriate controls are in place, and performance measures are monitored.

(5) General Counsels (GC). Agency GC offices are concerned with the legal ramifications of implementing policies, procedures, or technologies. The RM Profile can advise agency GC offices by providing a framework for describing how records management authorities are tied to agency business processes and enterprise architectures.

Chapter 2: Records Management Basics

In order to use the RM Profile effectively, agency decision-makers must understand the fundamentals of records management. This chapter highlights Federal and international records management resources for policy and guidance, key definitions, agency and staff responsibilities, the benefits of effective records management, and the records life cycle.

2.0 NARA POLICY AND GUIDANCE

Effective records management requires the creation and maintenance of authentic, reliable, and accessible records documenting agency functions and activities whether the records are paper or electronic. The Federal Records Act requires the heads of Federal agencies to create and preserve records of agency activities and decisions. The National Archives and Records Administration (NARA) oversees the management of Federal records as a core function, and the Archivist of the United States approves the disposition of all Federal records.

While agencies need to manage all records created and received during the course of Government business in accordance with the Federal Records Act, it is important to note that other statutes, such as the Freedom of Information Act (FOIA) and the Privacy Act, discuss records in different contexts that involve additional recordkeeping requirements. For example, the RM Profile does not specifically address records of individuals or FOIA records but instead concentrates on managing records at a higher level (i.e., at the agency business process level). As such, agencies will need to consider the records management guidance in the RM Profile in addition to any specific requirements in other statutes or policies that relate to their business.

NARA also issues policies and regulations to assist Federal agencies with the management of Federal records in all formats. NARA publishes its regulations in the Code of Federal Regulations ( 36 CFR Parts 1220-1238) and other policy documents, such as NARA Bulletins, are available on NARA's public website ( http://www.archives.gov).

In addition to policy and regulations, NARA develops records management guidance and best practices for Federal agencies to implement. NARA guidance stresses the importance of documenting business processes, ensuring accountability to stakeholders, assessing the value of information assets, and using risk assessment to determine appropriate records management approaches. Many of the more recent products, such as the guidance for the transfer of permanent electronic records to NARA ⁵ and the guidance for managing web records ⁶, assist agencies with the management of electronic records. While most available records management guidance generally applies to records in all formats and media, electronic records in particular present unique challenges for agencies. The volume, complexity, rapid obsolescence of hardware and software, and diversity of formats raise new issues that must be resolved. The RM Profile addresses these new issues in the management of electronic records.

2.1 OTHER GUIDANCE

Several Federal agencies share responsibility for records management oversight. While NARA has primary authority for Federal records management, other agencies such as the General Services Administration (GSA) and OMB also oversee records management in the Government. GSA provides guidance related to economy and efficiency in records management and OMB promotes the coordination of Federal information policy, including records management. As a starting point for agencies, OMB's Circular A-130 ⁷ provides high-level guidance for agencies on the management of Federal information resources.

Outside the Federal Government, sources such as the International Standards Organization (ISO) provide guidance that Federal agencies can use to manage their records. In particular, ISO Records Management Standard 15489-1 ⁸ defines records management and describes the characteristics of an effective records management program. The ISO Records Management Standard 15489-1 is consistent with NARA's approach to records management, emphasizing the importance of trustworthy records and the concepts of authenticity, reliability, integrity, and usability of records.

As noted in Objective #4 in Section 1.3, the RM Profile brings together records management guidance from diverse sources and provides a context that will promote understanding of the various requirements and guidelines.

2.2 DEFINITIONS

Defined below are selected key terms that provide the necessary context for the following chapters. For a more detailed glossary of terms, please refer to Appendix B of this document.

Information means any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual forms (A-130, 6(j)).

Information system is a discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual. An electronic information system is a system that contains and provides access to computerized Federal records and other information ( 36 CFR 1234.2).

Records are 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 data in them. Library or museum material made or acquired and preserved solely for reference or exhibition purposes, extra copies of documents preserved only for convenience of reference, and stocks of publications and of processed documents are not included ( 44 USC 3301).

Electronic records include numeric, graphic, and text information, which may be recorded on any medium capable of being read by a computer and which satisfy the definition of a record. This includes, but is not limited to, magnetic media, such as tapes and disks, and optical disks. Unless otherwise noted, these requirements apply to all electronic information systems, whether on microcomputers, minicomputers, or mainframe computers, regardless of storage media, in network or stand-alone configurations ( 36 CFR 1234.1).

Records management is the field of management responsible for the systematic control of the creation, maintenance, use, and disposition of records. From the Federal perspective, it is the planning, controlling, directing, organizing, training, promoting, and other managerial activities involved in records creation, maintenance and use, and 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 ( 44 USC 2901).

Recordkeeping requirements are defined as 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 ( 36 CFR 1220.14). Agencies may also identify recordkeeping requirements in their business and systems processes that are not mandated by laws or regulations but are equally valid. Recordkeeping requirements should be outlined in procedural manuals and other issuances that specify which records need to be included in agency files or other recordkeeping systems.

2.3 THE RECORDS LIFE CYCLE

As illustrated in Exhibit 2.0, the records life cycle consists of three stages: creation or receipt of the record; maintenance and use of the record; and disposition of the record (either destruction or transfer to the permanent holdings of the National Archives). Conceptually, Federal records span the period of time that they are in agency custody. The records life cycle concept ensures that agencies consider records management requirements throughout the life of a record, and not just at the point of disposition when the record is no longer needed by the agency.

Exhibit 2.0. Records Life Cycle

At each stage of the life cycle, agencies must address records management requirements for all records regardless of the format or media in which they are created or maintained. In fact, agencies must consider recordkeeping requirements for records (and systems of records) before they are created. In most cases, agencies will need to plan how staff will create and manage their records before designing and implementing the processes and systems that produce them. In this respect, the records life cycle - specifically regarding the consideration of recordkeeping requirements - begins prior to the first stage of the traditional records life cycle that starts with the creation or receipt of a record.

Additionally, it is important to note that the records life cycle is distinct from the systems life cycle (please refer to Chapter 4 for a more detailed discussion of the systems life cycle). The systems life cycle, or systems development life cycle (SDLC), applies to agency processes for developing and implementing agency information systems. The records life cycle, on the other hand, demands that agencies manage their records from creation through final disposition regardless of the system in which they reside. The most effective way to manage electronic records is to embed records management requirements into each stage of the SDLC.

2.4 THE VALUE OF EFFECTIVE RECORDS MANAGEMENT

Records enable and support an agency's work to fulfill its mission. Since records are a critical resource for achieving agency goals and reducing costs, it is essential that agencies systematically manage their records.

A systematic and strategic approach to managing Government records, as envisioned in the RM Profile, requires a better understanding of the strategic goals that agencies should use as a guide in managing their records. At a high level, NARA sets forth three records management goals to ensure that agencies:

economically and effectively create and manage records necessary to meet business needs,
maintain records long enough to protect rights and assure accountability, and
preserve all records and ensure their accessibility for as long as needed.

By meeting these three goals as part of coordinated records, information, and knowledge management strategies, agencies will be able to adapt to the demands of an evolving business environment. A sound records management program not only fulfills requirements of law and policy for records management but also has the following benefits for programs and processes:

Retrieve and access records for as long as needed, regardless of the format in which they were created.
Realize cost savings by aligning record storage and protection requirements with business value.
Support policy formulation and managerial decision-making.
Compliance with legal and regulatory recordkeeping requirements and agency-specific guidance.
Conduct Government business in an orderly and efficient manner. Implementation procedures are clear to users and consistent across the enterprise.
Ensure accountability to the public and other stakeholders.
Create authentic and reliable records supporting agency business processes.
Establish a framework supporting the growth of institutional knowledge and the preservation of institutional memory.
Promote information assurance, including the preservation of vital records and continuity of operations records in the event of a disaster.
Ensure timely and legal disposition of records to enhance governmental efficiency and minimize the exposure to litigation on records no longer needed by the agency.
Improve agency response to legal demands requiring the immediate retrieval and/or preservation of records.
Respond to governmental inquiries and public requests for records (e.g., congressional inquiries, FOIA, civil discovery, subpoenas).

Federal agencies should view records management as an opportunity to develop a program that promotes efficiency within the agency and responsiveness to external stakeholders and customers. Further, a sound records management program will position agencies better to use the RM Profile to maximum effect as agency managers understand and support the records management requirements, principles, and practices described in the Profile.

2.5 AGENCY RESPONSIBILITIES FOR RECORDS MANAGEMENT

Every Federal agency is legally required to manage its records as evidence of the agency's actions. Specific legal requirements for records management are specified in 44 USC Chapter 31 and in OMB Circular No. A-130 include:

(1) Making and preserving records that contain adequate and proper documentation of the organization, functions, policies, decisions, procedures, and essential transactions of the agency and designed to furnish the information necessary to protect the legal and financial rights of the Government and of persons directly affected by the agency's activities (44 USC 3101).

(2) Establishing and maintaining an active, continuing program for the economical and efficient management of the records of the agency (44 USC 3102).

(3) In a timely fashion, establish, and obtain the approval of the Archivist of the United States for retention schedules for Federal records (A-130, 8a(4)c); and

(4) Provide training and guidance as appropriate to all agency officials, employees, and contractors on their Federal records management responsibilities (A-130, 8a(4)d).

2.6 AGENCY RESPONSIBILITIES FOR INFORMATION RESOURCES MANAGEMENT

Agency Information Resource Management (IRM) officials oversee the management of information and records as valuable business resources. These resources provide the public with knowledge of the Government, society, and economy -- past, present, and future. They ensure the accountability of the Government to manage its operations and to maintain the healthy performance of the economy. As described in OMB Circular No. A-130, agencies have responsibilities for developing integrated strategies for managing information and records. Agencies must:

(1) Incorporate records management and archival functions into the design, development, and implementation of information systems, including providing for public access to records where required or appropriate (A-130, 8a(1)k1);

(2) Integrate planning for information systems with plans for resource allocation and use, including budgeting, acquisition, and use of information technology (A-130, 8a(1)e);

(3) Protect government information commensurate with the risk and magnitude of harm that could result from the loss, misuse, or unauthorized access to or modification of such information (A-130, 8a(1)g); and

(4) Seek to satisfy new information needs through interagency or intergovernmental sharing of information, or through commercial sources, where appropriate, before creating or collecting new information (A-130, 8a(1)d).

2.7 STAFF RESPONSIBILITIES

Federal employees have an individual responsibility for making and keeping records of their work. Federal employees have three basic obligations regarding Federal records:

(1) Create records to do the business of their agency, record decisions and actions taken, and document activities for which they are responsible;

(2) Manage records to ensure they can be found when needed. This means setting up good directories and files, and managing them (in whatever format) in a manner that allows them to be stored and retrieved efficiently; and

(3) Carry out the disposition of records under their control in accordance with agency records schedules ⁹ and Federal regulations.

The following chapters include an overview of the FEA reference models and guidance for agencies on how to use these models and the RM Profile to achieve many of the RM benefits while avoiding the consequences of not managing records effectively. Presented as a high-level framework, the RM Profile assists agencies with developing and implementing appropriate records management policies and procedures and integrating them into their business decision-making processes.

Chapter 3: Overview of the Federal Enterprise Architecture

Developed collaboratively by Federal Agencies, the Federal Chief Information Officers (CIO) Council, and the Office of Management and Budget (OMB), the Federal Enterprise Architecture (FEA) is a business and performance-based framework for Government-wide improvement. The framework includes a collection of interrelated reference models: the Business Reference Model (BRM), Service Component Reference Model (SRM), Technical Reference Model (TRM), Data Reference Model (DRM), and Performance Reference Model (PRM).

Federal agencies are currently using the FEA reference models to plan and develop their annual budgets and set strategic goals. Agencies' annual budget submissions to OMB for IT must describe how these investments "align" to the business, performance, service component, and technical reference models. In practical terms, this means that agencies must describe their IT investments in terms of the business operations they will support, the functional capabilities they intend to deliver, the supporting technologies used to build or deliver the capabilities, and performance impacts.

By providing a common language to describe the relationship between Federal business operations, technology, and information, the FEA enables the Government to identify opportunities to leverage technology to:

Reduce unnecessary redundancy;
Facilitate intergovernmental information sharing;
Establish a direct relationship between IT and agency performance to support citizen-centered, customer-focused Government; and
Maximize IT investments to better achieve mission outcomes.

The FEA reference models are explained in detail in a series of documents available on OMB's website at http://www.whitehouse.gov/omb/egov/a-1-fea.html.

3.0 RECORDS MANAGEMENT AND THE FEA

The objective of the FEA is to facilitate government-wide improvement. For this reason, OMB and the Federal CIO Council believe that agencies can use the FEA to improve their records management activities. Records management cross-cuts each of the FEA reference models, and, in fact, supports every Federal Line of Business and Sub-function. Exhibit 3.0, below, summarizes the records management resources cited in this Chapter and shows how they align with each of the five FEA reference models.

Exhibit 3.0. Viewing Records Management through the FEA

The RM Profile addresses records management in similar fashion to how The FEA Security and Privacy Profile, Phase I addresses security and privacy issues. ¹⁰ The Federal CIO Council recommended the Security and Privacy Profile, which provides a framework to help agencies incorporate security controls into their business processes, as a model upon which to base the RM Profile.

First, however, it is important to understand the structure and purpose of the reference models, how they fit together, and how agencies can use them as context for applying effective records management practices. The following sections of this chapter provide (1) overviews of each FEA reference model; (2) a description of how each model addresses, or will address, records management; and (3) a discussion of various records management resources applicable to each reference model that are available to help agencies improve their records management programs.

3.1 OVERVIEW OF THE BUSINESS REFERENCE MODEL

The BRM provides a means to describe the business operations of the Federal Government, independent of the agencies that perform them. The model is the primary "layer" of the FEA, and the foundation for the analysis of service components, technology, data, and performance.

In the model of the BRM below, four Business Areas separate Government operations into high-level categories relating to the purpose of Government (Services for Citizens), the mechanisms the Government uses to achieve its purpose (Mode of Delivery), the support functions necessary to conduct Government operations (Support Delivery of Services), and the resource management functions that support all areas of the Government's business (Management of Government Resources).

The model's four Business Areas are decomposed into 39 Lines of Business. Each business line includes a collection of Sub-functions that represent the lowest level of granularity in the BRM. For example, the Environmental Management Line of Business encompasses three Sub-functions: (1) Environmental Monitoring and Forecasting; (2) Environmental Remediation; and (3) Pollution Prevention and Control.

Within each Sub-function are the agency-specific business functions, processes, and activities. This level of detail is outside the boundary of the BRM, and as such, they are not shown in Exhibit 3.1. The FEA website provides a complete listing at http://www.egov.gov.

Exhibit 3.1. Business Reference Model

3.1.1 Records Management within the BRM

The records management function exists within two separate Lines of Business of the BRM.

Support Delivery of Services Business Area General Government Line of Business Central Records and Statistics Management Sub-function. This Sub-function is reserved for the "...management of records and statistics for the Federal Government as a whole, such as the records management performed by NARA and the statistics and data collection performed by the Bureau of the Census. For example, NARA efforts to improve records disposition activities and the Electronic Records Archives initiative are aligned to this Sub-function.

Example...
While agency initiatives to improve records management have a specific "home" within the BRM, it is important to note that Federal records creation, use, and maintenance occur within all Federal business processes (and, hence, Sub-functions and Lines of Business). For example:

Draft and final versions of testimony before Congress are records created/received within the Legislative Relations Line of Business Legislative Testimony Sub-function
Draft and final versions of procurement-related documents (e.g., Statements of Work, contracts, correspondence) are records created/received within the Supply Chain Management Line of Business Services Acquisition Sub-function.

Ma Technology Management Line of Business Record Retention Sub-function. This Sub-function is reserved for the "...operations surroundnagement of Government Resources Business Area Information and ing the management of the official documents and records for an agency." Examples include agency efforts to improve records management activities, such as acquiring an enterprise-wide electronic records management (ERM) application.

NARA, OMB, and the Federal CIO Council believe that the BRM can be improved to adequately capture the full life cycle of records management activities. Records retention is but one of many records activities that agencies perform. OMB and the Federal CIO Council will work to ensure that future versions of the BRM accurately reflect the full range of records activities in which agencies engage - records creation, receipt, maintenance, use, and disposition.

3.1.2 Records Management Resources for the BRM

Example...
An example of an agency-specific records requirement based upon Line of Business considerations concerns the Federal program to license and construct a high-level radioactive waste repository. Initiatives related to this effort are aligned to the Regulatory Compliance and Enforcement Line of Business Permits and Licensing Sub-function.

The Department of Energy will submit an application to the Nuclear Regulatory Commission to license a repository for construction. To shorten the time spent on the exchange of records that may be used as evidence in the licensing proceeding, the parties to the proceeding are required to make their records available via the Internet. The Commission's Licensing Support Network provides a single place where the parties and potential parties to the licensing hearing can search for records in a uniform way.

Based upon an analysis of a select number of Lines of Business, NARA has determined that the records management requirements to which all Federal agencies must comply are derived from two sources - Federal statutes and regulations, and agency-specific policies and procedures. Agency-specific requirements are often based upon the Line of Business and Sub-function to which agencies' programs and operations are aligned.

The RM Profile does not identify agency-specific recordkeeping requirements. However, NARA has established certain high-level goals that agencies should consider as guiding principles for their records management programs. These include:

Focusing on those records that are essential to agency mission and business operations, as well as to the Government as a whole for accountability, protection of rights, and documentation of the national experience. This will help NARA and Federal agencies to focus attention and resources on a smaller number of Government functions.

Establishing priorities for committing records management resources based on three criteria: the degree to which records relate to rights and accountability, the degree to which records in a program area are at risk, and the degree to which they create records with long-term value.

Within the context of the BRM, there are many records management resources that will help agencies meet these goals. In addition to the resources cited below and throughout this chapter, Appendix A: Selected Resources includes other relevant records management resources.

3.1.2.1 NARA Regulations and Guidance ( http://www.archives.gov/records-mgmt/index.html)

Agencies should refer to NARA regulations codified in Title 36 of the Code of Federal Regulations for requirements that apply to all Federal agencies. These requirements cover each stage of the records life cycle (e.g., from records creation and management through final disposition) and provide specific guidance for managing electronic records, email, and other formats. In addition, there are a number of guidance products on the NARA website that provide updated guidance, including products on managing website records and guidance on implementing electronic signatures in compliance with the Government Paperwork Elimination Act (GPEA).

Records Management Resources for the BRM

ISO 15489-1 - Information and Documentation - Records Management
OMB Circular A-130
ERM Guidance on Methodology for Determining Agency-Unique Requirements
NARA regulations and guidance, including:
- Guidance for Coordinating the Evaluation of Capital Planning and Investment Control Proposals for ERM Applications
- Guidance on Managing Web Records

3.1.2.2 ISO 15489-1
Information and Documentation - Records Management, Part 1: General ( http://www.niso.org/international/index.html and http://webstore.ansi.org/ansidocstore/default.asp. In addition, agencies may obtain a discount on standards available through GSA Advantage ( https://www.gsaadvantage.gov/advgsa/advantage/main/start_page.do)

In 2001, the International Organization for Standardization - a worldwide federation of national standards bodies - issued an international standard for records management to ensure that attention and protection are given to all records and that organizations can retrieve the evidence and information they contain more efficiently and effectively, using standard practices and procedures. The standard provides guidance on:

determining the responsibilities of organizations for records and records policies, procedures, systems, and processes;
records management in support of a quality process framework to comply with ISO 9001 and ISO 14001; and
the design and implementation of a records system.

3.1.2.3 Electronic Records Management Guidance on Methodology for Determining Agency-Unique Requirements (http://www.archives.gov/records-mgmt/policy/requirements-guidance.html)

NARA has issued guidance to help agencies manage the requirements analysis step of an enterprise-wide ERM acquisition project. Section One of the guidance, Requirements Gathering Beyond DoD 5015.2-STD, proposes a series of steps to assist agencies in identifying agency-specific ERM requirements. Section Two of the guidance, Requirements Analysis, proposes additional steps to assist agencies in analyzing their agency-specific ERM requirements.

3.1.2.4 Guidance for Coordinating the Evaluation of Capital Planning and Investment Control (CPIC) Proposals for ERM Applications ( http://www.archives.gov/records-mgmt/policy/cpic-guidance.html)

NARA has issued guidance to help Federal agencies evaluate CPIC proposals for ERM applications from the perspective of encouraging an enterprise-wide approach. The guidance was developed to help agencies coordinate and control the acquisition and implementation of ERM capabilities enterprise-wide. The criteria presented in the guidance provide a set of decision points to help agencies determine whether to fund office-specific ERM systems independently or integrated with an agency's enterprise-wide ERM system.

3.1.2.5 NARA Guidance on Managing Web Records ( http://www.archives.gov/records-mgmt/policy/managing-web-records-index.html)

NARA has issued guidance to provide agencies with an initial, high-level framework for managing the content records on their websites as well as the records documenting website operations. The guidance is based on statutory requirements and sets forth principles that form a sound basis for agency website management operations. While the guidance primarily discusses public Internet websites, it is equally applicable to websites that may be on agency intranets, virtual private networks, and security-classified websites.

Part One of the guidance provides general background information identifies records management responsibilities for agency websites, and highlights the statutory and regulatory requirements that apply to agency web operations. Part Two of the guidance, Managing Web Records, is geared to the needs of program officials, who provide the information posted on websites, and agency staff responsible for managing websites, including webmasters and IT staff. Part Three of the guidance, Scheduling Web Records, assists agency staff (e.g., records officers and webmasters) in developing records schedules for the records relating to the agency internet and intranet websites.

3.1.2.6 OMB Circular A-130, Management of Federal Information Resources (http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html)

OMB Circular A-130 establishes policy for the management of Federal information resources. With respect to records management, the circular directs agencies to:

record, preserve, and make accessible sufficient information to ensure the management and accountability of agency programs, and to protect the legal and financial rights of the Federal Government;
incorporate records management and archival functions into the design, development, and implementation of records systems;
establish and obtain in a timely fashion the approval of the Archivist of the United States for retention schedules for Federal records;
provide for public access to records where required or appropriate;
implement and enforce applicable records management policies and procedures, including requirements for archiving information maintained in electronic format, particularly in the planning, design and operation of information systems;
ensure the ability to access records regardless of form or medium; and
provide records management training and guidance.

3.2 OVERVIEW OF THE SERVICE COMPONENT REFERENCE MODEL

The Service Component Reference Model (SRM) categorizes components with respect to how they support business and/or performance objectives. ¹¹ The SRM helps agencies assemble IT solutions through the sharing and re-use of business and service components. The effective identification, assembly, and use of components allow for aggregate business services to be shared within and across agencies.

As illustrated in Exhibit 3.2, the SRM identifies seven Service Domains that provide a high-level view of the services and capabilities that support enterprise- and organization-wide processes and applications. Each Service Domain breaks down into one or more Service Types that group similar capabilities in support of the Domain. Each Service Type is decomposed further into one or more components that provide the "building blocks" to deliver the capability to the business.

The model's seven Service Domains include:

The Customer Services Domain - the capabilities that are directly related to the end customer, the interaction between the business and the customer, and the customer-driven activities or functions.
The Process Automation Services Domain - the capabilities that support the automation of process and management activities that assist in effectively managing the business.
The Business Management Services Domain - the capabilities that support the management and execution of business functions and organizational activities that maintain continuity across the business and value-chain participants.
The Digital Asset Services Domain - consists of the capabilities that support the generation, management, and distribution of intellectual property and electronic media across the business and extended enterprise.
The Business Analytical Services Domain - consists of the capabilities that support the extraction, aggregation, and presentation of information to facilitate decision analysis and business evaluation.
The Back Office Services Domain consists of the capabilities that support the management of enterprise planning transactional-based functions.
The Support Services Domain consists of cross-functional capabilities that can be leveraged independently of the Service Domain objective or mission.

Exhibit 3.2. Service Component Reference Model

The SRM is composed of seven Service Domains: Customer Services; Process Automation Services; Business Management Services; Digital Asset Services; Business Analytical Services; Back Office Services; and Support Services

Each Service Domain is decomposed into Service Types. For example, the three Service Types associated with the Customer Services Domain are: Customer Preferences; Customer Relationship Management; and Customer Initiated Assistance.

Each Service Type is decomposed further into components. For example, the four components within the Customer Preferences Service Type include: Personalization; Subscriptions; Alerts and Notifications; and Profile Management

Components are not shown in Exhibit 3.2. For a complete listing, refer to the FEA website at http://www.egov.gov.

The Federal CIO Council's AIC developed a White Paper for Federal agencies that outlines the concept of service components and how agencies may use and reuse them within a variety of architectural implementations. The AIC published the original version of Service Component-Based Architectures in 2004, and it is now being updated to reflect the advancement and maturity of the FEA, new technologies and architectural frameworks, and proven industry best practices. ¹²

3.2.1 Records Management within the SRM

The SRM's Digital Asset Services Domain defines records management components as "...the set of capabilities to support the storage, protection, archiving, classification, and retirement of documents and information." Currently, the SRM identifies four components:

Digital Rights Management - the set of capabilities that support the claim and ownership of intellectual capital and artifacts of an organization.
Document Classification - the set of capabilities that support the categorization of documents and artifacts, both electronic and physical.
Document Retirement - the set of capabilities that support the termination or cancellation of documents and artifacts used by an organization and its stakeholders.
Record Linking / Association - the set of capabilities that support the correlation between logical data and information sets.

3.2.2 Records Management Resources for the SRM

Records Management Resources for the SRM

NARA, RMSC Requirements Report

As part of the E-Government ERM initiative, NARA and partner agencies identified, documented, and prioritized records management activities that can be supported with software service components in a component-based architecture. Participants also drafted baseline functional requirements for Records Management Service Components (RMSC). The goals of the RMSC effort are to:

facilitate the potential acquisition of RMSCs that can be used to provide interoperable records management functionality in any agency system that creates and/or manages electronic records; and
enable the vendor and developer communities to integrate RMSCs into their products and services by extending records management across any point in the business process.

RMSCs will allow the management of records to begin much earlier in the business or mission process. (Current solutions, such as records management applications currently on the market, are usually add-ons to agency business processes and IT systems, rather than integral elements of the processes and systems.) Records management services would be available to users within the agency's enterprise architecture from their point of creation or receipt and possibly within their native applications. This will allow more efficient and effective management of records throughout their life cycle.

The RMSC Program's first activity was the Requirements Development Project. This project included collaborative sessions with agency records management and enterprise architecture experts appointed by agency CIOs and E-Gov managers, who identified and prioritized functional requirements for core records management activities that service components should support. The stakeholders reached a consensus on six records management activities that are identified below in Exhibit 3.3. NARA is continuing its work with the industry on defining RMSCs for future development, acquisition, and use by agencies with the appropriate security and access controls. The baseline functional requirements associated with each of these components are available for review on NARA's website at http://www.archives.gov/era/rms/ and at http://www.CORE.gov (see the following section for a discussion of www.CORE.gov.) For a more detailed discussion of how agencies might use RMSCs, please see Chapters 4 and 5.

Exhibit 3.3. Records Management Activities Supportable by Service Components (DRAFT)

RM Activities	Definition
Capture Record	Capture information with associated attributes in an electronic system.
Assign Disposition	Using an established disposition authority, assign the disposition schedule, item number, and disposition instructions to the record.
Categorize Record	Utilizing agency business rules, assign an appropriate descriptive label to the records to facilitate management in an electronic system.
Ensure Authenticity	Ensure the acceptability of a record as genuine, based on its characteristics such as structure, content, and context.
Associate Record	Provide the capability to associate a record to one or more other records through a Record Association attribute.
Execute Disposition	Implement destruction, transfer, or continued retention of a record in accordance with the established disposition authority. After validation that the disposition action is valid, execute the disposition action, and record the transaction.

3.2.3 Creating Registries for Components

Included within the effort to develop the FEA is the development of a registry -- a place Federal agencies can use to search for and locate a specific business or service component that meets their needs, or to find components they can customize to meet unique requirements. This registry, still in its infancy and termed CORE.gov, is accessible at www.core.gov and will:

Facilitate the rapid discovery and assembly of service components.
Catalog components that have been tested, approved, and certified for reuse.
Enable users to locate, evaluate, share, and download components.
Facilitate collaboration with others on component development.
Allow users to enhance downloaded components to meet their specific needs.

3.2.4 Linking the Business and Service Component Reference Models

The most granular layer of the BRM is the Sub-function layer, which stays at a high level to categorize the work agencies perform, and does not document the lower-level business processes that may vary across agencies. However, several of the Federal Line of Business Initiatives have begun to identify and standardize business processes across agencies as part of their efforts to develop common solutions and target architectures. As agencies redefine and develop their business processes, the Federal CIO Council and OMB will work to incorporate these collaborative solutions supporting interagency and intra-agency processes into the FEA.

3.3 OVERVIEW OF THE TECHNICAL REFERENCE MODEL

The Technical Reference Model (TRM) provides a foundation to describe the standards, specifications, and technologies supporting business and service components and E-Government solutions. The model identifies the technology elements that collectively support the adoption and implementation of technical architectures and provides the foundation to advance the re-use of technology and component services across the Federal Government through standardization.

As illustrated in Exhibit 3.4, the TRM is comprised of four Service Areas that group the requirements of technical architectures into functional areas. Service areas are decomposed into Service Categories, which classify lower levels of technologies, standards, and specifications in accordance with the business or technology function they serve.

The four Service Areas of the TRM include:

Service Access and Delivery - refers to the collection of standards and specifications to support external access, exchange, and delivery of service components or capabilities.
Service Platform & Infrastructure - refers to the collection of delivery and support platforms, infrastructure capabilities, and hardware requirements to support the construction, maintenance, and availability of a Service Component or capability.
Component Framework - refers to the underlying foundation, technologies, standards, and specifications by which Service Components are built, exchanged, and deployed across component-based, distributed, or service-oriented architectures.
Service Interface and Integration - refers to the collection of technologies, methodologies, standards, and specifications that govern how agencies will interface (both internally and externally) with service components. This area also defines the methods by which components will interface and integrate with back office/legacy assets.

Exhibit 3.4. Technical Reference Model

The TRM is composed of four Service Areas: Service Access and Delivery; Service Platform and Infrastructure; Component Framework; and Service Interface and Integration.

Supporting each Service Area is a collection of Service Categories -- used to categorize lower levels of technologies, standards and specifications in accordance with the business or technology function they serve. For example, the Service Access and Delivery Service Area includes four Service Categories: Access Channels; Delivery Channels; Service Requirements; and Service Transport.

Each Service Category is supported by one or more service technologies, standards, or specifications. For example, the Web Browser Service Category is supported by the two most widely used browsers: Internet Explorer and Netscape Communicator.

Technologies, standards and specifications are not shown in Exhibit 3.4. For a complete listing, refer to the FEA website, www.egov.gov.

Technical Reference Model

3.3.1 Records Management within the TRM

Currently, the TRM does not include or address records management. However, as the TRM continues to mature, it is reasonable to expect that it will incorporate NARA requirements in Title 36 of the Code of Federal Regulations (36 CFR) pertaining to the adequacy of documentation and the disposition of records, and GSA requirements in 41 CFR pertaining to the economy and efficiency of records management.

These legal mandates that agencies must consider in developing IT solutions are captured in the Service Access and Delivery Service Area Service Requirements Service Category Legislative / Compliance Service Standard.

For example, the Section 508 specification for computer usability defines the prerequisites that an application, system, or service must have, mandated by Congress or other governing bodies. The illustration above shows how the TRM's Legislative / Compliance Service Standard includes this specification.

Another potential area within the TRM to address technical standards and specifications related to records management is within the Service Platform and Infrastructure Service Area Software Software Engineering Service Category. This Service Category covers the technical aspects of building software systems, as well as management issues such as configuration management and testing. The design criteria for ERM software applications set forth in the Department of Defense (DoD) 5015.2-STD align with the Software Engineering Service Category.

NARA will work with OMB and the Federal CIO Council to ensure that the next version of the TRM adequately addresses records management standards and specifications.

3.3.2 Value of the TRM and SRM for Records Management

The TRM presents standards and specifications that can describe the technical environment in which an RMA exists, and thereby, for example, indicate the interface specifications required between the RMA and other applications in support of a given service. Using the TRM requires the SRM for context. An IT solution comprised of TRM components exists to perform a particular service, such as managing records or sharing records or retiring records. For example, an agency would first look to the SRM for a service related to retiring records, and then look for an IT solution that performs records retirement.

Food for Thought...
As records management becomes a process integral to other processes, one can envision a future standard being developed for the interface or integration of applications that will automatically preserve a record through its life cycle using technology that will be transparent to users.

There are potentially many IT solutions that perform this service, and an agency is best served by finding a solution that is compatible with its own technical environment.

An ultimate goal of the RMSC in combination with registries and repositories like CORE.gov is to assist agencies in discovering workable end-to-end IT solutions that standardize records management services and maximize the efficiency and effectiveness of Government operations.

3.3.3 Records Management Resources for the TRM

There are several records management resources that can help agencies understand their recordkeeping requirements and the technical standards and technologies that help to ensure compliance with such requirements. The following sections identify and briefly describe these resources.

3.3.3.1 DoD 5015.2-STD
Design Criteria Standard for Electronic Records Management Software Applications
http://www.dtic.mil/whs/directives/corres/pdf/50152std_061902/p50152s.pdf

NARA has endorsed the Department of Defense ERM Software Application Design Criteria Standard (DoD 5015.2-STD, June 2002) as one possible approach Federal agencies may use to manage electronic records. DoD 5015.2-STD defines a baseline set of requirements for automated record keeping. DoD tests and certifies software products to ensure compliance with the mandatory requirements of the standard. Agencies are encouraged to use the standard and DoD 5015.2-STD

Records Management Resources for the TRM

DoD 5015.2-STD
NARA, Records Management Guidance for Agencies Implementing E-Signature Technologies
NARA, Records Management Guidance for PKI Digital Signature Authenticated and Secured Transaction Records
NARA, Records Management Guidance for PKI-Unique Administrative Records
NARA, Transfer Instructions for Permanent Electronic Records

certified products as a baseline when selecting an RMA to manage the agency's electronic records.

The standard sets forth mandatory baseline functional requirements; identifies non-mandatory features deemed desirable for RMA software; defines required system interfaces and search criteria to be supported by RMAs; incorporates requirements for classified marking, access control, declassification and downgrading, and other issues; and describes the minimum records management requirements that must be met, based on current NARA regulations. Additionally, the standard also specifies software engineering practices and business rules for agencies to follow when developing RMAs.

3.3.3.2 Records Management Guidance for Agencies Implementing E-Signature Technologies ( http://www.archives.gov/records-mgmt/policy/electronic-signature-technology.html)

NARA has issued guidance that focuses on records management issues involving records created using e-signature technology. In systems implemented as a result of GPEA, records management requirements will form the core of the IT system requirements. In implementing e-signature technologies, agency IT staff should recognize that signatures are an integral part of a record. If the record needs to be preserved, whether for a finite period of time or permanently, then the agency needs to ensure the trustworthiness of the electronically signed record over time.

The guidance discusses the records management principles that apply to e-signature technology, and:

the characteristics of trustworthy records and approaches agencies can take to ensure the trustworthiness of electronically-signed records;
special considerations when dealing with the preservation of records that are augmented by e-signatures;
the importance of implementing non-repudiation services;
approaches for determining which e-signature records to maintain;
the modification of agencies' records schedules to cover e-signature records;
special considerations relating to long-term, electronically-signed records that preserve legal rights; and
specific NARA requirements for permanent, electronically-signed records.

To help ensure appropriate recordkeeping for Federal agencies employing public key infrastructure (PKI) in their programs, NARA and the Legal and Policy Working Group of the Federal Identity Credentialing Committee (which operates under the mandate of the Federal CIO Council), have issued the following additional guidance on PKI.

3.3.3.2.1 Records Management Guidance for PKI Digital Signature Authenticated and Secured Transaction Records

( http://www.archives.gov/records-mgmt/policy/pki.html)

The purpose of this detailed guidance is to assist Federal agencies in the management of PKI digital signature authenticated and secured transaction records in their normal course of conducting electronic commerce.

3.3.3.2.2 Records Management Guidance for PKI-Unique Administrative Records
(http://www.archives.gov/records-mgmt/policy/pki-guidance.html)

This document provides records management guidance for both operational and recordkeeping environments that will assist Federal agencies in the management of administrative records produced or received during the planning, implementation, operation, audit or monitoring, and reorganization or termination of a PKI. The guidance defines and describes the requirements (or "what" is needed) for meeting records management regulations and good recordkeeping practices for PKI-unique administrative records. It does not suggest "how" agencies should implement these requirements, or indicate which technology or products agencies should use for implementation.

3.3.3.3 NARA Transfer Instructions for Permanent Electronic Records
http://www.archives.gov/records-mgmt/initiatives/erm-products.html

As part of the ERM E-Gov Initiative to improve ERM in Federal agencies, and in cooperation with other Federal agencies, NARA has issued guidance to supplement current requirements in 36 CFR Part 1228.270 for transferring permanent electronic records to NARA. The guidance expands currently acceptable formats to enable the transfer of (1) email with attachments; (2) scanned textual images; (3) PDF; (4) digital photographic records; (5) geospatial data records, and (6) web content records. The guidance includes requirements for creating and transferring these electronic records to NARA.

3.4 OVERVIEW OF THE DATA REFERENCE MODEL

Achieving two major goals of the FEA - information sharing and improved effectiveness of Federal IT investments - requires the ability to identify and use common data across the Federal Government. The Data Reference Model (DRM) helps to achieve these goals by promoting the common identification, use, and appropriate sharing of data and information across agencies. Records, which are an important subset of data and information, are relevant to the DRM in that the effective management and exchange of records is contingent on the DRM. The DRM uses a flexible and standards-based approach to describe the categorization, exchange, and structure of data, information, and records. Unlike the other reference models that are populated with components, the DRM currently exists only as a framework. The evolution of the DRM, including its framework and how it addresses records, is ongoing and subject to potentially dramatic changes. While enhancement, expansion, and clarity are expected, the basic principles discussed in this section will likely remain viable.

The DRM describes three basic standardization areas, as illustrated below in Exhibit 3.5:

Data Context (Categorization of Data) - A standard approach to representing taxonomies that an agency uses to categorize its data. Such categorization enables the business context of data to be well understood.
Data Sharing (Exchange of Data) - A standard approach to describing the characteristics and requirements of interagency data exchanges, including data sources. Defines a standard message structure known as an Information Exchange Package.
Data Description (Structure of Data) - A standard approach to describing an agency's structured, semi-structured, and unstructured data. Structured data includes individual entities (such as those defined within a data architecture), their attributes, and the relationships between them. Unstructured data includes multimedia files, and documents created using earlier versions of applications such as Microsoft Word. Semi-structured data includes Web pages and emails.

The categorization of data (business context) and the structure of data (data element) support the exchange of data (information exchange package).

Exhibit 3.5. Data Reference Model Structure

3.4.1 DRM Components

3.4.1.1 Categorization of Data

The business context represents the general business purpose of the data and uses the BRM as its categorization taxonomy. This information is valuable for the exchange of records as it helps the recipient (user or system) to view and process the information in the proper context. As shown in Exhibit 3.6, the business context Subject Area is closely aligned to one or more BRM Lines of Business, and the Super Type suggests alignment to more specific business processes or activities.

Exhibit 3.6. Data Reference Model "Categorization of Data" Area

With respect to the creation of a record, the Subject Area indicates the BRM business context (e.g., Line of Business) within which the record was created or is applicable. The Super Type indicates the specific business process or activity that resulted in the record creation. For example, if one agency wants to exchange "permit" data with another agency, then the business context (subject area and super type) associated with "permit" in this exchange will differentiate whether the permit relates to Recreational Resource Management and Tourism, a Sub-function under the Natural Resources Line of Business, or to Permits and Licensing, a Sub-function under the Regulatory Compliance and Enforcement Line of Business. While both permits are records, a permit associated with recreational park use is much different than a permit to drill for offshore oil.

3.4.1.2 Exchange of Data

In order to achieve maximum interoperability for data exchanges among systems, it is necessary to specify a standard message structure that systems can understand or easily interpret. This is the purpose of the DRM Information Exchange Package, which represents a set of data that is transmitted for a specific business purpose. The package contains data that either are generated or required by a unit of work or a business transaction.

The information exchange package makes use of the DRM's ability to categorize and structure data, thereby further facilitating the sharing of information and/or records. Consider the transmission of a record between RMAs. If both RMAs transmit/receive data that conform to the DRM information exchange package format, they can interoperate seamlessly because they each have a common understanding of all aspects of the data - the business context, the message format, and the data contained within the message. That is, the sending RMA will transmit the record and its metadata in a format that is understandable and processable by the receiving RMA.

Exhibit 3.7. Information Exchange Package

Federal records are information exchange packages. They require characteristics and metadata about the data contained within the record, and also metadata about the entire record as a whole. This creates a challenge for the evolution of the DRM in that an information exchange package must be identified as a record and then associated with record metadata. This has yet to be resolved, but has been identified as a requirement.

3.4.1.3 Structure of Data

In addition to providing the business context of data, the DRM specifies a standard way to describe the structure of data through a mechanism for associating properties of a data element. As shown in Exhibit 3.8, this mechanism is comprised of three constructs:

Exhibit 3.8. Data Reference Model "Structure of Data" Area

A set of data elements, comprised of the constructs described above, establish an information package exchanged within a given business transaction.

3.4.2 Metadata and Registries/Repositories

Data elements are aggregated into meaningful information, often becoming a record as they are aggregated. Records are not limited to, nor defined by any particular subject area or particular group of data elements. However, when agencies create records in the conduct of public business, the data or information aggregation (now a record) must abide by specific business rules for records management.

Metadata is data that defines and describes other data. Metadata about a record includes properties such as author or originator, date filed, format, and vital record indicator. A metadata registry is a system for managing metadata for sharable data (i.e., data elements that have precise identifiers, meaning, structures, and values). Data elements can be registered in a metadata registry that serves a particular Community of Interest (COI), ensuring that authoritative metadata (i.e., metadata that is vetted and approved by the COI) is used in all cases for improved access and sharing of data.

For example, the data elements listed in the DoD 5015.2-STD could be registered in a metadata registry along with their specified properties (metadata). RMAs can reference this metadata registry for these data elements, ensuring that they are compliant with their metadata at all times. This further enhances interoperability by ensuring that there is a set of authoritative metadata accessible by all tools, systems, and users for a COI. It also ensures that all tools and systems that process records do so in an accurate manner. Additionally, updates to such metadata can take place in a concentrated place (a single metadata registry or a series of associated metadata registries), which leads to greater control of metadata and greater records processing accuracy. Finally, the business context in which a given data element may be used can also be registered in the metadata registry (as one or more categorizations) and associated with the data element to ensure the use of the data element only within permitted contexts.

For example, a data element that contains a publication date would conform to the requirements listed in DoD 5015.2-STD's minimum metadata profile, as well as additional format requirements as contained in the data representation (e.g., must be of format MM/DD/YYYY). A receiving RMA that recognizes the DRM information exchange package format, as well as the 5015.2-STD metadata requirements, can then receive and process the record in an interoperable manner.

3.4.3 Records Management Resources for the DRM

Within the DRM context, the primary records management resource to which agencies can refer is the DoD 5015.2-STD's minimum metadata profile.

3.4.3.1 DoD 5015.2-STD Minimum Metadata Profile
( http://www.dtic.mil/whs/directives/corres/pdf/50152std_061902/p50152s.pdf)

Records Management Resources for the DRM

DoD 5015.2-STD Minimum Metadata Profile

Recommended for inclusion in the TRM as a Legislative/Compliance Service Requirement under the Service Access and Delivery Domain, the DoD 5015.2-STD's minimum metadata profile stipulates the metadata that needs to be associated with a record.

In addition to the metadata profile detailed in DoD 5015.2-STD, there is other work currently ongoing concerning metadata that is being conducted under Section 207 of the E-Government Act of 2002.

3.5 OVERVIEW OF THE PERFORMANCE REFERENCE MODEL

The Performance Reference Model (PRM) helps agencies measure the performance of major IT investments and their contribution to agency performance. The objectives of the model are to enhance performance information; improve the alignment and better articulate the contribution of inputs (such as technology) to outputs and outcomes; and identify improvement opportunities that span organizational boundaries.

The PRM, as shown in Exhibit 3.9, is comprised of four Measurement Areas:

Mission and business results - to capture the outcomes that agencies seek to achieve.
Customer results - to capture how well an agency or specific process within an agency is serving its customers.
Processes and activities - to capture the outputs that directly result from the processes that IT initiatives support.
Technology - to capture key performance elements directly associated with IT initiatives.

Exhibit 3.9. Performance Reference Model

Each Measurement Area includes Measurement Categories, which are decomposed into generic Measurement Indicators that agencies can tailor to reflect their own environments. Exhibit 3.9 provides an example of the agency's use of the PRM to identify measurement indicators for the development and implementation of a new IT system.

Exhibit 3.10. Sample Use of the PRM to Identify Measurement Indicators

Measurement Area	Measurement Category	Measurement Indicators	Indicators Tailored for Agency Use
Technology	Financial	Total costs Licensing costs Operations and maintenance costs Training Costs	In FY 2005, reduce total costs by 10 percent In FY 2006, reduce licensing costs by 5 percent In FY 2007, reduce operations and maintenance costs by 25 percent In FY 2007, reduce training costs by 15 percent.

Agencies initiating projects to improve their records management practices should consider using performance metrics to achieve anticipated improvements. If these improvements are not achieved, agencies should take corrective action. Agencies could develop metrics that measure improvements to agency business processes due to enhanced records management processes and procedures. One example of this type of metric would be to reduce the time required to respond to Freedom of Information Act requests by 50 percent. Within the PRM framework, this metric is aligned to the Customer Results Measurement Area Timeliness and Responsiveness Measurement Category Response Time Measurement Indicator.

3.5.1 Records Management Resources for the PRM

Records Management Resource for the PRM

Industry Advisory Council, "The Use of Metrics in Electronic Records Management Systems"

In July 2003, and at the request of OMB and NARA, the Industry Advisory Council (IAC) convened a Study Group to examine industry best practices in the area of metrics relating to ERM. Specifically, the Study Group was asked to determine appropriate metrics that are meaningful without being unduly burdensome. The Group identified 11 broad categories of metrics: access to services, accuracy, capacity, efficiency, participation, productivity, search and retrieval, system, user satisfaction, utilization, and legal. A copy of the White Paper, The Use of Metrics in Electronic Records Management Systems, and its findings is available at: http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf.

3.6 THE RECORDS LIFE CYCLE AND THE FEA REFERENCE MODELS

With this understanding of the FEA, agencies can view the life cycle of a Federal record - creation or receipt, maintenance and use, and disposition - within the context of the reference models. As shown in Exhibit 3.10 below, agencies create, receive, maintain, use, and disposition records in support of their business processes (applicable to the BRM). Business and service components (identified in the SRM), supported by appropriate standards (including data standards), specifications, and technologies (identified in the TRM and DRM), are used to accomplish these records management activities. Finally, agencies can measure their records management performance using the various measurement indicators identified in the PRM.

Exhibit 3.11. Illustration of the FEA Integrated with Records Management

In short, agencies can improve their records management practices by using the RM Profile that places records management resources within the context of the FEA. For example, agencies can refer to:

the BRM to identify the records management requirements to which they must comply, based on their Line of Business,
the SRM and TRM to identify the business and service components, and supporting technologies, that will enhance records management activities,
the DRM to identify the proper construct and metadata for records; and
the PRM to identify metrics suitable for monitoring the performance of records management initiatives.

Chapters 4 and 5 discuss in greater detail how to use the FEA reference models to identify, support, and improve records management requirements and activities.

Chapter 4: Using the RM Profile to Improve Records Management

In the current business environment, electronic records and systems are growing exponentially while Federal agencies struggle to implement processes to manage these records throughout their life cycle. Whereas in the past, agencies relied on traditional paper recordkeeping systems and reliable processes to preserve records as evidence of their activities, now agencies are creating more records electronically, including both documents and databases and are not reducing them to paper either for active use or for recordkeeping purposes. Additionally, traditional methods for managing paper records do not apply as readily to the management of electronic records and systems, and agencies have been slow to incorporate new procedures and tools into their business processes to ensure that valuable business records are managed effectively and not lost.

To face these challenges, Federal agencies must address the management of electronic records and systems proactively. To keep up with the volume of electronic records and systems created, agencies cannot relegate recordkeeping to a final step at the end of a particular process. Instead, records management must be tied to agency business processes and implemented at all stages of a record's life cycle. This is the challenge - to promote a paradigm where records management principles and procedures are integrated into agency mission processes and systems.

To achieve this goal, agencies need a sound framework and resources to find guidance and tools to manage their records and systems effectively. As a starting point, this RM Profile provides just that: a resource that identifies records management guidance and tools and describes how they support agency business (BRM), applications (SRM), technologies (TRM), data (DRM), and metrics (PRM).

In this chapter, the RM Profile introduces issues and guidance for agencies to consider when:

(re)designing business processes and/or consolidating to a Line of Business,
planning new systems of records, or
enhancing existing systems that are tied to the Federal acquisition process as defined by the OMB Circular No. A-11 (and specifically in the supporting Exhibit 300).

Regardless of the activity or type of acquisition, agencies should refer to OMB Circular No. A-130 when making IT decisions to ensure that alternative private sector or governmental sources are considered and the proposed solution is appropriate for the business process. Also discussed in this chapter is the incorporation of RM within the Systems Development Life Cycle (SDLC), along with specific questions that a Project Manager should consider when developing or enhancing an IT system.

The chapter concludes with some sample records management questions and responses that are tied to each FEA reference model. These questions and responses illustrate how agencies should incorporate records management into the planning, development, and implementation of agency business systems and processes.

4.0 DEVELOPING INVESTMENT STRATEGIES

For Federal agencies, the logical place to begin using the RM Profile is when agencies re-engineer business processes or consolidate processes into a Line of Business. Additionally, the RM Profile is useful to agencies within the context of the acquisition process defined by OMB Circular No. A-11. OMB requires that acquisitions support Federal Lines of Business and map to existing FEA reference models. As part of this process, agencies should evaluate where records management requirements exist within the context of each reference model and as relevant to the planned acquisition. Within all Line of Business processes, activities, and IT system transactions, agencies create, access, use, share, and disposition records (e.g., disposed of or transferred to NARA). As such, agencies should address the integration of records management when developing business and IT investment strategies by asking the appropriate questions, such as:

What constitutes a record within the planned business process or IT system?
Are records being shared?
Will records be needed beyond the life of the planned IT system?
Does a particular record have special security and privacy considerations?
Are any of the records permanent and scheduled for transfer to NARA?

The RM Profile can guide this process by helping agencies ask the right questions, ensuring that records management is considered in the planning stages of new acquisitions and accounted for at all points in the business processes these acquisitions support. Further, by using the RM Profile to answer specific records management-related questions, agencies can strengthen their business cases to OMB by showing how records management supports more efficient and effective business processes and sound investments.

Regarding implementation approaches using the RM Profile, there are currently two distinct tracks that agencies might choose and a third option that represents a hybrid approach combining elements of the first two:

An agency can opt for a DoD 5015.2-STD certified RMA that provides records management functionality for capturing, managing, accessing, storing, and dispositioning records.
Another option is to explore a component-based architecture (CBA) that uses records management service components (RMSCs) to accomplish similar functionality.
A third option is to develop RMSCs as part of mission applications and link them to RMAs already being used by the agency.

RMAs and CBAs are described below along with their relative benefits and challenges. Chapter 5 illustrates how agencies might use RMAs and CBAs in three hypothetical scenarios.

4.1 RECORDS MANAGEMENT AND THE SDLC

The SDLC process applies to information system development projects ensuring that user requirements and agency strategic goals and objectives are met. It provides a structured and standardized process for all phases of any system development effort. These phases track the development of a system from initiation through concept development and planning; requirements definition; design; development; integration and testing; implementation; operations and maintenance; and retirement. The most effective way to manage electronic records is to build records management requirements into systems during the concept, design and development phases. The RM Profile recommends that agencies embed these requirements in the early stages of the SDLC, and in doing so, they will realize cost efficiencies and other positive benefits.

Exhibit 4.0 presents a high-level overview of integrating RM into the SDLC. It depicts certain points in the SDLC process where agencies can establish records management review and approval to ensure that sound RM practices are incorporated into the development of any proposed IT system. Sections 4.1.1 through 4.1.6 present records management-related questions that project managers and teams should consider at each appropriate phase of the SDLC.

Exhibit 4.0. Records Management Integration into the SDLC

4.1.1 Concept Development

The main RM objectives in this phase are to get the Records Officer involved in the system design, to ensure the system owner is aware of the need to integrate RM into the system and to begin discussing records schedules.

(1) Is this system replacing a paper-based records system? If yes, are the paper records already scheduled? If yes, can the existing dispositions be used as the basis for new dispositions for this system?

(2) Is this new system replacing an existing electronic system? If yes, is this existing system already scheduled? If yes, can the existing dispositions be used as the basis for new dispositions for this system? Have you addressed the migration of the legacy data?

(3) If the business process/workflow in question has or will be re-designed prior to system development, will these new business process methodologies account for a change in the nature of existing records?

4.1.2 Requirements Definition

The RM objective in this phase is to ensure that all records-related requirements have been identified and formally documented in the system requirements document. To implement these requirements effectively, agencies should ensure that they are validated and measurable.

(1) Have you incorporated all records-related requirements into the system?

(2) Have you identified additional records requirements based on your business needs?

(3) Have you considered how the proposed records dispositions and retention times might impact the system's records-related requirements? For records of long-term value, is there a well-documented migration strategy to ensure the integrity and continued access to these records?

(4) Have you incorporated all of the records-related requirements detailed in your system requirements document into the records requirements section of your draft IT Investment Proposal?

(5) Have you validated the requirements and developed clear measures for each?

4.1.3 Preliminary and Detailed Design

The RM objectives in this phase are to ensure that the requirements identified in the previous phase are addressed in the preliminary and detailed system design and to initiate the draft records schedule.

(1) Have you integrated all of the identified records management requirements into the system design?

(2) Have you finalized the draft records schedule for the system and circulated it for internal clearances?

(3) Have you involved the Records Officer in the records schedule creation process? If not, he/she should review your draft schedule before continuing with development to ensure that all of the identified records-related requirements are covered by the schedule.

(4) Have you identified and included existing RM service components in the system design, as appropriate to meet the requirements?

4.1.4 Integration and System Test

In this phase, the RM objectives are to validate that the system meets the specific RM requirements identified in the requirements definition stage and that the system is scheduled.

(1) Has the Records Officer submitted the records schedule to NARA?

(2) Does the system meet all of the identified records-related requirements outlined in the requirements document? If not, did you consult with the Records Officer to determine the appropriate course of action?

(3) Has the Configuration Control Board (CCB) process taken records management issues into account for all changes?

4.1.5 Production and Operation

The RM objectives in this phase are to validate the records schedule or modify it to reflect the findings of the assessment, and to re-certify that RM requirements are being met throughout the system's Operations and Maintenance (O&M) phase.

(1) Are records management requirements being followed?

(2) Has the system been modified or is it being used to support different business needs than originally intended? If so, you may require a new product plan and/or schedule.

(3) Is the system content consistent with what was intended (e.g., is the system maintaining more or less data than intended? Different data?)? If not, you may need to modify the records schedule. Contact the Records Officer for assistance.

(4) Do the records produced by the system have the same value that was originally assigned to them? If not, you may need to modify the records schedule, including retention times.

(5) Has a work process provided or supported by the system been changed? Does this change have any records-related implications (e.g., changes to the records schedule, revised records management system requirements)? If so, contact the Records Officer for assistance.

4.1.6 System Retirement and Rollover

The RM objectives in this phase are to ensure continued accountability for the records contained in the system being shut down, and that records are retained and kept accessible for the full retention period.

(1) Is the system being totally shut down or will you migrate some of the data to a successor system?

(2) If you plan to migrate some of the data, will you preserve the functionality of the migrated data as well as complete access to the data not migrated?

(3) If the system will be totally shut down, will you maintain the accessibility of the data for the full retention period?

(4) Is the current disposition(s) for the system still appropriate? Have business needs sufficiently changed to warrant a re-examination of both the value of the records and the retention period?

4.2 RECORDS MANAGEMENT APPLICATIONS (DoD 5015.2-STD)

Agencies may use DoD 5015.2-STD certified RMAs to maintain and protect records in accordance with agency-specific and Federal records management regulations. RMAs incorporate requirements for managing the complete life cycle of a record after users declare a document to be a record. RMAs can be implemented enterprise-wide or at the office or unit level. Because not all RMAs comply with the DoD standard, NARA recommends that agencies review the complete listing of DoD 5015.2-STD certified RMAs at: http://jitc.fhu.disa.mil/recmgt/.

The primary advantage to using an RMA is that the supporting DoD standard includes NARA-endorsed requirements that ensure that RMAs provide records management functionality

RMA Advantages

Endorsed by NARA
Tested and certified by DOD
Few other options

throughout the life cycle of all declared records in the RMA. In the current business environment, there are few, if any, other automated options that agencies can consider to manage their records. On the other hand, there are challenges to implementing RMAs:

First, RMAs require integration into agency business processes to ensure they work within existing agency architectures, software platforms, and user needs.
Second, RMAs are not "plug and play" and often require considerable resources (i.e., time, money, and personnel) to ensure they are implemented effectively.
Third, the RMA standard includes only a minimum set of requirements for providing records management functionality that each agency needs to evaluate. In most cases, agencies will decide to augment these requirements with agency-specific requirements, which can be a long and involved process.

If an agency determines that an RMA is the best available option to meet their records management needs, the agency should ensure that:

an RMA is not currently in use in any agency program or office,
only a DoD 5015.2-STD certified RMA is implemented and used (unless there is appropriate justification for using a non-compliant product), and
all systems conforming to the 5015.2-STD are mapped in their agency enterprise architecture so as to reveal any non-conforming systems that may be at risk for not managing records effectively.

4.3 COMPONENT-BASED ARCHITECTURE AND RECORDS MANAGEMENT SERVICE COMPONENTS

If records management is to be integral to all processes and IT systems, then agencies must embed parts or "components" of the full life cycle functionality of the RMA into a process or a system. Agency staff can create a record within a business application in the same manner that it would be created within an RMA, complete with associated metadata (e.g., author, classification, disposition authority), and handled accordingly. As agencies develop an IT system to perform a Line of Business function or process, it can include the capability to recognize a record as it is created, prompt for the appropriate metadata, and even automatically transfer the record to an RMA repository. In this example, the feature of the IT system that handles records management could be called a "create record" or "capture record" component, where that component(s) integrates with the other components of the system performing a Line of Business process.

In simplest terms, components are building blocks that connect together in many different configurations or scenarios to serve a particular purpose. With respect to software and applications, a component is a "self-contained business process or service with pre-determined functionality that may be exposed through a business or technology interface." ¹³ It is a discrete unit of business functionality that can provide a business service in and of itself or be combined with other components to provide a business service. From that definition, an RMA can be considered a component that provides a records management service. Also, the RMA can be a component comprised of many components, with each smaller component supplying a service related to different aspects of the record life cycle, such as capturing (creating), retrieving, or disposing of a record. Further, the software component that captures a record can be connected to other software components to generate a Line of Business service, such as the Treasury Department's PAY.gov website.

The advantage to using components is that they are "plug and play" and re-usable in many different business processes within and across Federal agencies. Components promote adaptive and resilient agency enterprise architectures and the consistent application of business rules. Staff can share records, and information in general, more easily throughout the enterprise and across agencies. Exhibit 4.1 illustrates the utility of building an application using a CBA, in that agencies can implement components, and therefore services, in many different applications as stand-alone units of functionality, independent of business rules and data.

Exhibit 4.1. Illustration of the Utility of Component-Based Architectures

Yet, there are significant challenges to this approach as well. In the current business environment, CBAs are still developing and in many agencies the necessary processes, skills, and culture to support effective CBAs are immature.

CBA Advantages

"Plug and play"
Re-usability
More easily integrated into agency enterprise architectures

As discussed in Chapter 3 of this RM Profile, RMSCs fall under the SRM, but they are still only a list of requirements at this point. In future versions of the RM Profile, these requirements may provide the foundation for RMSCs that agencies can build into their business processes and applications.

Equally important to identifying RMSCs is identifying the technology components necessary to find and use these service components that may already exist within the Federal Government, and conversely, developing and exposing components to other agencies. Services are made available by publishing the service description to service registries (such as CORE.gov) and found by service consumers via querying the registry, as shown below in Exhibit 4.2. The reusable software components, or services, communicate with each other. The communication can involve either simple data passing or, two or more services coordinating some activity, such as completing a Line of Business activity while concurrently capturing a record in an RMA repository.

Exhibit 4.2. Records Management Component Discovery

The illustration above is a simple diagram of how services can be exposed, discovered, and accessed. There is much more involved in the process of defining components and services, incorporating the technologies within an agency to develop and/or take advantage of services, and building Service-Oriented Architectures (SOAs), all of which are beyond the scope of this document.

The definition, exposure, and use of business and technical services is still in its infancy within the Federal Government; however, a service orientation appears to be the direction of the future. Over time, the objective is to maximize enterprise-wide services and components while providing unique services and components only for specialized requirements. It constitutes a new way of thinking, and provides an opportunity for agencies to share data and services, such as records management services and components, where it makes sense to do so, as opposed to developing in-house solutions with limited efficiency and re-usability. In developing their IT investment strategies, agencies should consider the advantages of re-use or accessing existing services and components.

4.4 COMPONENT-BASED ARCHITECTURE AND DoD 5015.2-STD

When developing investment strategies, agencies need to be aware of the advantages and challenges to implementing either of the above approaches to building records management functionality into agency business processes. Regardless of the option selected, the RM Profile can advise the planning, acquisition, and implementation of components or RMAs. While this document treats RMAs and CBAs as distinct approaches, especially in the scenarios that follow, they are in fact complementary. The DoD standard applies to the development of applications that support the entire life cycle of records, but it is also applicable to developing components of a records management service. The RMSCs that set forth standard business functionality of records management (independent of applications that provide the service), and the functionality/capability provided by an RMA are contained within the SRM. The DoD 5015.2-STD that stipulates technical requirements for an RMA (and can be extended to RM component software) is also contained within the TRM.

4.5 RECORDS MANAGEMENT, THE FEA, AND FEDERAL INVESTMENT STRATEGIES

The following questions provide specific examples of how agencies can use the RM Profile as a guide for integrating records management into their acquisition and implementation strategies. Derived from the resources identified in Chapter 3 (and listed in Appendix A), the questions highlight many of the key issues relevant to each FEA reference model. Agencies should address these questions before proposing solutions for funding through the Investment Management process. Where appropriate, the questions refer agencies to the relevant records management resources where answers or additional guidance can be found.

Parallel to the discussion in Chapter 3, the questions show how to approach an IT investment in relation to the FEA reference models. A common approach when planning an IT investment is to consider:

First, what business is supported within the BRM (e.g., the records management Sub-function within the Information and Technology Management Line of Business, or the Border and Transportation Security Sub-function within the Homeland Security Line of Business)?
Second, what capabilities or services (SRM) are being sought to support the business that the IT investment will provide (e.g., RMSCs)?
Third, what technologies (TRM) will be used to develop or access the capabilities or services (e.g., DoD 5015.2-STD, .NET, or WSDL)?
Fourth, what data (DRM) will be created, used, or shared?
Finally, what performance metrics or results (PRM) are to be achieved (e.g., how will agencies measure agency and individual employee performance with respect to the creation, management, and sharing of records?)?

Exhibit 4.3 shows the order in which agencies should consider the following sample questions.

Exhibit 4.3. FEA Reference Model Order when Considering an IT Investment

It is important to note that the questions provided are not comprehensive; rather, they are a starting point for this version of the RM Profile and will continue to evolve in future iterations of this document as more resources are identified and agencies gain experience using the RM Profile.

4.6 SAMPLE FEA RELATED QUESTIONS

4.6.1 BRM Questions

What Line of Business is identified in the Exhibit 300 for this system acquisition?
Is one of the existing records management Lines of Business identified as the primary or ancillary Line of Business for the system?
1. If records management is a primary Line of Business in the Exhibit 300, has your agency signed an "agency commitment Memorandum of Understanding (MOU)" with E-Records Management (ERM) E-Gov?
2. If yes, has your capital planning investment control board considered ERM E-Gov's Guidance for Coordinating the Evaluation of Capital Planning and Investment Control (CPIC) Proposals for ERM Applications?
Have you identified within the primary Line of Business of the system which specific activities will generate Federal records? Which will access Federal records? Which will transfer or share Federal records?
Have the processes supporting the primary Line of Business been re-designed?
1. If yes, have you considered the characteristics of recordkeeping trustworthiness discussed in ISO 15489-1 in that re-design?
2. What effect does the Line of Business re-design have on recordkeeping, management, and use by other processes and services?

4.6.2 SRM Questions

What records management services or capabilities are required to support the business identified above?
Are you considering an RMA or a component-based approach for automating record management functionality?
1. If component-based, have you consulted the RMSC requirements in the CORE.gov registry at OMB's FEA Program Management Office?
2. If component-based, do the RMSCs that meet your records management requirements already exist within your Agency or elsewhere within the Federal Government?
For either RMA or RMSC implementation, have you identified the applicable SRM components?

4.6.3 TRM Questions

Are you using an RMA to accomplish the required records management functionalities?
1. If yes, does the RMA comply with the DoD 5015.2-STD?
2. If yes, has your agency consulted ERM E-Gov's ERM Guidance on Methodology for Determining Agency-unique Requirements to determine additional requirements beyond the DoD 5015.2-STD minimum requirements?
Are you using RMSCs to accomplish the required records management functionalities?
1. If yes, how are you acquiring the service components?
  1. Are you acquiring the components in accordance with NARA's draft RMSC requirements?
  2. If developing the component, what technologies from the TRM are you using (e.g., NET)?
  3. If accessing another Agency's component, what TRM technologies do you need to access the component (e.g., web service, WSDL, XML)?
    1. Have you executed a Service Level Agreement with the other Agency?
    2. Do the components comply with DoD 5015.2-STD?
2. What relationship exists between records management services and technologies? Agencies should evaluate existing technologies in the marketplace and determine which solutions can support desired records management services.
Do the technology components that meet your records management requirements already exist within your agency or elsewhere in the Federal Government?
Does the system employ electronic signatures?
1. If yes, have you correlated your risk assessment with recordkeeping requirements per NARA's (1) Records Management Guidance for Agencies Implementing Electronic Signature Technologies, (2) Records Management Guidance for PKI-Unique Administrative Records, and (3) Records Management Guidance For PKI Digital Signature Authenticated and Secured Transaction Records?
Has the records scheduling activity determined that there are permanent records in the system?
1. If yes, have the system designers/integrators consulted ERM E-Gov's applicable, format-specific transfer requirements (available on the NARA website) and incorporated those into system design and analysis?
Is there a web interface to this system?
1. Have you reviewed NARA's Guidance on Managing Web Records?
What FEA TRM services, categories, standards, and specifications are applicable to this acquisition?

4.6.4 DRM Questions

For those records in the system, have you determined what metadata to associate with the records?
Does the metadata meet the requirements expressed in Table C2.T3 and C2.T4 of the current DoD 5015.2-STD?

4.6.5 PRM Questions

How are the metrics defined in the OMB Exhibit 300 for this system acquisition?
Are the metrics process-improvement related or are the metrics records management-specific?
1. If the metrics are records management-specific, have you reviewed the ERM E-Gov IAC White Paper on RMA metrics?
Do the records produced by this system or the system itself (as a record) already possess an existing NARA-approved disposition authority?
1. If yes, have you revisited the applicable records schedule to account for changes in the process or format of the records?
2. If no, has your Records Officer initiated a records scheduling activity?

As shown through these examples, the RM Profile framework is a best practice reference for agencies to integrate records management principles, procedures, and requirements into agency business and information technology processes. When used as guidance for enterprise-wide acquisition planning, the RM Profile:

promotes consistency in applying records management throughout the agency,
reduces the need for stove-pipe systems and processes to perform records management,
encourages the re-use of systems and processes supporting records management,
assures that records management requirements are met throughout the life cycle of all records, and
minimizes implementation challenges usually faced when ad hoc or stand-alone systems are created to support records management.

The following chapter illustrates how agencies might apply these questions in a step-by-step scenario of a real Government business process. Whether the goal is to procure an RMA or to develop a CBA, the scenario shows how the RM Profile framework and resources can advise agency planning processes to ensure that records (and systems of records) are effectively managed from records creation or receipt through their ultimate disposition.

Chapter 5: Application of the RM Profile

The following three scenarios demonstrate hypothetical applications of some of the FEA reference model/records management-related questions discussed in Chapter 4. The first scenario is an RMA implementation. The second scenario relates to an agency enhancement of an existing mission application by adding an RM component to it. The third scenario involves developing an RM component as part of a mission system where the organization already maintains an RMA. Included solely for illustration, these scenarios are not intended to be comprehensive in how agencies might implement the RM Profile.

As mentioned in the previous chapter, and illustrated below in Exhibit 5.0, there is a common thought process and navigation through the FEA reference models when approaching a records management acquisition, regardless of whether it is for an RMA or a records management component.

Exhibit 5.0. Illustrative Navigation through the FEA Reference Models

5.0 IMPLEMENTING A RECORDS MANAGEMENT APPLICATION

RMAs provide organizations with the capabilities to manage their records as required by law throughout their life cycle, that is, from their creation to their maintenance and use, and then to their ultimate disposition (i.e., disposal or permanent preservation). This includes "locking down" documents so that they are unalterable and managing version control of specific documents. RMAs also include the functionality to store and destroy records at the appropriate time. RMAs often reduce the cost otherwise associated with operating multiple, disparate records management systems, including costs associated with administration, maintenance, and training.

Organizations may wish to consider the acquisition of an RMA if they are seeking to:

manage records from desktop applications, where the electronic version of the record will be the recordkeeping copy;
maintain electronic mail in an electronic format for recordkeeping purposes;
facilitate the transfer of permanent electronic mail records to the National Archives; and
collect, organize, and categorize records in a manner that facilitates their retrieval, use, disposition, and preservation.

5.0.1 Overview of the Scenario

The CIO of Agency A, working with the Records Officer, is acquiring an RMA to manage Agency records. They want all records within the Agency stored, tracked, maintained, secured, and accessible to appropriate customers as well as internal staff, and stored or disposed of in accordance with disposition instructions on approved agency records schedules. After reviewing NARA's guidance for Coordinating the Evaluation of CPIC Proposals for ERM Applications, ¹⁴ the CIO decides to acquire an enterprise-wide RMA and maintain all records in one central repository.

Prior to initiating the acquisition and generating a business case, the CIO searches the Agency's Enterprise Architecture and queries sub-agency program offices to determine whether any units within the organization are already using RMAs. They find that several program offices have their own database repositories for maintaining records, but none are using RMAs or document management applications, which from many vendors contain additional functionality to perform records management.

5.0.2 Application of the RM Profile to the Scenario

5.0.2.1 Addressing BRM-Related Questions

This particular acquisition is for the primary purpose of records management and therefore falls within the Record Retention Sub-function of the Information and Technology Management Line of Business within the Management of Government Resources Business Area. Since records management is the primary Line of Business, the CIO generates an 'Agency Commitment MOU' with the ERM E-Gov initiative ¹⁵ to ensure alignment and adherence to the policies, guidance, and best practices generated by that initiative. The CIO and Records Officer determine that this acquisition is for an enterprise-wide RMA, which will result in a central repository for all Agency records, and policies and procedures for sub-agency offices to use.

Staff will not create records within the RMA - rather, records will be captured by the RMA via processes established to transfer records to the RMA from other applications where they are created. Records may be born-digital or scanned from existing hard copy records. The RMA will then manage all life cycle functions of a record for secure storage, access, and disposition. As part of the acquisition, the Agency intends to re-design and streamline its records management processes to take advantage of the RMA's functionality. In performing this task, the Agency considers existing standards such as the ISO Records Management Standard 15489-1 with which the RMA should comply. Also as part of the acquisition, the CIO and Records Officer intend to survey the Agency for all existing records and records management best practices currently employed.

5.0.2.2 Addressing SRM-Related Questions

To support the Line of Business to which this acquisition aligns, the intended system must have the capability to support records management requirements for the entire life cycle of records: capturing a record, ensuring all required metadata is maintained with the record, securely storing a record, enabling secure access to a record by both customers and Agency staff, allowing for the sharing of records internally and externally, and disposing of a record in accordance with its approved disposition instructions (e.g., storage within the Agency and disposal, or transfer to NARA).

As an RMA, the system will provide the functionality of all service components currently identified within FEA SRM v1.0. They reside within the Records Management Service Type under the Digital Asset Services Domain and include:

Digital Rights Management - the set of capabilities that support the claim and ownership of intellectual property and artifacts of an organization.
Document Classification - the set of capabilities that support the categorization of documents and artifacts, both electronic and physical.
Document Retirement - the set of capabilities that support the termination or cancellation of documents and artifacts used by an organization and its stakeholders.
Record Linking / Association - the set of capabilities that support the correlation between logical data and information sets.

The RMA will also provide additional RM capabilities that are not captured yet within the FEA SRM, such as those listed in Chapter 3 and defined in NARA's Records Management Service Components (RMSC) Requirements Development Project Final Report. ( http://www.archives.gov/era/pdf/rmsc0305.pdf)

5.0.2.3 Addressing TRM-Related Questions

The CIO is aware that there are many RMAs available as commercial off-the-shelf (COTS) products on the market, and that it is advantageous to procure the COTS product as opposed to building an RMA in-house, as the alternatives and cost-benefit analyses sections of the OMB Exhibit 300 will show. The alternatives analysis section also reflects the consideration of the various COTS products, and supports the selection of a DoD 5015.2-STD ¹⁶ certified product that satisfies critical records management requirements. The CIO mentions that while the TRM does not currently incorporate the DoD 5015.2-STD as an RM Service Requirement (under the Service Access and Delivery Service Area), the Agency does intend to employ a DoD 5015.2-STD certified RMA.

Additionally, the CIO will consult the ERM E-Gov's ERM Guidance on Methodology for Determining Agency-unique Requirements to ascertain additional requirements for their RMA that extend beyond those required by DoD 5015.2-STD.

The RMA will maintain electronically signed records. As part of this acquisition, the CIO's staff will refer to NARA's Records Management Guidance for Agencies Implementing Electronic Signature Technologies to ensure the RMA meets the requirements for preserving a record's trustworthiness over time. The RMA will also house permanent records that will require transfer to NARA in accordance with the disposition instructions on the approved agency records schedule. Agency A should tailor the RMA as necessary to ensure the transfer of permanent records in a format specified by the ERM E-Gov Transfer Instructions for Permanent Electronic Records.

Since the RMA will not be developed in-house, it is not necessary to identify all the standards and specifications associated with building the RMA, typically found within the Component Framework Service Area. Other TRM Service Areas, Service Categories, Standards, and Specifications that are applicable to this RMA acquisition include:

Service Access and Delivery.
To support internal and external access to the RMA, by customers and Agency staff, the CIO specifies Web Browser specifications (e.g., Internet Explorer and/or Netscape) for accessing the RMA, and Internet and Intranet standards for delivering or sharing the RMA records. Since the Agency will make appropriate records accessible to the public, they do not intend to establish the requirement for a virtual private network. RMA records will be accessed and/or delivered via HTTP or HTTPS, depending on the security associated with the record.
Service Platform and Infrastructure.
The RMA will reside on an Application Server (within the Delivery Servers Service Category) dedicated to the RMA. The Agency will designate the RMA application server as an Enterprise Server (within the Hardware/Infrastructure Service Category), and will integrate it with an Oracle Database for its central repository of agency records. The Office of the CIO will maintain the RMA and employ Change Management (within the Software Configuration Management Service Category) to ensure configuration control.
Service Interface and Integration.
The CIO and Records Officer want to be able to share records with other agencies and be able to transfer records to NARA when appropriate, so the Agency will specify XML as an Interoperability Standard to facilitate sharing of records. Since an RMA is a complete application and not separable as multiple components, and because it is a vendor product, there is no need for the Agency to consider publishing the RMA or its parts as a service within a service registry or directory, and hence, there is no need for a Service Interface.

5.0.2.4 Addressing DRM-Related Questions

Because it is DoD 5015.2-STD certified, the RMA will meet the minimum requirements for record metadata. Additionally, this acquisition will incorporate additional agency-unique metadata requirements as determined by the Agency.

5.0.2.5 Addressing PRM-Related Questions

The Records Officer initiated this acquisition to ensure:

Proper records management for all Agency records,
Efficient and timely access to records by Agency staff, customers, and
Maintenance of the integrity and authenticity of Agency records.

To develop performance measures and metrics for this RMA acquisition and subsequent implementation, the Records Officer reviews the IAC's White Paper on RMA metrics ( http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf) in order to articulate common RMA performance measures. Performance measures are as follows:

Mission and Business Results.
Outcomes the Agency is seeking to achieve with the RMA:
1. The number of FOIA requests processed per day increases by xx%.
Customer Results.
How well the Agency is serving its customers (internal and external) by employing the RMA: 1. Record search and retrieval capability results in record matches being returned within xx amount of time.
2. Customer satisfaction in retrieving Agency records improves by xx%.
Processes and Activities.
Outputs directly resulting from the RMA supporting records management:
1. Accuracy of record classification (filing) improves by xx%.
Technology.
Key performance elements directly associated with the RMA:
1. Record holding capacity of the RMA is xx number of records.
2. The response time for an RMA query or search is less than xx amount of time.
3. Access to records for both Agency staff and the public is available 7x24.

The agency already has NARA-approved disposition authorities for the records managed by the RMA. The Agency is revisiting the records schedule as the RM processes are re-engineered with the implementation of the RMA.

5.0.3 RMA Acquisition Approach

Due to the cost and complexity of the effort, it takes a significant amount of time to procure and implement an enterprise-wide RMA. Organizations seeking to acquire an RMA should consider the following approach, which suggests a proposed process upon which to base the acquisition decision.

Establish and officially charter a project team with the requisite skills, including project, risk, security, requirements, communications, and change management. The project team should assign a project manager with the appropriate responsibilities and authority. The project manager should lead the effort with the development of the key planning documents.
Establish a baseline by surveying existing programs/offices within the organization to determine those that have established records management policies and procedures. At the same time, request that each program/office analyze its business processes to identify the records created, received, maintained/used, and dispositioned throughout the organization.
Identify assumptions, constraints, and risks, considering those that relate to funding, project schedules, and technical issues.
Identify records management requirements, including those relating to technical, security, end-user, legal, policy, budgetary, and other issues. Organizations can look to the series of questions relating to the FEA reference models to help them determine records management requirements (see Chapter 4 of this Profile).
Develop records schedules that adequately document agency business processes and describe the records with appropriate disposition instructions to support agency business needs. The records schedules should be written at a level of granularity appropriate for use with an RMA.
Identify and prioritize criteria to evaluate RMAs based on the constraints and requirements identified previously.
Identify and select alternative RMAs for evaluation that comply with the baseline set of requirements set forth in DoD 5015-2-STD.
Evaluate products and rank them in accordance with evaluation criteria. The evaluation should include an estimate of the organization-wide costs and benefits of each product. Also, if available, the evaluation should also include references from current users of the products within the agency or in other agencies.
Select an RMA that best satisfies the evaluation criteria.
Develop the business case to support the RMA investment and funding request. At this point in investment planning, the organization should be able to:
- justify an enterprise-wide investment in an RMA
- articulate the project management structure put in place to manage the effort
- describe the alternative RMAs considered and the results of this analysis (OMB requires analysis of three alternatives as part of the OMB Exhibit 300 requirements)
- identify the risks to the organization associated with the investment
- provide major milestones and total costs to deploy an RMA
- map the RMA to the organization's enterprise architecture
- discuss security and privacy considerations associated with the investment.
Submit the business case (Exhibit 300) to OMB for funding, after ensuring the organization is not seeking funding for both enterprise-wide and program-specific RMAs. ¹⁷
Plan and conduct a pilot project within the organization to test the RMA. Pilot planning should include the identification of performance goals and metrics, to help evaluate the success of the pilot. Determine a "Go/No Go" decision, based on the results of the pilot.
Develop and implement a phased implementation plan for the RMA that focuses on the extensive change management effort that will be required.

5.1 INCORPORATING A RECORDS MANAGEMENT COMPONENT INTO A MISSION APPLICATION

This scenario, designed as a counterpoint to the preceding scenario, focuses on the use of RMSCs in automating records management functions, as opposed to the use of a 5015.2-STD-certified RMA. It is speculative in that NARA is just now defining the requirements for RMSCs (as presented in Chapter 3), so there are no NARA-endorsed RMSCs in existence yet for agencies to adopt. However, some RMA vendors, in alignment with the direction that the Federal Government is headed, are starting to define their applications in terms of components.

5.1.0 Overview of the Scenario

Agency B operates an information system that automates a permit adjudication process. This system, which is in the operations and maintenance phase of deployment, employs integrated scanning and workflow software. The Agency is in the process of transitioning to a component-based deployment of applications in its enterprise architecture. The funding proposal for records management enhancement of the permit adjudication system will represent an initial foray into component-based application development.

5.1.1 Application of the RM Profile to the Scenario

5.1.1.1 Addressing BRM-Related Questions

Agency B submits an Exhibit 300 to OMB to enhance the permit adjudication system. The primary Business Area, Line of Business, and Sub-function to which this acquisition applies are the Services for Citizens Business Area, the Homeland Security Line of Business, and the Border and Transportation Security Sub-function.

Since the enhancement of the permit adjudication system incorporates records management functionality, the ancillary Line of Business and Sub-function for this acquisition are the Information and Technology Management Line of Business and the Records Retention Sub-function under the Management of Government Resources Business Area.

After consulting ISO 15489-1, the Records Officer recommends modifications to the workflow to capture recordkeeping copies at various stages in the process (as opposed to a single, final step) to enhance the trustworthiness of the process. This recommendation will also necessitate modification of the records schedule associated with the system.

5.1.1.2 Addressing SRM-Related Questions

The Agency's enterprise architect reviews the records management capabilities of the Digital Asset Services Domain in the CORE.gov registry maintained by the FEA PMO and discovers requirements for RM service components at: http://www.archives.gov/era/pdf/rmsc0305.pdf as defined by the ERM E-Gov Initiative. While no actual code resides in the registry available for re-use, the Architect and Project Manager discuss with the Agency Records Officer to see which components would be most advantageous to develop and implement in the permit adjudication system. The first decision point is to determine which of the six potential RM service components to develop and deploy. The project team, in consultation with the Agency Records Officer, considers each component for potential inclusion. The thought process surrounding that activity is described below for each component.

Capture Record component: The purpose of this component is to capture information with associated attributes in an electronic system.

This component is selected for development and deployment as a means of implementing the business decision to capture recordkeeping copies at various stages in the workflow of the permit adjudication process.
Assign Disposition component: This component uses an established disposition authority to assign the disposition schedule, item number, and disposition instructions to the record.

This component is not selected for development and deployment due to the manner in which the records resulting from this system have been scheduled. Since the purpose of the system has been narrowly defined (i.e., permit application adjudication), all of the output of the system falls into a single series that has a uniform retention period (which can be encoded as metadata at the time of activation of the CAPTURE RECORD component).
Categorize Record component: This component utilizes agency business rules to assign an appropriate descriptive label to the records in order to facilitate management in an electronic system.

This component is not selected for development and deployment because the current system already performs the categorization function.
Ensure Authenticity component: This component ensures the acceptability of a record as genuine, based on its characteristics such as structure, content, and context.

This component is not selected for development and deployment because the current system already ensures the authenticity of the electronic information.
Associate Record component: This component provides the capability to associate a record to one or more other records through a Record Association attribute.

This component is selected to support the development of an 'official case file' associated with the adjudication of any individual permit application. ¹⁸
Execute Disposition component: This component implements the destruction, transfer, or continued retention of a record in accordance with the established disposition authority. After validation that the disposition action is valid, the component executes the disposition action and records the transaction.

This component is selected for development to provide consistent compliance with retention requirements as expressed in the approved records schedule.

Once the Agency selects the relevant components as appropriate to the system, the Agency Architect must determine how to deploy them, both in the context of the permit adjudication system upgrade under consideration, as well as in the larger context of the enterprise architecture. As such, considerations might include:

Does the deployment of these components have any potential wider applicability than the system at hand?
- If so, how can their development and deployment be leveraged/maximized?
- If leveraging their deployment is deemed prudent, what constraints do existing legacy applications place on their development?
Is it advisable to ensure a parallel recordkeeping capability (e.g., via a 5015.2-STD certified RMA) during the initial stages of a CBA EA deployment?

For submission of the OMB Exhibit 300, Agency B identifies SRM service components supplied by the permit adjudication system. Those service components applicable to records management that are incorporated in the system are all contained within the Digital Asset Services Domain under the Records Management Service Type, namely the Document Classification and the Record Linking / Association Service Components. Future revisions of the SRM will likely include the RMSCs identified in Section 5.1.1.2.

5.1.1.3 Addressing TRM-Related Questions

Agency B's search for existing RMSCs led to the realization that they would have to build the components in-house (and later register in CORE.gov so that other agencies will be able to take advantage of them). Given the existing Permit Adjudication System application framework, and consultation with system development contractors, the Agency decides on a .NET solution for building the RMSCs.

To document the permit adjudication process, Agency B captures copies of long-term temporary records at various stages of the process. The Agency identified these recordkeeping copies after reviewing the existing records schedules and the proposed business process modifications developed as a result of the BRM-related analysis. Several points in the workflow process where recordkeeping copies are 'set aside' occur coincident with scanning actions. While permit adjudication records have been appraised as temporary, their retention for agency business is lengthy. As such, the Records Officer directs the project team to examine creation requirements in Expanding Acceptable Transfer Requirements: Transfer Instructions for Existing Permanent Electronic Records: Scanned Images of Textual Records, so that the system will produce long-term temporary records that support agency business for as long as needed.

As listed below, the Agency identifies TRM Service Areas, Service Categories, Standards, and Specifications for the RMSCs being developed.

Service Access and Delivery. DoD 5015.2-STD, though not listed as a specification yet within the TRM, will fall under the Service Requirements Service Type and the Legislative/Compliance Standard.
Component Framework. The business logic of the RMSCs will be developed according to the Visual Basic.NET Specification within the Platform Dependent Standard and Business Logic Service Type.

5.1.1.4 Addressing DRM-Related Questions

The Agency develops the RMSCs to meet DoD 5015.2-STD criteria, thus ensuring that minimum record metadata requirements are met. The Agency also identifies and adds additional agency-unique metadata.

5.1.1.5 Addressing PRM-Related Questions

As part of the acquisition strategy, the Agency develops performance metrics for the system. As the system is not classified primarily as a recordkeeping system, and in light of the recommendations made in the Industry Advisory Council E-Government Shared Interest Group White Paper on The Use of Metrics in Electronic Records Management (ERM) Systems ( http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf), the Agency chooses to cast system performance metrics in terms of distinct process-related improvements (e.g., reduction in time for permit application processing).

The agency already has NARA-approved disposition authorities for the output records generated by the application adjudication system. The Records Officer evaluates all steps in the workflow to determine at which points in the workflow it is necessary to capture recordkeeping copies to provide accountability and document work processes. This records management performance-related analysis will inform subsequent business and service component reference model-related questions.

5.2 DEVELOPING A MISSION APPLICATION WITH A RECORDS MANAGEMENT COMPONENT AND LINKING TO AN RMA

This scenario focuses on the use of RMSCs to incorporate records management functionality into an existing mission application in an effort to better integrate records management into mission processes. It also assumes that an agency-wide RMA already exists with a central repository for all agency records. The scenario is purely hypothetical and is applicable to any agency that would use a mission system as described below or might apply this example to their real-world environment.

5.2.0 Overview of the Scenario

Agency C wants to develop an information system to automate an identification (ID) card application process (e.g., an Agency ID, a driver's license, or a library card). The following is a synopsis of the process and workflow:

Application Acceptance Facility receives the application. First-time applicants must appear in person to request an ID. Applicants may apply for ID renewals through the Agency's website. Application packages include a signed application form, proof of identity (e.g., driver's license), and required fees.
Agency processes applications and fees. Once received by the Acceptance Facility, staff process the fees and affix a bar code to the application, which is used as the primary identifier at every subsequent step in the process. Staff extract data from the application and enter the data into the Agency ID system for processing, tracking, and reporting.
Agency reviews applications for eligibility. Staff perform manual and automated checks (e.g., name checks) on the application data to validate and verify the information. The Agency adjudicates the application and decides to grant or deny it with notations captured on the application form and entered into the Agency ID system.
Agency issues (or denies) valid ID. The Agency mails the ID to the applicant if adjudication does not reveal any issues. If issues arise, the Agency informs the applicant that supplemental or clarifying information is needed. The application is then placed in suspense pending receipt of information. If the ID application is denied, the Agency informs applicants of their rights under the appeals process.
Agency files application case files in the recordkeeping system. After staff completes all outstanding actions on the application, the Agency compiles the case file and forwards it to the ID Services Division for filing. The paper case files are scanned into the Agency ID system along with the associated metadata about the application. The Agency maintains the validated images on an optical disk.

5.2.1 Application of the RM Profile to the Scenario

5.2.1.1 Addressing BRM-Related Questions

Agency C submits an Exhibit 300 to OMB to develop the ID system. The primary Line of Business and Sub-function to which this acquisition corresponds is the Direct Services for Citizens Line of Business and the Civilian Operations Sub-function under the Mode of Delivery - Government Service Delivery Business Area.

Since the development of the ID system incorporates records management functionality, an ancillary Line of Business and Sub-function for this acquisition is the Information and Technology Management Line of Business and the Records Retention Sub-function under the Management of Government Resources Business Area.

The Agency Records Officer reviews the current process and identifies the following Federal records: ID application, the final ID, and all associated supporting or clarifying documentation. Consulting ISO 15489-1, the Records Officer recommends modifications to the ID application workflow to capture recordkeeping copies at various stages in the process (as opposed to a single, final step) to enhance the trustworthiness of the process. This recommendation will also necessitate modification of the records schedule associated with the system.

Aside from capturing the recordkeeping copies, the ID system needs to interface with the Agency RMA. Once the application process is completed, the RMA will manage the ID system records in accordance with the approved records schedules. Because of the existence of an interface to the RMA, Agency C does not need to include this RM functionality in the ID system.

5.2.1.2 Addressing SRM-Related Questions

The records management capabilities that need to be built into the ID workflow described above include a record capture capability and a record linking or association capability. When linked to the ID system, the RMA will handle other records management capabilities, such as record categorization.

Considering a component-based approach, Agency C's Enterprise Architect reviews the CORE.gov website maintained by OMB's FEA Program Management Office to determine if there are existing RM components within the Registry. None have been identified to date. However, requirements for RMSCs, as defined by the ERM E-Gov Initiative, do exist within the Digital Asset Services Domain in the CORE.gov registry. The Architect and Project Manager coordinate with the Agency Records Officer to see which components would be most advantageous to develop and implement in the ID System.

Based on the existing records schedule and the proposed modifications from the BRM-related analysis, the Agency decided to capture long-term temporary records to document the ID card application process. Per the Records Management Service Components Requirements Development Project Final Report ¹⁹, the first decision point is to determine which of the six potential components to develop and deploy. The project team, in consultation with the Agency Records Officer, considers each component for potential inclusion. The thought process surrounding that activity is described below for each identified component.

Capture Record component: The purpose of this component is to capture information with associated attributes in an electronic system.

This component is selected for development and deployment as a means of implementing the business decision to capture recordkeeping copies at various stages in the workflow of the ID application adjudication process.
Assign Disposition component: This component uses an established disposition authority to assign the disposition schedule, item number, and disposition instructions to the record.

This component is not selected for development and deployment due to the manner in which the records resulting from this system have been scheduled. Since the purpose of the system has been narrowly defined (i.e., ID application adjudication), all of the output of the system falls into a single series with a uniform retention period (which can be encoded as metadata at the time of activation of the CAPTURE RECORD component).
Categorize Record component: This component utilizes agency business rules to assign an appropriate descriptive label to the records in order to facilitate management in an electronic system.

This component is not selected for development and deployment because the categorization of the records will be determined by the RMA at the time the ID System passes the record to the RMA. The interface between the RMA and the ID System will handle this function.
Ensure Authenticity component: This component ensures the acceptability of a record as genuine, based on its characteristics such as structure, content, and context.

This component is not selected for development and deployment because the Agency RMA already ensures the authenticity of the electronic information. The ID System needs to pass the characteristics of the record to the RMA, but the RMA is responsible for ensuring the authenticity of a record once the characteristics are established.
Associate Record component: This component provides the capability to associate a record to one or more other records through a Record Association attribute.

This component is selected to allow for the development of an "official case file" associated with the adjudication of any individual ID card application.
Execute Disposition component: This component implements the destruction, transfer, or continued retention of a record in accordance with the NARA-approved disposition authority. After verifying that the disposition action is valid, the component executes the disposition action and records the transaction.

This component is not selected for development because the Agency RMA already performs the execute disposition function.

Once Agency C selects the relevant components for the system, the Agency Architect should consider the larger context of the records management component(s) deployment within the Agency enterprise architecture, including the potential use by other agency systems. As such, considerations might include:

Does the deployment of these components have any potential wider applicability than the system at hand?
1. If so, how can their development and deployment be leveraged/maximized?
2. If leveraging their deployment is deemed prudent, what constraints do existing legacy applications place on their development?

For submission of the OMB Exhibit 300, Agency C identifies all SRM service components supporting the ID system; however, only those related to the RM service components are presented here. The service components applicable to records management that are being developed as part of the ID System are all contained within the Digital Asset Services Domain under the Records Management Service Type, namely the Document Classification and the Record Linking / Association Service Components. Future revisions of the SRM will likely include the RMSCs as identified in Section 5.2.1.2.

5.2.1.3 Addressing TRM-Related Questions

Agency C will have to present the technologies for the entire ID system, but the TRM discussion here relates only to technologies related to implementing the RM functionality.

After searching for existing RMSCs, Agency C concludes that they will have to build the components in-house (and later register them in CORE.gov so that other agencies will be able to take advantage of them). Given the existing ID system application framework, the Agency RMA, and consultation with system development contractors, Agency C decides on a NET solution for building the RMSCs. It will also be necessary to establish the record's structural characteristics and metadata for interfacing with the RMA to ensure that the components meet applicable DoD 5015.2-STD criteria.

The records schedule revision activity identifies several points in the process workflow where recordkeeping copies are "set aside" (e.g., during the scanning process). While ID application adjudication records have been appraised as temporary, their retention for Agency business is lengthy. As such, the Records Officer directs the project team to examine creation requirements in Expanding Acceptable Transfer Requirements: Transfer Instructions for Existing Permanent Electronic Records: Scanned Images of Textual Records so that the system will produce long-term, temporary records capable of supporting Agency business needs over time.

TRM Service Areas, Service Categories, Standards, and Specifications related to the RMSC development include:

Service Access and Delivery.
DoD 5015.2-STD, though not listed as a specification yet within the TRM, will fall under the Service Requirements Service Type and the Legislative/Compliance Standard. Also, the Intranet Standard is identified as the Delivery Channel for the communication between the ID System and the RMA, and the https Specification is identified as the Service Transport Standard for records exchanged between the ID system and the RMA.
Component Framework.
The business logic of the RMSCs will be developed according to the Visual Basic.NET Specification within the Platform Dependent Standard and Business Logic Service Type.
Service Interface and Integration.
The ID system and the RMA will communicate with each other for record passing using a Middleware Standard (within the Integration Service Type), and specifically, an Object Request Broker Specification has been selected. The XML Specification will be the Data Format/Classification Standard, and the XML Schema Specification will be the Data Types/Validation Standard to ensure that the ID system and the RMA both understand the record characteristics and metadata being passed.

5.2.1.4 Addressing DRM-Related Questions

The Agency develops the RMSCs to meet DoD 5015.2-STD criteria, thus ensuring that minimum record metadata requirements are met. The Agency also identifies and adds additional agency-unique metadata.

5.2.1.5 Addressing PRM-Related Questions

As part of the acquisition strategy, Agency C develops performance metrics for the system.

As the system is not classified primarily as a recordkeeping system, and in light of the recommendations made in the Industry Advisory Council E-Government Shared Interest Group White Paper on The Use of Metrics in Electronic Records Management (ERM) Systems ( http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf), the Agency chooses to cast system performance metrics in terms of distinct process-related improvements (e.g., reduction in time for ID application processing).

The agency already has NARA-approved disposition authorities for the output records generated by the application adjudication system. The Records Officer has carefully evaluated all steps in the workflow to determine at which points in the workflow it is necessary to capture recordkeeping copies in order to provide accountability and document work processes. This records management performance-related analysis will inform subsequent business and service component reference model-related questions.e

Chapter 6: Next Steps

The Records Management Profile is a work in progress that will continue to evolve as more records management resources are identified and the technologies supporting the FEA mature. During the review process of this document, several agencies and industry groups provided recommendations on preliminary next steps for Fiscal Year 2006. Though these actions have not been reviewed or approved by the AIC, they do provide an indication as to where future work on the RM Profile might lead.

Explore the ongoing governance process for the RM Profile with NARA, the AIC, and the FEA Program Management Office.
Discuss potential areas of collaboration with other FEA Profile projects (e.g., Security and Privacy, Geospatial).
Expand RM resources in RM Profile to include agency best practices, recently completed NARA guidance, other International standards, and related guidance.
Discuss the best approaches to promoting the use of the Profile by agencies.
Implement the RM Profile at an agency in a limited-scope pilot or test case to refine the approach and evaluate the usefulness of the RM Profile.
Incorporate records management requirements into the RM Profile as they relate to vital records, Continuity of Operations (COOP), and disaster recovery processes.

Appendix A: Selected Resources

FEA Reference Models

Federal Enterprise Architecture Program Management Office, "FEA Consolidated Reference Model Document" ( May 2005). Available at: http://www.whitehouse.gov/omb/egov/documents/CRM.PDF

General

Electronic Records Policy Working Group, "Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records: A Report to the Interagency Committee on Government Information" (June 28, 2004). Available at: http://www.cio.gov/documents/ICGI/ERPWG_Barriers.pdf

Electronic Records Policy Working Group, "Recommendations for the Effective Management of Government Information on the Internet and Other Electronic Records: A Report to the Interagency Committee on Government Information" (December 16, 2004). Available at: http://www.cio.gov/documents/ICGI/ICGI-207e-report.pdf

Federal Enterprise Architecture Program Management Office, "The FEA Security and Privacy Profile Phase I Final: A Foundation for Government-wide Improvement" (July 29, 2004). Available at: http://www.cio.gov/documents/FEA%20Security%20Profile%20Phase%20IFINAL07-29-04.doc

National Archives and Records Administration, "NARA's Strategic Directions for Federal Records Management" (July 31, 2003). Available at: http://www.archives.gov/records-mgmt/initiatives/strategic-directions.html

BRM Resources

International Standards Organization (ISO). ISO 15489-1: Information and Documentation - Records Management (2001). Available at: ( http://www.niso.org/international/index.html and http://webstore.ansi.org/ansidocstore/default.asp. In addition, agencies may obtain a discount on standards available through GSA Advantage ( https://www.gsaadvantage.gov/advgsa/advantage/main/start_page.do)

National Archives and Records Administration, "Guidance for Coordinating the Evaluation of Capital Planning and Investment Control (CPIC) Proposals for ERM Applications" (June 2003). Available at: http://www.archives.gov/records-mgmt/policy/cpic-guidance.html

National Archives and Records Administration, "Guidance for Managing Web Records" (January 2005). Available at: http://www.archives.gov/records-mgmt/policy/managing-web-records.html

National Archives and Records Administration, "Guidance on Methodology for Determining Agency-unique Requirements" (August 2004). Available at: http://www.archives.gov/records-mgmt/policy/requirements-guidance.html

Office of Management and Budget. Circular A-130, Revised, (Transmittal Memorandum No. 4), Management of Federal Information Resources (11/28/2000). Available at: http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

SRM Resources

Architecture and Infrastructure Committee, Federal Chief Information Officers Council, "Component-Based Architectures," Version 2.0 (June 2004). Available at: http://cio.gov/documents/CIOC_AIC_Service%20Component%20Based%20Architectures%20_2.0_FINAL.pdf

National Archives and Records Administration, "Records Management Service Components Requirement Development Project," Final Report (March 31, 2005). Available at: http://www.archives.gov/era/pdf/rmsc0305.pdf

TRM Resources

Department of Defense, "STD-5015.2: Design Criteria Standard for Electronic Records Management Software Applications" (June 19, 2002). Available at: http://jitc.fhu.disa.mil/recmgt/standards.html

National Archives and Records Administration, "Records Management Guidance for Agencies Implementing Electronic Signature Technologies" (October 18, 2000). Available at: http://www.archives.gov/records-mgmt/policy/electronic-signature-technology.html

National Archives and Records Administration, "Records Management Guidance for PKI Digital Signature Authenticated and Secured Transaction Records," (March 28, 2005). Available at: http://www.archives.gov/records-mgmt/policy/pki.html

National Archives and Records Administration, "Records Management Guidance for PKI-Unique Administrative Records," (March 14, 2003). Available at: http://www.archives.gov/records-mgmt/policy/pki-guidance.html

National Archives and Records Administration, "Transfer Instructions for Permanent Electronic Records" [Six format-specific products issued between September 2002-September 2004]. Available at: http://www.archives.gov/records-mgmt/initiatives/erm-products.html

DRM Resources

Department of Defense, "STD-5015.2: Design Criteria Standard for Electronic Records Management Software Applications (Minimum Metadata Profile)," (June 19, 2002). Available at: http://jitc.fhu.disa.mil/recmgt/standards.html

PRM Resources

Industry Advisory Council, "The Use of Metrics in Electronic Records Management (ERM) Systems (White Paper)," (August 2004). Available at: http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf

Appendix B: Glossary

Business Reference Model (BRM): a function-driven framework to describe the Lines of Business and internal functions performed by the Federal Government independent of the agencies that perform them. Agencies' major IT investments are mapped to the BRM to identify collaboration opportunities.

Capital Planning and Investment Control (CPIC): a decision-making process for ensuring that IT investments integrate strategic planning, budgeting, procurement, and the management of IT in support of agency missions and business needs.

Component: a self-contained process, service, or IT capability with pre-determined functionality that may be exposed through a business or technology interface.

Component-based Architecture: an enterprise architecture based upon categorizing business, service, performance, technical, and data entities, at their lowest level, as components, then recognizing larger lines of business, service, and technology infrastructures as combinations of components, enabling the design of enterprise solutions using pre-manufactured components.

Data Reference Model (DRM): describes, at an aggregate level, the data and information that support government programs and business line operations. The DRM enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources.

Disposition: actions taken regarding records after they are no longer required to conduct current Agency business.

Electronic records: include numeric, graphic, and text information, which may be recorded on any medium capable of being read by a computer and which satisfy the definition of a record. This includes, but is not limited to, magnetic media, such as tapes and disks, and optical disks. Unless otherwise noted, these requirements apply to all electronic information systems, whether on microcomputers, minicomputers, or mainframe computers, regardless of storage media, in network or stand-alone configurations (36 CFR 1234.1).

Federal Enterprise Architecture (FEA): a framework for describing the relationship between business functions and the technologies and information that support them. Agencies' major IT investments are aligned against each reference model within the FEA framework.

Information: any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual forms.

Information system: a discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual. An electronic information system is a system that contains and provides access to computerized Federal records and other information (36 CFR 1234.2).

Metadata: are data describing stored data, that is, data describing the structure, content, context, and other characteristics of electronic records.

Performance Reference Model (PRM): a standardized performance measurement framework to characterize performance in a common manner where necessary. The PRM will help agencies produce enhanced performance information; improve the alignment and better articulate the contribution of inputs, such as technology, to outputs and outcomes; and identify improvement opportunities that span traditional organizational boundaries.

Public Key Infrastructure (PKI): a set of policies, processes, server platforms, software, and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

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 data in them. Library or museum material made or acquired and preserved solely for reference or exhibition purposes, extra copies of documents preserved only for convenience of reference, and stocks of publications and of processed documents are not included (44 USC 3301).

Records management: the field of management responsible for the systematic control of the creation, maintenance, use, and disposition of records." From the Federal perspective, it is the planning, controlling, directing, organizing, training, promoting, and other managerial activities involved in records creation, maintenance and use, and 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 (44 USC 2901).

Records Management Application (RMA): software used by an organization to manage its records. An RMA's primary management functions are categorizing and locating records and identifying records that are due for disposition. RMA software also stores, retrieves and disposes of the electronic records that are stored in its repository.

Records Management Service Component (RMSC): a piece of software that provides services that support the creation, management, transfer, and destruction of electronic records within a computing environment.

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 (36 CFR 1220.14). Agencies may also identify recordkeeping requirements in their business and systems processes that are not mandated by laws or regulations but are equally valid. Recordkeeping requirements should be outlined in procedural manuals and other issuances that specify which records need to be included in agency files or other recordkeeping systems.

Records Schedule: provides mandatory instructions for what to do with records (and non-record materials) no longer needed for current Government business. Also retention schedule, disposition schedule, and records control schedule.

Service Component Reference Model (SRM): provides a common framework and vocabulary for characterizing the IT and business components that collectively comprise an IT investment. The SRM will help agencies rapidly assemble IT solutions through the sharing and re-use of business and IT components.

Service-Oriented Architecture (SOA): defines how two computing entities interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. The unit of work is referred to as a service, and the service interactions are defined using a description language.

Technical Reference Model (TRM): provides a foundation to describe the standards, specifications, and technologies supporting the delivery, exchange, and construction of business (or Service) components and E-Gov solutions. The TRM unifies existing agency TRMs and Electronic Government (E-Gov) guidance by providing a foundation to advance the re-use of technology and component services from a Government-wide perspective.

Appendix C: List of Exhibits

No.	Title
2.0	Records Life Cycle
3.0	Viewing Records Management through the FEA
3.1	Business Reference Model
3.2	Service Component Reference Model
3.3	Records Management Activities Supportable by Service Components
3.4	Technical Reference Model
3.5	Data Reference Model Structure
3.6	Data Reference Model "Categorization of Data" Area
3.7	Information Exchange Package
3.8	Data Reference Model "Structure of Data" Area
3.9	Performance Reference Model
3.10	Sample Use of PRM to Identify Measurement Indicators
3.11	Illustration of the FEA Integrated with Records Management
4.0	Records Management Integration into the SDLC
4.1	Illustration of the Utility of Component-Based Architectures
4.2	Records Management Component Discovery
4.3	FEA Reference Model Order when Considering an IT Investment
5.0	Illustrative Navigation through the FEA Reference Models

Appendix D: List of Acronyms

AIC	Architecture and Infrastructure Committee
BRM	Business Reference Model
CBA	Component-Based Architecture
CCB	Configuration Control Board
CFR	Code of Federal Regulations
CIO	Chief Information Officer
COI	Community of Interest
COTS	Commercial Off-the-Shelf
CPIC	Capital Planning and Investment Control
DoD	Department of Defense
DRM	Data Reference Model
EA	Enterprise Architecture
ERM	Electronic Records Management
ERPWG	Electronic Records Policy Working Group
FEA	Federal Enterprise Architecture
FEA PMO	Federal Enterprise Architecture Program Management Office
GC	General Counsel
GPEA	Government Paperwork and Elimination Act
GSA	General Services Administration
HTTP	Hypertext Transfer Protocol
IAC	Industry Advisory Council
ICGI	Interagency Committee on Government Information
IRM	Information Resources Management
ISO	International Standards Organization
IT	Information Technology
MOU	Memorandum of Understanding
NARA	National Archives and Records Administration
OMB	Office of Management and Budget
PKI	Public Key Infrastructure
PRM	Performance Reference Model
RM	Records Management
RMA	Records Management Application
RMO	Records Management Officer. Also Records Officer.
RMSC	Records Management Service Component(s)
SDLC	Systems Development Life Cycle
SOA	Service-Oriented Architecture
SRM	Service Component Reference Model
TRM	Technical Reference Model
USC	United States Code
WSDL	Web Services Description Language
XML	eXtensible Markup Language

¹ For a more detailed discussion of the barriers to the effective management of electronic records, please refer to the Electronic Records Policy Working Group, "Barriers to the Effective Management of Government Information on the Internet and Other Electronic Records: A Report to the Interagency Committee on Government Information" (June 28, 2004). Available at: http://www.cio.gov/documents/ICGI/ERPWG_Barriers.pdf

²Federal Enterprise Architecture Program Management Office, "The FEA Security and Privacy Profile Phase I Final: A Foundation for Government-wide Improvement " (July 29, 2004). Available at: http://www.cio.gov/documents/FEA_Security_Profile_Phase_I_Final_07-29-2004.pdf

³ Electronic Records Policy Working Group, "Recommendations for the Effective Management of Government Information on the Internet and Other Electronic Records: A Report to the Interagency Committee on Government Information" (December 16, 2004). Available at: http://www.cio.gov/documents/ICGI/ICGI-207e-report.pdf

⁴ Office of Management and Budget. Circular A-130, Revised, (Transmittal Memorandum No. 4), Management of Federal Information Resources (11/28/2000). Available at:http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

⁵ National Archives and Records Administration, "Transfer Instructions for Permanent Electronic Records" [Six format-specific products issued between September 2002-September 2004]. Available at: http://www.archives.gov/records-mgmt/initiatives/erm-products.html

⁶ National Archives and Records Administration, "Guidance for Managing Web Records," January 2005. Available at: http://www.archives.gov/records-mgmt/policy/managing-web-records-index.html

⁷ Office of Management and Budget. Circular A-130, Revised, (Transmittal Memorandum No. 4), Management of Federal Information Resources (11/28/2000). Available at: http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

⁸ International Standards Organization (ISO). ISO 15489-1: Information and Documentation - Records Management. 2001. Available at: http://www.iso.org

⁹ The term "records schedule" is synonymous with the terms "disposition schedule" and "retention schedule" also used in this document.

¹⁰ Federal Enterprise Architecture - Program Management Office, "The FEA Security and Privacy Profile Phase I Final: A Foundation for Government-wide Improvement" (July 29, 2004). Available at: http://www.cio.gov/documents/FEA_Security_Profile_Phase_I_Final_07-29-2004.pdf

¹¹ As defined by the Federal CIO Council, Architecture and Infrastructure Committee, a component is a self-contained process, service, or IT capability with pre-determined functionality that may be exposed through a business or technology interface.

¹² Federal CIO Council, "Service Component-Based Architectures," Version 2.0, June 2004. Available at http://cio.gov/index.cfm?function=subEA.

¹³ For additional information on OMB's and the CIO Council's views on service components, see (1) Federal Enterprise Architecture - Program Management Office, Federal Enterprise Architecture Service Component Reference Model Release Document, Version 1.0. (June 2003), and (2) Federal CIO Council, Architecture and Infrastructure Committee, Service Component-Based Architectures, Version 2.0, June 2004.

¹⁴ http://www.archives.gov/records-mgmt/policy/cpic-guidance.html

¹⁵If the agency has not previously executed the MOU with the ERM Initiative.

¹⁶DoD 5015.2-STD is based on legal requirements that are applicable to all federal agencies. Testing for compliance with the standard is conducted by the Joint Interoperability Test Command of the Defense Information Systems Agency. Those commercial-off-the-shelf records products that pass the certification test are placed on a formal Records Management Software Applications Product Register. A summary test report is also available on the register. The register is located at http://jitc.fhu.disa.mil/recmgt/.

¹⁷See NARA's Guidance for Coordinating the Evaluation of Capital Planning and Investment Control Proposals for ERM Applications ( http://www.archives.gov/records-mgmt/policy/cpic-guidance.html)

¹⁸This activity allows for the creation of a Case File by linking the records of the case file. It allows for the linking of a record that was used to create a redacted or declassified record in the record declassification process. It allows for the linking of a record used to create to response to an information request such as FOIA. Although outside the scope of this work, it is anticipated that it might be used to associate the body of a record with its attachments.

¹⁹ http://www.archives.gov/era/pdf/rmsc0305.pdf

Page updated: April 26, 2019

Top