Federal Enterprise Architecture Records Management Profile

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.

Viewing Records Management through the FEA

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.

Chapter 6: Next Steps

Appendix A: Selected Resources

Appendix B: Glossary

Appendix C: List of Exhibits

Appendix D: List of Acronyms

Top of Page

Acknowledgements

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)

Top of Page

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

Top of Page

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 policy that relate to their business.

NARA also issues policy 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 web site (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 means 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 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 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.

Top of Page

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 inter-related 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 to 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 web site 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

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

formats. In addition, there are a number of guidance products on the NARA web site that provide updated guidance, including products on managing web site records and guidance on implementing electronic signatures in compliance with the Government Paperwork Elimination Act (GPEA).

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 world-wide federation of national standards bodies - issued an international standard for records management to ensure that attention and protection is 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 systems.

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 web sites as well as the records documenting web site operations. The guidance is based on statutory requirements, and sets forth principles that form a sound basis for agency web site management operations. While the guidance primarily discusses public Internet web sites, it is equally applicable to web sites that may be on agency intranets, virtual private networks, and security-classified web sites.

Part One of the guidance provides general background information, identifies records management responsibilities for agency web sites, 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 web sites, and agency staff responsible for managing web sites, 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 agency internet and intranet web sites.

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 allows 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 the cross-functional capabilities that can be leveraged independent of 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 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 consensus on six records management activities that are identified below in Exhibit 3.3. NARA is continuing its work with 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 web site 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.
Catalogue 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 re-define 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.

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 pre-requisites 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 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 Department of Defense (DoD) 5015.2-STD align to 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 records 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), has 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, semistructured, 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. 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 both 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 are data that defines and describes other data. Metadata about a record include 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 need 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 agency 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.

Top of Page

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 the 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 to 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 a 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 records life cycle, such as capture (create), retrieve, or dispose 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 web site.

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 re-usable 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.

NARA

Records Managers

Records Management Resources

Federal Enterprise Architecture Records Management Profile

Version 1.0

Executive Summary

Table of Contents

Chapter 1: Introduction

Chapter 2: Records Management Basics

Chapter 3: Overview of the Federal Enterprise Architecture

Chapter 4: Using the RM Profile to Improve Records Management

Chapter 5: Application of the RM Profile

Chapter 6: Next Steps

Appendix A: Selected Resources

Appendix B: Glossary

Appendix C: List of Exhibits

Appendix D: List of Acronyms

Acknowledgements

Chapter 1: Introduction

Chapter 2: Records Management Basics

Chapter 3: Overview of the Federal Enterprise Architecture

Chapter 4: Using the RM Profile to Improve Records Management