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
December 15, 2005 FEA Records Management Profile, Version 1.0 ii

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 iii

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 FEA

Business Reference Model (BRM)

Agencies analyze their business processes to help identify the 

records they create, receive, maintain, and use.

Service Component Reference Model (SRM)

Agency use of records management service components will help 

automate the records management life cycle.

Data Reference Model (DRM)

Facilitate the transfer of records between RMSC and applications. 

Enable discovery and access by agencies and the public.

Technical Reference Model (TRM)

Agency use of the TRM will help identify the standards, specifications 

and technologies needed to support RMSC.

IAC White Paper

OMB, ISO, NARA Guidance

RM Service Components (RMSC)

DoD 5015.2-STD

NARA GPEA Guidance

NARA Transfer Instructions

DoD 5015.2 Metadata Profile

RM Resources

Performance Reference Model (PRM)

Agencies identify metrics and goals for records management 

performance and outcomes.
December 15, 2005 FEA Records Management Profile, Version 1.0 iv

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 v

Table of Contents

Executive Summary ...................................................................................................................... ii

Table of Contents...........................................................................................................................v

Acknowledgements ..................................................................................................................... vii

Chapter 1: Introduction

1.0 Overview............................................................................................................................. 1

1.1 RM Profile Context ............................................................................................................. 1

1.2 Vision for the RM Profile ................................................................................................... 2

1.3 Objectives of the RM Profile .............................................................................................. 2

1.4 Intended Audience .............................................................................................................. 3

Chapter 2: Records Management Basics

2.0 NARA Policy and Guidance ............................................................................................... 5

2.1 Other Guidance ................................................................................................................... 6

2.2 Definitions........................................................................................................................... 6

2.3 The Records Life Cycle ...................................................................................................... 7

2.4 The Value of Effective Records Management .................................................................... 9

2.5 Agency Responsibilities for Records Management.......................................................... 10

2.6 Agency Responsibilities for Information Resources Management .................................. 10

2.7 Staff Responsibilities ........................................................................................................ 11

Chapter 3: Overview of the Federal Enterprise Architecture

3.0 Records Management and the FEA .................................................................................. 12

3.1 Overview of the Business Reference Model..................................................................... 13

3.2 Overview of the Service Component Reference Model................................................... 18

3.3 Overview of the Technical Reference Model................................................................... 22

3.4 Overview of the Data Reference Model ........................................................................... 26

3.5 Overview of the Performance Reference Model............................................................... 31

3.6 The Records Life Cycle and the Reference Models ......................................................... 33

Chapter 4: Using the RM Profile to Improve Records Management

4.0 Developing Investment Strategies .................................................................................... 35

4.1 Records Management and the SDLC................................................................................ 35

4.2 Records Management Applications (DoD 5015.2-STD).................................................. 39

4.3 Component-Based Architecture and Records Management Service Components........... 40

4.4 Component-Based Architecture and DoD 5015.2-STD ................................................... 42

4.5 Records Management, the FEA, and Federal Investment Strategies................................ 43

4.6 Sample FEA Related Questions........................................................................................ 44
December 15, 2005 FEA Records Management Profile, Version 1.0 vi

Table of Contents (cont’d)

Chapter 5: Application of the RM Profile

5.0 Implementing a Records Management Application......................................................... 48

5.1 Incorporating a Records Management Component into a Mission Application............... 54

5.2 Developing a Mission Application with a Records Management Component 

and Linking to an RMA.................................................................................................... 58

Chapter 6: Next Steps ................................................................................................................ 64

Appendix A: Selected Resources .............................................................................................. 65

Appendix B: Glossary ................................................................................................................ 68

Appendix C: List of Exhibits .................................................................................................... 71

Appendix D: List of Acronyms .................................................................................................. 72
December 15, 2005 FEA Records Management Profile, Version 1.0 vii

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, thoughtprovoking 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)
December 15, 2005 FEA Records Management Profile, Version 1.0 1

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.

1

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

 

1

For a more detailed discussion of the barriers to the effective management of electronic records, please refer to the 

Electronic Records Policy Working Group, “Barriers to the Effective Management of Government Information on 

the Internet and Other Electronic Records: A Report to the Interagency Committee on Government Information” 

(June 28, 2004). Available at: http://www.cio.gov/documents/ICGI/ERPWG_Barriers.pdf
December 15, 2005 FEA Records Management Profile, Version 1.0 2

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

2

 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.

3

 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 

 

2 Federal Enterprise Architecture Program Management Office, “The FEA Security and Privacy Profile Phase I 

Final: A Foundation for Government-wide Improvement “ (July 29, 2004). Available at: 

http://www.cio.gov/documents/FEA_Security_Profile_Phase_I_Final_07-29-2004.pdf

3 Electronic Records Policy Working Group, “Recommendations for the Effective Management of Government 

Information on the Internet and Other Electronic Records: A Report to the Interagency Committee on Government 

Information” (December 16, 2004). Available at: http://www.cio.gov/documents/ICGI/ICGI-207e -report.pdf
December 15, 2005 FEA Records Management Profile, Version 1.0 3

procedures and other records management requirements (e.g., OMB Circular A-130).4 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 

 

4 Office of Management and Budget. Circular A-130, Revised, (Transmittal Memorandum No. 4), Management of 

Federal Information Resources (11/28/2000). Available at: 

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html
December 15, 2005 FEA Records Management Profile, Version 1.0 4

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 5

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 NARA5 and the guidance for managing web records,6 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 

 

5 National Archives and Records Administration, “Transfer Instructions for Permanent Electronic Records” [Six 

format-specific products issued between September 2002-September 2004]. Available at:

http://www.archives.gov/records-mgmt/initiatives/erm-products.html

6 National Archives and Records Administration, “Guidance for Managing Web Records,” January 2005. Available 

at: http://www.archives.gov/records-mgmt/policy/managing-web-records-index.html
December 15, 2005 FEA Records Management Profile, Version 1.0 6

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-1307provides 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

8

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

 

7 Office of Management and Budget. Circular A -130, Revised, (Transmittal Memorandum No. 4), Management of 

Federal Information Resources (11/28/2000). Available at: 

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

8 International Standards Organization (ISO). ISO 15489-1: Information and Documentation – Records 

Management. 2001. Available at: http://www.iso.org
December 15, 2005 FEA Records Management Profile, Version 1.0 7

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. 
December 15, 2005 FEA Records Management Profile, Version 1.0 8

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.

Creation or 

Receipt

Maintenance 

and Use

Disposition

PERMANENT

TEMPORARY
December 15, 2005 FEA Records Management Profile, Version 1.0 9

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 
December 15, 2005 FEA Records Management Profile, Version 1.0 10

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 
December 15, 2005 FEA Records Management Profile, Version 1.0 11

(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 

schedules9 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 decisionmaking processes.

 

9

 The term ‘records schedule’ is synonymous with the terms ‘disposition schedule’ and ‘retention schedule’ also 

used in this document.
December 15, 2005 FEA Records Management Profile, Version 1.0 12

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 citizencentered, 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.
December 15, 2005 FEA Records Management Profile, Version 1.0 13

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.

10

 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 highlevel categories relating to the purpose of Government (Services for Citizens), the mechanisms 

 

10 Federal Enterprise Architecture - Program Management Office, “The FEA Security and Privacy Profile Phase I 

Final: A Foundation for Government-wide Improvement” (July 29, 2004). Available at:

http://www.cio.gov/documents/FEA_Security_Profile_Phase_I_Final_07-29-2004.pdf

The FEA

Business Reference Model (BRM)

Agencies analyze their business processes to help identify the 

records they create, receive, maintain, and use.

Service Component Reference Model (SRM)

Agency use of records management service components will help 

automate the records management life cycle.

Data Reference Model (DRM)

Facilitate the transfer of records between RMSC and applications. 

Enable discovery and access by agencies and the public.

Technical Reference Model (TRM)

Agency use of the TRM will help identify the standards, specifications 

and technologies needed to support RMSC.

IAC White Paper

OMB, ISO, NARA Guidance

RM Service Components (RMSC)

DoD 5015.2-STD

NARA GPEA Guidance

NARA Transfer Instructions

DoD 5015.2 Metadata Profile

RM Resources

Performance Reference Model (PRM)

Agencies identify metrics and goals for records management 

performance and outcomes.
December 15, 2005 FEA Records Management Profile, Version 1.0 14

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 Subfunctions: (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.

Defense & National Security

Homeland Security

Intelligence Operations

Law Enforcement

International Affairs & Commerce

Litigation & Judicial Activities

Correctional Activities

Education

Energy

Health

Transportation

Income Security

Environmental Management

Natural Resources

Disaster Management

Community & Social Services

Economic Development

Workforce Management

General Science & Innovation

Direct Services for Citizens

Knowledge Creation & Management

Public Goods Creation & 

Management

Regulatory Compliance & Enforcement

Federal Financial Assistance

Credit & Insurance

Transfers to States & 

Local Governments

Services for

Citizens

Mode of 

Delivery

Legislative Relations

Public Affairs

Regulatory Development

Planning & Resource Allocation

Controls & Oversight

Revenue Collection

Internal Risk Management &

Mitigation

General Government

Support Delivery

of Services

Supply Chain Management

Human Resource Management

Financial Management

Administrative Management

Information & Technology 

Management

Management of Government

Resources

Purpose of 

Government

Mechanisms

Used to

Achieve

Purpose

Government

Operations

Support

Functions

Resource

Management

Functions

Business 

Areas (4)

Lines 

of

Business (39)

Defense & National Security

Homeland Security

Intelligence Operations

Law Enforcement

International Affairs & Commerce

Litigation & Judicial Activities

Correctional Activities

Education

Energy

Health

Transportation

Income Security

Environmental Management

Natural Resources

Disaster Management

Community & Social Services

Economic Development

Workforce Management

General Science & Innovation

Direct Services for Citizens

Knowledge Creation & Management

Public Goods Creation & 

Management

Regulatory Compliance & Enforcement

Federal Financial Assistance

Credit & Insurance

Transfers to States & 

Local Governments

Services for

Citizens

Mode of 

Delivery

Legislative Relations

Public Affairs

Regulatory Development

Planning & Resource Allocation

Controls & Oversight

Revenue Collection

Internal Risk Management &

Mitigation

General Government

Support Delivery

of Services

Supply Chain Management

Human Resource Management

Financial Management

Administrative Management

Information & Technology 

Management

Management of Government

Resources

Purpose of 

Government

Mechanisms

Used to

Achieve

Purpose

Government

Operations

Support

Functions

Resource

Management

Functions

Business 

Areas (4)

Lines 

of

Business (39)
December 15, 2005 FEA Records Management Profile, Version 1.0 15

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, Subfunctions 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.

Example...

An example of an agency-specific records 

requirement based upon Line of Business 

considerations concerns the Federal 

program to license and construct a highlevel 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. 

• Management of Government Resources Business Area >Information and Technology 

Management Line of Business >Record Retention Sub-function.

This Sub-function is reserved for the “...operations 

surrounding 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 

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 agencyspecific 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 
December 15, 2005 FEA Records Management Profile, Version 1.0 16

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

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/)

Agencies should refer to NARA regulations codified in Title 36 of the Code of Federal 

Regulations for requirements that apply to all Federal agencies. These requirements cover each 

stage of the records life cycle (e.g., from records creation and management through final 

disposition) and provide specific guidance for managing electronic records, email, and other 

formats. In addition, there are a number of guidance 

products on the NARA 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
December 15, 2005 FEA Records Management Profile, Version 1.0 17

• 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/recordsmgmt/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 agencyspecific 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/recordsmgmt/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.
December 15, 2005 FEA Records Management Profile, Version 1.0 18

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.11 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: 

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

2. The Process Automation Services Domain – the capabilities that support the automation of 

process and management activities that assist in effectively managing the business. 

 

11 As defined by the Federal CIO Council, Architecture and Infrastructure Committee, a component is a selfcontained process, service, or IT capability with pre-determined functionality that may be exposed through a 

business or technology interface.
December 15, 2005 FEA Records Management Profile, Version 1.0 19

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

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

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

6. The Back Office Services Domain consists of the capabilities that support the management of 

enterprise planning transactional-based functions

7. 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 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 ComponentBased Architectures in 2004, and it is now being updated to reflect the advancement and 

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 20

Records Management Resources

for the SRM

• NARA, RMSC Requirements Report 

maturity of the FEA, new technologies and architectural frameworks, and proven industry best 

practices.12

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

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.

 

12 Federal CIO Council, “Service Component-Based Architectures,” Version 2.0, June 2004. Available at 

http://cio.gov/index.cfm?function=subEA .
December 15, 2005 FEA Records Management Profile, Version 1.0 21

Draft

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 reviewon NARA’s web site at http://www.archives.gov/era/rmsc 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 

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. 
December 15, 2005 FEA Records Management Profile, Version 1.0 22

• 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: 

1. Service Access and Delivery – refers to the collection of standards and specifications to 

support external access, exchange, and delivery of service components or capabilities. 

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

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

4. 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.
December 15, 2005 FEA Records Management Profile, Version 1.0 23

Exhibit 3.4. Technical Reference Model

3.3.1 Records Management within the TRM

Currently, the TRM does not include or address records 

management. However, as the TRM continues to mature, it 

is reasonable to expect that it will incorporate NARA 

requirements in Title 36 of the Code of Federal Regulations 

(36 CFR) pertaining to the adequacy of documentation and 

the disposition of records, and GSA requirements in 41 CFR 

pertaining to the economy and efficiency of records 

management. 

These legal mandates that agencies must consider in 

developing IT solutions are captured in the Service Access 

and Delivery Service Area >Service Requirements Service 

Category >Legislative / Compliance Service Standard. 

Service Access 

and Delivery

Access Channels

Delivery Channels

Service Requirements

Service Transport

Legislative/Compliance

- Section 508

- Web Content Accessibility

- Security

- Privacy

- Records Management

Authentication

Single Sign-on

Service Access 

and Delivery

Access Channels

Delivery Channels

Service Requirements

Service Transport

Legislative/Compliance

- Section 508

- Web Content Accessibility

- Security

- Privacy

- Records Management

Authentication

Single Sign-on

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 24

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

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 25

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

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 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 nonmandatory 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 esignature 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;
December 15, 2005 FEA Records Management Profile, Version 1.0 26

• 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. 
December 15, 2005 FEA Records Management Profile, Version 1.0 27

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
December 15, 2005 FEA Records Management Profile, Version 1.0 28

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 
December 15, 2005 FEA Records Management Profile, Version 1.0 29

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 30

Records Management Resources 

for the DRM

• DoD 5015.2-STD Minimum 

Metadata Profile

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) 

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. 
December 15, 2005 FEA Records Management Profile, Version 1.0 31

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: 

1. Mission and business results – to capture the outcomes that agencies seek to achieve. 

2. Customer results – to capture how well an agency or specific process within an agency is 

serving its customers. 

3. Processes and activities – to capture the outputs that directly result from the processes that IT 

initiatives support. 

4. Technology – to capture key performance elements directly associated with IT initiatives. 

Exhibit 3.9. Performance Reference Model

Within the PRM, 

Measurement Areas are 

decomposed into Measurement 

Categories. 

Measurement Categories are 

further decomposed into 

Measurement Indicators.

For example, the Service 

Accessibility Measurement 

Category includes four 

Measurement Indicators: 

access, availability, 

automation, and integration.
December 15, 2005 FEA Records Management Profile, Version 1.0 32

Records Management Resource

 for the PRM

• Industry Advisory Council, “The Use 

of Metrics in Electronic Records 

Management Systems” 

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

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 33

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.

Records Management Profile

Creation 

and Receipt

Records Management Profile

FEA

BRM

SRM

TRM

DRM

PRM

Maintenance 

and Use

Disposition

Policies and Procedures

Components, Services, Shared Service Centers

Standards, Specifications, and Technologies

Information Structure, Exchange, and Access

Performance Metrics and Results

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B

L

O

B
December 15, 2005 FEA Records Management Profile, Version 1.0 34

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. A130 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.
December 15, 2005 FEA Records Management Profile, Version 1.0 35

4.0 DEVELOPING INVESTMENT STRATEGIES

For Federal agencies the logical place to begin using the RM Profile is when agencies reengineer 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 
December 15, 2005 FEA Records Management Profile, Version 1.0 36

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.

Concept

Development Requirements

Definition

Preliminary

Design

Detailed

Design

Development

Integration &

System Test

Deployment

& Acceptance

Production

Retirement &

Rollover

Records 

Officer

brought into

the system

design

process

Records 

Officer 

Signature as

Stakeholder on

The IT 

Investment

Proposal

summary

Proposed

records 

schedule

created or

discussion

initiated

Formal Systems

Requirements

Document

containing all

recordsrelated

requirements

Records 

Officer 

signature as

stakeholder on

Preliminary 

Design 

Document 

incorporating

requirements

Records

Officer

included in

project status

meetings

as

needed

Records

Officer

included in

project status

meetings

as

needed

Records

Officer has

reviewed

draft records

schedule

Records

Officer

included in

project status

meetings

as

needed

Annual 

IT review

citing

recordsrelated

concerns

forwarded to

Records

Officer

for

action

Records 

Officer 

signature as

stakeholder on

Systems Test

Report

Draft records

schedule

prepared

Records 

Officer 

signature on

project review

certification

document(s)

Records 

Officer 

signature on

the shut -down

documentation

certifying all

records

,management

concerns have

been addressed
December 15, 2005 FEA Records Management Profile, Version 1.0 37

(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 welldocumented 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?
December 15, 2005 FEA Records Management Profile, Version 1.0 38

(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.
December 15, 2005 FEA Records Management Profile, Version 1.0 39

RMA Advantages

• Endorsed by 

NARA

• Tested and 

certified by DOD

• Few other options

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 NARAendorsed requirements that ensure that RMAs provide records management functionality 

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.
December 15, 2005 FEA Records Management Profile, Version 1.0 40

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.”13 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 

 

13 For additional information on OMB’s and the CIO Council’s views on service components, see: (1) Federal 

Enterprise Architecture – Program Management Office, Federal Enterprise Architecture Service Component 

Reference Model Release Document, Version 1.0. (June 2003), and (2) Federal CIO Council, Architecture and 

Infrastructure Committee, Service Component-Based Architectures, Version 2.0, June 2004. 
December 15, 2005 FEA Records Management Profile, Version 1.0 41

CBA Advantages

• ‘Plug and play’

• Re-usability

• More easily integrated 

into agency enterprise 

architectures

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

Records Management

Service Components

(not all inclusive)

Capture

Record

Assign 

Disposition

Categorize

Record

Dispose

Record

Associate

Record

Line of Business

Service Components

(not all inclusive)

Component

Capture

Record

Component

Component 

Component
December 15, 2005 FEA Records Management Profile, Version 1.0 42

Exhibit 4.2. Records Management Component Discovery

Service

Provider

Service

Consumer

Service

Registry or

Directory

Service Description 

Query Response

Registry Queries

XML Service Request

XML Service Response

The illustration above is a simple diagram of how services can be exposed, discovered, and 

accessed. There is much more involved in the process of defining components and services, 

incorporating the technologies within an agency to develop and/or take advantage of services, 

and building Service-Oriented Architectures (SOAs), all of which are beyond the scope of this 

document. 

The definition, exposure, and use of business and technical services is still in its infancy within 

the Federal Government; however, a service orientation appears to be the direction of the future. 

Over time, the objective is to maximize enterprise-wide services and components while 

providing unique services and components only for specialized requirements. It constitutes a 

new way of thinking, and provides an opportunity for agencies to share data and services, such as 

records management services and components, where it makes sense to do so, as opposed to 

developing in-house solutions with limited efficiency and re-usability. In developing their IT 

investment strategies, agencies should consider the advantages of re-use or accessing existing 

services and components. 

4.4 COMPONENT-BASED ARCHITECTURE AND DoD 5015.2-STD

When developing investment strategies, agencies need to be aware of the advantages and 

challenges to implementing either of the above approaches to building records management 

functionality into agency business processes. Regardless of the option selected, the RM Profile 

can advise the planning, acquisition, and implementation of components or RMAs. While this 

document treats RMAs and CBAs as distinct approaches, especially in the scenarios that follow, 

they are in fact complementary. The DoD standard applies to the development of applications 

that support the entire life cycle of records, but it is also applicable to developing components of 

a records management service. The RMSCs that set forth standard business functionality of 

records management (independent of applications that provide the service), and the 

functionality/capability provided by an RMA are contained within the SRM. The DoD 5015.2-

STD that stipulates technical requirements for an RMA (and can be extended to RM component 

software) is also contained within the TRM.
December 15, 2005 FEA Records Management Profile, Version 1.0 43

4.5 RECORDS MANAGEMENT, THE FEA AND FEDERAL INVESTMENT 

STRATEGIES 

The following questions provide specific examples of how agencies can use the RM Profile as a 

guide for integrating records management into their acquisition and implementation strategies. 

Derived from the resources identified in Chapter 3 (and listed in Appendix A), the questions 

highlight many of the key issues relevant to each FEA reference model. Agencies should 

address these questions before proposing solutions for funding through the Investment 

Management process. Where appropriate, the questions refer agencies to the relevant records 

management resources where answers or additional guidance can be found. 

Parallel to the discussion in Chapter 3, the questions show how to approach an IT investment in 

relation to the FEA reference models. A common approach when planning an IT investment is 

to consider:

• First, what business is supported within the BRM (e.g., the records management Subfunction within the Information and Technology Management Line of Business, or the 

Border and Transportation Security Sub-function within the Homeland Security Line of 

Business)?

• Second, what capabilities or services (SRM) are being sought to support the business that the 

IT investment will provide (e.g., RMSCs)? 

• Third, what technologies (TRM) will be used to develop or access the capabilities or services 

(e.g., DoD 5015.2-STD, .NET, or WSDL)? 

• Fourth, what data (DRM) will be created, used or shared? 

• Finally, what performance metrics or results (PRM) are to be achieved (e.g., how will 

agencies measure agency and individual employee performance with respect to the creation, 

management, and sharing of records?)?

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

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

BRM SRM TRM DRM PRM

It is important to note that the questions provided are not comprehensive; rather, they are a 

starting point for this version of the RM Profile and will continue to evolve in future iterations of 

this document as more resources are identified and agencies gain experience using the RM 

Profile.
December 15, 2005 FEA Records Management Profile, Version 1.0 44

4.6 SAMPLE FEA RELATED QUESTIONS

4.6.1 BRM Questions

1. What Line of Business is identified in the Exhibit 300 for this system acquisition?

2. Is one of the existing records management Line s of Business identified as the primary or 

ancillary Line of Business for the system?

A. If records management is a primary Line of Business in the Exhibit 300, has your 

agency signed an “agency commitment Memorandum of Understanding (MOU)” 

with E-Records Management (ERM) E-Gov?

B. If yes, has your capital planning investment control board considered ERM EGov’s Guidance for Coordinating the Evaluation of Capital Planning and 

Investment Control (CPIC) Proposals for ERM Applications?

3. Have you identified within the primary Line of Business of the system which specific 

activities will generate Federal records? Which will access Federal records? Which will 

transfer or share Federal records?

4. Have the processes supporting the primary Line of Business been re-designed?

A. If yes, have you considered the characteristics of recordkeeping trustworthiness 

discussed in ISO 15489-1 in that re-design?

B. What effect does the Line of Business re-design have on recordkeeping,

management, and use by other processes and services?

4.6.2 SRM Questions

1. What records management services or capabilities are required to support the business 

identified above?

2. Are you considering an RMA or a component-based approach for automating record 

management functionality?

A. If component-based, have you consulted the RMSC requirements in the 

CORE.gov registry at OMB’s FEA Program Management Office?

B. If component-based, do the RMSCs that meet your records management 

requirements already exist within your Agency or elsewhere within the Federal 

Government?

3. For either RMA or RMSC implementation, have you identified the applicable SRM 

components?
December 15, 2005 FEA Records Management Profile, Version 1.0 45

4.6.3 TRM Questions

1. Are you using an RMA to accomplish the required records management 

functionalities?

A. If yes, does the RMA comply with the DoD 5015.2-STD?

B. If yes, has your agency consulted ERM E-Gov’s ERM Guidance on Methodology 

for Determining Agency-unique Requirements to determine additional 

requirements beyond the DoD 5015.2-STD minimum requirements?

2. Are you using RMSCs to accomplish the required records management 

functionalities?

A. If yes, how are you acquiring the service components?

1) Are you acquiring the components in accordance with NARA’s draft RMSC 

requirements?

2) If developing the component, what technologies from the TRM are you using 

(e.g., .NET)?

3) If accessing another Agency’s component, what TRM technologies do you 

need to access the component (e.g., web service, WSDL, XML)?

a) Have you executed a Service Level Agreement with the other Agency?

b) Do the components comply with DoD 5015.2-STD?

B. What relationship exists between records management services and technologies?

Agencies should evaluate existing technologies in the marketplace and determine 

which solutions can support desired records management services. 

3. Do the technology components that meet your records management requirements 

already exist within your agency or elsewhere in the Federal Government?

4. Does the system employ electronic signatures?

A. If yes, have you correlated your risk assessment with recordkeeping requirements 

per NARA’s (1) Records Management Guidance for Agencies Implementing 

Electronic Signature Technologies, (2) Records Management Guidance for PKIUnique Administrative Records, and (3) Records Management Guidance For PKI 

Digital Signature Authenticated and Secured Transaction Records?

5. Has the records scheduling activity determined that there are permanent records in the 

system?
December 15, 2005 FEA Records Management Profile, Version 1.0 46

A. If yes, has the system designers/integrators consulted ERM E-Gov’s applicable, 

format-specific transfer requirements (available on the NARA web site) and 

incorporated those into system design and analysis?

6. Is there a web interface to this system?

A. Have you reviewed NARA’s Guidance on Managing Web Records?

7. What FEA TRM services, categories, standards and specifications are applicable to 

this acquisition?

4.6.4 DRM Questions

1. For those records in the system, have you determined what metadata to associate with the 

records?

2. Do the metadata meet the requirements expressed in Table C2.T3 and C2.T4 of the 

current DoD 5015.2-STD?

4.6.5 PRM Questions

1. How are the metrics defined in the OMB Exhibit 300 for this system acquisition?

2. Are the metrics process-improvement related or are the metrics records managementspecific?

A. If the metrics are records management-specific, have you reviewed the ERM EGov IAC White Paper on RMA metrics?

3. Do the records produced by this system or the system itself (as a record) already possess 

an existing NARA-approved disposition authority?

A. If yes, have you re-visited the applicable records schedule to account for changes 

in the process or format of the records?

B. If no, has your Records Officer initiated a records scheduling activity?

As shown through these examples, the RM Profile framework is a best practice reference for 

agencies to integrate records management principles, procedures, and requirements into agency 

business and information technology processes. When used as guidance for enterprise-wide 

acquisition planning, the RM Profile:

• promotes consistency in applying records management throughout the agency,

• reduces the need for stove-pipe systems and processes to perform records management,

• encourages re-use of systems and processes supporting records management,
December 15, 2005 FEA Records Management Profile, Version 1.0 47

• assures that records management requirements are met throughout the life cycle of all 

records, and

• minimizes implementation challenges usually faced when ad hoc or stand-alone systems are 

created to support records management.

The following chapter illustrates how agencies might apply these questions in a step-by-step 

scenario of a real Government business process. Whether the goal is to procure an RMA or to 

develop a CBA, the scenario shows how the RM Profile framework and resources can advise 

agency planning processes to ensure that records (and systems of records) are effectively 

managed from records creation or receipt through their ultimate disposition.
December 15, 2005 FEA Records Management Profile, Version 1.0 48

Chapter 5: Application of the RM Profile

The following three scenarios demonstrate hypothetical applications of some of the FEA 

reference model/records management-related questions discussed in Chapter 4. The first 

scenario is an RMA implementation. The second scenario relates to an agency enhancement of

an existing mission application by adding an RM component to it. The third scenario involves 

developing an RM component as part of a mission system where the organization already 

maintains an RMA. Included solely for illustration, these scenarios are not intended to be 

comprehensive in how agencies might implement the RM Profile.

As mentioned in the previous chapter, and illustrated below in Exhibit 5.0, there is a common 

thought process and navigation through the FEA reference models when approaching a records 

management acquisition, regardless of whether it is for an RMA or a records management 

component. 

Exhibit 5.0. Illustrative Navigation through the FEA Reference Models 

5.0 IMPLEMENTING A RECORDS MANAGEMENT APPLICATION

RMAs provide organizations with the capabilities to manage their records as required by law 

throughout their life cycle, that is, from their creation, to their maintenance and use, and then to 

their ultimate disposition (i.e., disposal or permanent preservation). This includes "locking 

down" documents so that they are unalterable and managing version control of specific 

documents. RMAs also include the functionality to store and destroy records at the appropriate 

time. RMAs often reduce the cost otherwise associated with operating multiple, disparate 

records management systems, including costs associated with administration, maintenance, and 

training.

BRM LOB and Sub -Function?

Search the SRM for applicable services and 

components, and component registries

RM services, functions, capabilities desired 

to support the BRM LOB?

DoD 5015.2 requirements?

Search the TRM for standards, technologies, 

applications (5015.2 certified), to support 

development, exposure or access to RM components

Use the DRM approach for RM data standards

 and appropriate metadata 

View the PRM to determine how 

performance measures should be 

defined/categorized
December 15, 2005 FEA Records Management Profile, Version 1.0 49

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

• manage records from desktop applications, where the electronic version of the record will be 

the recordkeeping copy;

• maintain electronic mail in an electronic format for recordkeeping purposes; 

• facilitate the transfer of permanent electronic mail records to the National Archives; and 

• collect, organize, and categorize records in a manner that facilitates their retrieval, use, 

disposition, and preservation.

5.0.1 Overview of the Scenario

The CIO of Agency A, working with the Records Officer, is acquiring an RMA to manage 

Agency records. They want all records within the Agency stored, tracked, maintained, secured, 

and accessible to appropriate customers as well as internal staff, and stored or disposed of in 

accordance with disposition instructions on approved agency records schedules. After reviewing 

NARA’s guidance for Coordinating the Evaluation of CPIC Proposals for ERM Applications,

14

the CIO decides to acquire an enterprise-wide RMA and maintain all records in one central 

repository.

Prior to initiating the acquisition and generating a business case, the CIO searches the Agency’s 

Enterprise Architecture and queries sub-agency program offices to determine whether any units 

within the organization are already using RMAs. They find that several program offices have

their own database repositories for maintaining records, but none are using RMAs or document 

management applications, which from many vendors contain additional functionality to perform 

records management.

5.0.2 Application of the RM Profile to the Scenario

5.0.2.1 Addressing BRM-Related Questions

This particular acquisition is for the primary purpose of records management, and therefore falls 

within the Record Retention Sub-function of the Information and Technology Management Line 

of Business within the Management of Government Resources Business Area. Since records 

management is the primary Line of Business, the CIO generates an ‘Agency Commitment MOU’ 

with the ERM E-Gov initiative 15 to assure alignment and adherence to the policies, guidance, and 

best practices generated by that initiative. The CIO and Records Officer determine that this 

acquisition is for an enterprise-wide RMA, which will result in a central repository for all 

Agency records, and policies and procedures for sub-agency offices to use.

Staff will not create records within the RMA – rather, records will be captured by the RMA via 

processes established to transfer records to the RMA from other applications where they are 

created. Records may be born-digital or scanned from existing hard copy records. The RMA 

will then manage all life cycle functions of a record for secure storage, access, and disposition. 

 

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

15 If the agency has not previously executed the MOU with the ERM Initiative. 
December 15, 2005 FEA Records Management Profile, Version 1.0 50

As part of the acquisition, the Agency intends to re-design and streamline its records 

management processes to take advantage of the RMA’s functionality. In performing this task,

the Agency considers existing standards such as the ISO Records Management Standard 15489-1

with which the RMA should comply. Also as part of the acquisition, the CIO and Records 

Officer intend to survey the Agency for all existing records and records management best 

practices currently employed.

5.0.2.2 Addressing SRM-Related Questions

To support the Line of Business to which this acquisition aligns, the intended system must have 

the capability to support records management requirements for the entire life cycle of records:

capturing a record, ensuring all required metadata is maintained with the record, securely storing 

a record, enabling secure access to a record by both customers and Agency staff, allowing for the 

sharing of records internally and externally, and disposing of a record in accordance with its 

approved disposition instructions (e.g., storage within the Agency and disposal, or transfer to 

NARA).

As an RMA, the system will provide the functionality of all service components currently 

identified within FEA SRM v1.0. They reside within the Records Management Service Type 

under the Digital Asset Services Domain, and include:

• Digital Rights Management – the set of capabilities that support the claim and ownership of 

intellectual property and artifacts of an organization.

• Document Classification – the set of capabilities that support the categorization of documents 

and artifacts, both electronic and physical.

• Document Retirement – the set of capabilities that support the termination or cancellation of 

documents and artifacts used by an organization and its stakeholders.

• Record Linking / Association – the set of capabilities that support the correlation between 

logical data and information sets.

The RMA will also provide additional RM capabilities that are not captured yet within the FEA 

SRM, such as those listed in Chapter 3 and defined in NARA’s Records Management Service 

Components (RMSC) Requirements Development Project Final Report.

(http://www.archives.gov/era/pdf/rmsc0305.pdf)

5.0.2.3 Addressing TRM-Related Questions

The CIO is aware that there are many RMAs available as commercial off-the-shelf (COTS) 

products on the market, and that it is advantageous to procure the COTS product as opposed to 

building an RMA in-house, as the alternatives and cost benefit analyses sections of the OMB 

Exhibit 300 will show. The alternatives analysis section also reflects the consideration of the 

various COTS products, and supports the selection of a DoD 5015.2-STD16 certified product that 

 

16 DoD 5015.2-STD is based on legal requirements that are applicable to all federa l agencies. Testing for 

compliance with the standard is conducted by the Joint Interoperability Test Command of the Defense Information 

Systems Agency. Those commercial-off-the-shelf records products which pass the certification test are placed on a 
December 15, 2005 FEA Records Management Profile, Version 1.0 51

satisfies critical records management requirements. The CIO mentions that while the TRM does 

not currently incorporate the DoD 5015.2-STD as an RM Service Requirement (under the Service 

Access and Delivery Service Area), the Agency does intend to employ a DoD 5015.2-STD 

certified RMA.

Additionally, the CIO will consult the ERM E-Gov’s ERM Guidance on Methodology for 

Determining Agency-unique Requirements to ascertain additional requirements for their RMA 

that extend beyond those required by DoD 5015.2-STD.

The RMA will maintain electronically-signed records. As part of this acquisition, the CIO’s staff 

will refer to NARA’s Records Management Guidance for Agencies Implementing Electronic 

Signature Technologies to ensure the RMA meets the requirements for preserving a record’s 

trustworthiness over time. The RMA will also house permanent records that will require transfer 

to NARA in accordance with the disposition instructions on the approved agency records 

schedule. Agency A should tailor the RMA as necessary to ensure the transfer of permanent 

records in a format specified by the ERM E-Gov Transfer Instructions for Permanent Electronic

Records.

Since the RMA will not be developed in-house, it is not necessary to identify all the standards 

and specifications associated with building the RMA, typically found within the Component 

Framework Service Area. Other TRM Service Areas, Service Categories, Standards and 

Specifications that are applicable to this RMA acquisition include:

• Service Access and Delivery. 

To support internal and external access to the RMA, by customers and Agency staff, the CIO 

specifies Web Browser specifications (e.g., Internet Explorer and/or Netscape) for accessing 

the RMA, and Internet and Intranet standards for delivering or sharing the RMA records. 

Since the Agency will make appropriate records accessible to the public, they do not intend 

to establish the requirement for a virtual private network. RMA records will be accessed 

and/or delivered via HTTP or HTTPS, depending on the security associated with the record.

• Service Platform and Infrastructure. 

The RMA will reside on an Application Server (within the Delivery Servers Service 

Category) dedicated to the RMA. The Agency will designate the RMA application server as 

an Enterprise Server (within the Hardware/Infrastructure Service Category), and will 

integrate it with an Oracle Database for its central repository of agency records. The Office 

of the CIO will maintain the RMA and employ Change Management (within the Software 

Configuration Management Service Category) to ensure configuration control. 

• Service Interface and Integration. 

The CIO and Records Officer want to be able to share records with other agencies and be 

able to transfer records to NARA when appropriate, so the Agency will specify XML as an 

Interoperability Standard to facilitate sharing of records. Since an RMA is a complete 

application and not separable as multiple components, and because it is a vendor product, 

 

formal Records Management Software Applications Product Register. A summary test report is also available on the 

register. The register is located at http://jitc.fhu.disa.mil/recmgt/.
December 15, 2005 FEA Records Management Profile, Version 1.0 52

there is no need for the Agency to consider publishing the RMA or its parts as a service 

within a service registry or directory, and hence, there is no need for a Service Interface.

5.0.2.4 Addressing DRM-Related Questions

Because it is DoD 5015.2-STD certified, the RMA will meet the minimum requirements for 

record metadata. Additionally, this acquisition will incorporate additional agency-unique 

metadata requirements as determined by the Agency.

5.0.2.5 Addressing PRM-Related Questions

The Records Officer initiated this acquisition to ensure:

• Proper records management for all Agency records,

• Efficient and timely access to records by Agency staff and customers, and

• Maintenance of the integrity and authenticity of Agency records.

To develop performance measures and metrics for this RMA acquisition and subsequent 

implementation, the Records Officer reviews the IAC’s White Paper on RMA metrics 

(http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf) in order to 

articulate common RMA performance measures. Performance measures are as follows:

• Mission and Business Results. 

Outcomes the Agency is seeking to achieve with the RMA: 

1. The number of FOIA requests processed per day increases by xx%.

• Customer Results. 

How well the Agency is serving its customers (internal and external) by employing the 

RMA:

1. Record search and retrieval capability results in record matches being returned within xx 

amount of time.

2. Customer satisfaction in retrieving Agency records improves by xx%.

• Processes and Activities. 

Outputs directly resulting from the RMA supporting records management:

1. Accuracy of record classification (filing) improves by xx%.

• Technology. 

Key performance elements directly associated with the RMA:

1. Record holding capacity of the RMA is xx number of records.

2. The response time for an RMA query or search is less than xx amount of time.

3. Access to records for both Agency staff and the public is available 7x24.

The agency already has NARA-approved disposition authorities for the records managed by the 

RMA. The Agency is re-visiting the records schedule as the RM processes are re-engineered 

with the implementation of the RMA. 
December 15, 2005 FEA Records Management Profile, Version 1.0 53

5.0.3 RMA Acquisition Approach

Due to the cost and complexity of the effort, it takes a significant amount of time to procure and 

implement an enterprise-wide RMA. Organizations seeking to acquire an RMA should consider 

the following approach, which suggests a proposed process upon which to base the acquisition 

decision. 

1. Establish and officially charter a project team with the requisite skills, including project, risk, 

security, requirements, communications and change management. The project team should 

assign a project manager with the appropriate responsibilities and authority. The project 

manager should lead the effort with development of the key planning documents.

2. Establish a baseline by surveying existing programs/offices within the organization to 

determine those that have established records management policies and procedures. 

At the same time, request that each program/office analyze their business processes to 

identify the records created, received, maintained/used, and dispositioned throughout the 

organization.

3. Identify assumptions, constraints, and risks, considering those that relate to funding, project 

schedules, and technical issues.

4. Identify records management requirements, including those relating to technical, security, 

end-user, legal, policy, budgetary, and other issues. Organizations can look to the series of 

questions relating to the FEA reference models to help them determine records management 

requirements (see Chapter 4 of this Profile).

5. Develop records schedules that adequately document agency business processes and describe 

the records with appropriate disposition instructions to support agency business needs. The 

records schedules should be written at a level of granularity appropriate for use with an 

RMA.

6. Identify and prioritize criteria to evaluate RMAs based on the constraints and requirements 

identified previously. 

7. Identify and select alternative RMAs for evaluation that comply with the baseline set of 

requirements set forth in DoD 5015-2-STD. 

8. Evaluate products and rank them in accordance with evaluation criteria. The evaluation 

should include an estimate of the organization-wide costs and benefits of each product. Also, 

if available, the evaluation should also include references from current users of the products 

within the agency or in other agencies.

9. Select an RMA that best satisfies the evaluation criteria.

10. Develop the business case to support the RMA investment and funding request. At this point 

in investment planning, the organization should be able to:
December 15, 2005 FEA Records Management Profile, Version 1.0 54

• justify an enterprise-wide investment in an RMA

• articulate the project management structure put in place to manage the effort

• describe the alternative RMAs considered and the results of this analysis (OMB requires 

analysis of three alternatives as part of the OMB Exhibit 300 requirements)

• identify the risks to the organization associated with the investment

• provide major milestones and total costs to deploy an RMA

• map the RMA to the organization’s enterprise architecture

• discuss security and privacy considerations associated with the investment.

11. Submit the business case (Exhibit 300) to OMB for funding, after ensuring the organization 

is not seeking funding for both enterprise-wide and program-specific RMAs.17

12. Plan and conduct a pilot project within the organization to test the RMA. Pilot planning 

should include identification of performance goals and metrics, to help evaluate the success 

of the pilot. Determine “Go/No Go” decision, based on the results of the pilot. 

13. Develop and implement a phased implementation plan for the RMA that focuses on the 

extensive change management effort that will be required.

 

5.1 INCORPORATING A RECORDS MANAGEMENT COMPONENT INTO A 

MISSION APPLICATION

This scenario, designed as a counterpoint to the preceding scenario, focuses on the use of 

RMSCs in automating records management functions, as opposed to the use of a 5015.2-STD 

certified RMA. It is speculative in that NARA is just now defining the requirements for RMSCs 

(as presented in Chapter 3), so there are no NARA endorsed RMSCs in existence yet for 

agencies to adopt. However, some RMA vendors, in aligning to the direction that the Federal 

Government is headed, are starting to define their applications in terms of components.

5.1.0 Overview of the Scenario

Agency B operates an information system that automates a permit adjudication process. This 

system, which is in the operations and maintenance phase of deployment, employs integrated 

scanning and workflow software. The Agency is in the process of transitioning to a componentbased deployment of applications in its enterprise architecture. The funding proposal for records 

management enhancement of the permit adjudication system will represent an initial foray into 

component-based application development.

 

17 See NARA’s Guidance for Coordinating the Evaluation of Capital Planning and Investment Control Proposals 

for ERM Applications (http://www.archives.gov/records-mgmt/policy/cpic-guidance.html)
December 15, 2005 FEA Records Management Profile, Version 1.0 55

5.1.1 Application of the RM Profile to the Scenario

5.1.1.1 Addressing BRM-Related Questions

Agency B submits an Exhibit 300 to OMB to enhance the permit adjudication system. The

primary Business Area, Line of Business, and Sub-function to which this acquisition applies are 

the Services for Citizens Business Area, the Homeland Security Line of Business and the Border 

and Transportation Security Sub-function.

Since the enhancement of the permit adjudication system incorporates records management

functionality, the ancillary Line of Business and Sub-function for this acquisition are the 

Information and Technology Management Line of Business and the Records Retention Subfunction under the Management of Government Resources Business Area.

After consulting ISO 15489-1, the Records Officer recommends modifications to the workflow 

to capture recordkeeping copies at various stages in the process (as opposed to a single, final 

step) to enhance the trustworthiness of the process. This recommendation will also necessitate 

modification of the records schedule associated with the system.

5.1.1.2 Addressing SRM-Related Questions

The Agency’s enterprise architect reviews the records management capabilities of the Digital 

Asset Services Domain in the CORE.gov registry maintained by the FEA PMO and discovers

requirements for RM service components at: http://www.archives.gov/era/pdf/rmsc0305.pdf as 

defined by the ERM E-Gov Initiative. While no actual code resides in the registry available for 

re-use, the Architect and Project Manager discuss with the Agency Records Officer to see which 

components would be most advantageous to develop and implement in the permit adjudication 

system. The first decision point is to determine which of the six potential RM service 

components to develop and deploy. The project team, in consultation with the Agency Records 

Officer, considers each component for potential inclusion. The thought process surrounding that 

activity is described below for each component.

• Capture Record component: The purpose of this component is to capture information with 

associated attributes in an electronic system.

This component is selected for development and deployment as a means of implementing the 

business decision to capture recordkeeping copies at various stages in the workflow of the 

permit adjudication process. 

• Assign Disposition component: This component uses an established disposition authority to 

assign the disposition schedule, item number, and disposition instructions to the record.

This component is not selected for development and deployment due to manner in which the 

records resulting from this system have been scheduled. Since the purpose of the system has 

been narrowly defined (i.e., permit application adjudication), all of the output of the system 

fall into a single series that has a uniform retention period (which can be encoded as metadata 

at the time of activation of the CAPTURE RECORD component).
December 15, 2005 FEA Records Management Profile, Version 1.0 56

• Categorize Record component: This component utilizes agency business rules to assign an 

appropriate descriptive label to the records in order to facilitate management in an electronic 

system.

This component is not selected for development and deployment because the current system 

already performs the categorization function.

• Ensure Authenticity component: This component ensures the acceptability of a record as 

genuine, based on its characteristics such as structure, content, and context.

This component is not selected for development and deployment because the current system 

already ensures the authenticity of the electronic information.

• Associate Record component: This component provides the capability to associate a record to 

one or more other records through a Record Association attribute.18

This component is selected to support the development of an ‘official case file’ associated 

with the adjudication of any individual permit application.

• Execute Disposition component: This component implements destruction, transfer, or 

continued retention of a record in accordance with the established disposition authority. 

After validation that the disposition action is valid, the component executes the disposition 

action and records the transaction.

This component is selected for development to provide consistent compliance with retention 

requirements as expressed in the approved records schedule.

Once the Agency selects the relevant components as appropriate to the system, the Agency 

Architect must determine how to deploy them, both in the context of the permit adjudication 

system upgrade under consideration, as well as in the larger context of the enterprise 

architecture. As such, considerations might include: 

• Does the deployment of these components have any potential wider applicability than the 

system at hand?

o If so, how can their development and deployment be leveraged/maximized?

o If leveraging of their deployment is deemed prudent, what constraints do existing 

legacy applications place on their development?

• Is it advisable to ensure a parallel recordkeeping capability (e.g., via a 5015.2-STD certified 

RMA) during the initial stages of a CBA EA deployment?

For submission of the OMB Exhibit 300, Agency B identifies SRM service components supplied 

by the permit adjudication system. Those service components applicable to records management 

 

18 This activity allows for the creation of a Case File by linking the records of the case file. It allows for the linking 

of a record that was used to create a redacted or declassified record in the record declassification process. It allows 

for the linking of a record used to create to response to an information request such as FOIA. Although outside the

scope of this work, it is anticipated that it might be used to associate the body of a record to its attachments.
December 15, 2005 FEA Records Management Profile, Version 1.0 57

that are incorporated in the system are all contained within the Digital Asset Services Domain

under the Records Management Service Type, namely the Document Classification and the 

Record Linking / Association Service Components. Future revisions of the SRM will likely 

include the RMSCs identified in Section 5.1.1.2.

5.1.1.3 Addressing TRM-Related Questions

Agency B’s search for existing RMSCs led to the realization that they would have to build the 

components in-house (and later register in CORE.gov so that other agencies will be able to take 

advantage of them). Given the existing Permit Adjudication System application framework, and 

consultation with system development contractors, the Agency decides on a .NET solution for 

building the RMSCs. 

To document the permit adjudication process, Agency B captures copies of long-term temporary 

records at various stages of the process. The Agency identified these recordkeeping copies after 

reviewing the existing records schedules and the proposed business process modifications 

developed as a result of the BRM-related analysis. Several points in the workflow process where 

recordkeeping copies are ‘set aside’ occur coincident with scanning actions. While permit 

adjudication records have been appraised as temporary, their retention for agency business is 

lengthy. As such, the Records Officer directs the project team to examine creation requirements

in Expanding Acceptable Transfer Requirements: Transfer Instructions for Existing Permanent 

Electronic Records: Scanned Images of Textual Records, so that the system will produce longterm temporary records that support agency business for as long as needed.

As listed below, the Agency identifies TRM Service Areas, Service Categories, Standards and 

Specifications for the RMSCs being developed.

• Service Access and Delivery. DoD 5015.2-STD, though not listed as a specification yet 

within the TRM, will fall under the Service Requirements Service Type and the 

Legislative/Compliance Standard.

• Component Framework. 

The business logic of the RMSCs will be developed according to the Visual Basic.NET 

Specification within the Platform Dependent Standard and Business Logic Service Type.

5.1.1.4 Addressing DRM-Related Questions

The Agency develops the RMSCs to meet DoD 5015.2-STD criteria, thus ensuring that 

minimum record metadata requirements are met. The Agency also identifies and adds additional 

agency-unique metadata.

5.1.1.5 Addressing PRM-Related Questions

As part of the acquisition strategy, the Agency develops performance metrics for the system.
December 15, 2005 FEA Records Management Profile, Version 1.0 58

As the system is not classified primarily as a recordkeeping system, and in light of the 

recommendations made in the Industry Advisory Council E-Government Shared Interest Group 

White Paper on The Use of Metrics in Electronic Records Management (ERM) Systems 

(http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf), the 

Agency chooses to cast system performance metrics in terms of distinct process-related 

improvements (e.g., reduction in time for permit application processing). 

The agency already has NARA-approved disposition authorities for the output records generated 

by the application adjudication system. The Records Officer evaluates all steps in the workflow 

to determine at which points in the workflow it is necessary to capture recordkeeping copies to 

provide accountability and document work processes. This records management performancerelated analysis will inform subsequent business and service component reference model-related 

questions.

5.2 DEVELOPING A MISSION APPLICATION WITH A RECORDS 

MANAGEMENT COMPONENT AND LINKING TO AN RMA

This scenario focuses on the use of RMSCs to incorporate records management functionality into 

an existing mission application in an effort to better integrate records management into mission 

processes. It also assumes that an agency-wide RMA already exists with a central repository for 

all agency records. The scenario is purely hypothetical and is applicable to any agency that 

would use a mission system as described below, or might apply this example to their real-world 

environment. 

5.2.0 Overview of the Scenario

Agency C wants to develop an information system to automate an identification (ID) card 

application process (e.g., an Agency ID, a driver’s license, or a library card). The following is a 

synopsis of the process and workflow: 

1. Application Acceptance Facility receives the application. First time applicants must 

appear in person to request an ID. Applicants may apply for ID renewals through the 

Agency’s web site. Application packages include a signed application form, proof of 

identity (e.g., driver’s license), and required fees.

2. Agency processes application and fees. Once received by the Acceptance Facility, staff 

process the fees and affix a bar code to the application, which is used as the primary 

identifier at every subsequent step in the process. Staff extract data from the application 

and enter the data into the Agency ID system for processing, tracking, and reporting.

3. Agency reviews application for eligibility. Staff perform manual and automated checks 

(e.g., name checks) on the application data to validate and verify the information. The 

Agency adjudicates the application and decides to grant or deny with notations captured 

on the application form and entered into the Agency ID system.
December 15, 2005 FEA Records Management Profile, Version 1.0 59

4. Agency issues (or denies) valid ID. The Agency mails the ID to the applicant if 

adjudication does not reveal any issues. If issues arise, the Agency informs the applicant 

that supplemental or clarifying information is needed. The application is then placed in 

suspense pending receipt of information. If the ID application is denied, the Agency 

informs applicants of their rights under the appeals process.

5. Agency files application case file in recordkeeping system. After staff complete all 

outstanding actions on the application, the Agency compiles the case file and forwards it 

to ID Services Division for filing. The paper case files are scanned into the Agency ID 

system along with the associated metadata about the application. The Agency maintains 

the validated images on optical disk.

5.2.1 Application of the RM Profile to the Scenario

5.2.1.1 Addressing BRM-Related Questions

Agency C submits an Exhibit 300 to OMB to develop the ID system. The primary Line of 

Business and Sub-function to which this acquisition corresponds is the Direct Services for 

Citizens Line of Business and the Civilian Operations Sub-function under the Mode of Delivery –

Government Service Delivery Business Area.

Since the development of the ID system incorporates records management functionality, an 

ancillary Line of Business and Sub-function for this acquisition is the Information and 

Technology Management Line of Business and the Records Retention Sub-function under the 

Management of Government Resources Business Area.

The Agency Records Officer reviews the current process and identifies the following Federal 

records: ID application, the final ID, and all associated supporting or clarifying documentation. 

Consulting ISO 15489-1, the Records Officer recommends modifications to the ID application 

workflow to capture recordkeeping copies at various stages in the process (as opposed to a 

single, final step) to enhance the trustworthiness of the process. This recommendation will also 

necessitate modification of the records schedule associated with the system.

Aside from capturing the recordkeeping copies, the ID system needs to interface with the 

Agency RMA. Once the application process is completed, the RMA will manage the ID system 

records in accordance with the approved records schedules. Because of the existence of and 

interface to the RMA, Agency C does not need to include this RM functionality in the ID system. 

5.2.1.2 Addressing SRM-Related Questions

The records management capabilities that need to be built into the ID workflow described above 

include a record capture capability and a record linking or association capability. When linked to 

the ID system, the RMA will handle other records management capabilities, such as record 

categorization.
December 15, 2005 FEA Records Management Profile, Version 1.0 60

Considering a component-based approach, Agency C’s Enterprise Architect reviews the 

CORE.gov web site maintained by OMB’s FEA Program Management Office to determine if 

there are existing RM components within the Registry. None have been identified to date. 

However, requirements for RMSCs, as defined by the ERM E-Gov Initiative, do exist within the 

Digital Asset Services Domain in the CORE.gov registry. The Architect and Project Manager 

coordinate with the Agency Records Officer to see which components would be most 

advantageous to develop and implement in the ID System.

Based on the existing records schedule and the proposed modifications from the BRM-related 

analysis, the Agency decides to capture long-term temporary records to document the ID card 

application process. Per the Records Management Service Components Requirements 

Development Project Final Report 19, the first decision point is to determine which of the six

potential components to develop and deploy. The project team, in consultation with the Agency 

Records Officer, considers each component for potential inclusion. The thought process 

surrounding that activity is described below for each identified component.

• Capture Record component: The purpose of this component is to capture information with 

associated attributes in an electronic system. 

This component is selected for development and deployment as a means of implementing the 

business decision to capture recordkeeping copies at various stages in the workflow of the ID 

application adjudication process. 

• Assign Disposition component: This component uses an established disposition authority to 

assign the disposition schedule, item number, and disposition instructions to the record.

This component is not selected for development and deployment due to the manner in which 

the records resulting from this system have been scheduled. Since the purpose of the system 

has been narrowly defined (i.e., ID application adjudication), all of the output of the system 

fall into a single series with a uniform retention period (which can be encoded as metadata at 

the time of activation of the CAPTURE RECORD component).

• Categorize Record component: This component utilizes agency business rules to assign an

appropriate descriptive label to the records in order to facilitate management in an electronic 

system.

This component is not selected for development and deployment because categorization of 

the records will be determined by the RMA at the time the ID System passes the record to the 

RMA. The interface between the RMA and the ID System will handle this function.

• Ensure Authenticity component: This component ensures the acceptability of a record as 

genuine, based on its characteristics such as structure, content, and context.

This component is not selected for development and deployment because the Agency RMA 

already ensures the authenticity of the electronic information. The ID System needs to pass 

 

19 http://www.archives.gov/era/pdf/rmsc0305.pdf
December 15, 2005 FEA Records Management Profile, Version 1.0 61

the characteristics of the record to the RMA, but the RMA is responsible for ensuring 

authenticity of a record once the characteristics are established.

• Associate Record component: This component provides the capability to associate a record to 

one or more other records through a Record Association attribute.

This component is selected to allow for the development of an “official case file” associated 

with the adjudication of any individual ID card application.

• Execute Disposition component: This component implements destruction, transfer, or 

continued retention of a record in accordance with the NARA-approved disposition authority. 

After verifying that the disposition action is valid, the component executes the disposition 

action and records the transaction.

This component is not selected for development because the Agency RMA already performs 

the execute disposition function.

Once Agency C selects the relevant components for the system, the Agency Architect should 

consider the larger context of the records management component(s) deployment within the 

Agency enterprise architecture, including the potential use by other agency systems. As such,

considerations might include: 

• Does the deployment of these components have any potential wider applicability than the 

system at hand?

o If so, how can their development and deployment be leveraged/maximized?

o If leveraging of their deployment is deemed prudent, what constraints do existing 

legacy applications place on their development?

For submission of the OMB Exhibit 300, Agency C identifies all SRM service components 

supporting the ID system; however, only those related to the RM service components are 

presented here. The service components applicable to records management that are being 

developed as part of the ID System are all contained within the Digital Asset Services Domain

under the Records Management Service Type, namely the Document Classification and the 

Record Linking / Association Service Components. Future revisions of the SRM will likely 

include the RMSCs as identified in Section 5.2.1.2.

5.2.1.3 Addressing TRM-Related Questions

Agency C will have to present the technologies for the entire ID system, but the TRM discussion 

here relates only to technologies related to implementing the RM functionality. 

After searching for existing RMSCs, Agency C concludes that they will have to build the 

components in-house (and later register them in CORE.gov so that other agencies will be able to 

take advantage of them). Given the existing ID system application framework, the Agency 

RMA, and consultation with system development contractors, Agency C decides on a .NET 

solution for building the RMSCs. It will also be necessary to establish the record’s structural 
December 15, 2005 FEA Records Management Profile, Version 1.0 62

characteristics and metadata for interfacing to the RMA to ensure that the components meet 

applicable DoD 5015.2-STD criteria.

The records schedule revision activity identifies several points in the process workflow where 

recordkeeping copies are “set aside” (e.g., during the scanning process). While ID application 

adjudication records have been appraised as temporary, their retention for Agency business is 

lengthy. As such, the Records Officer directs the project team to examine creation requirements 

in Expanding Acceptable Transfer Requirements: Transfer Instructions for Existing Permanent 

Electronic Records: Scanned Images of Textual Records so that the system will produce longterm, temporary records capable of supporting Agency business needs over time.

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

development include:

• Service Access and Delivery. 

DoD 5015.2-STD, though not listed as a specification yet within the TRM, will fall under the 

Service Requirements Service Type and the Legislative/Compliance Standard. Also, the 

Intranet Standard is identified as the Delivery Channel for the communication between the 

ID System and the RMA, and the https Specification identified as the Service Transport 

Standard for records exchanged between the ID system and the RMA.

• Component Framework. 

The business logic of the RMSCs will be developed according to the Visual Basic.NET 

Specification within the Platform Dependent Standard and Business Logic Service Type.

• Service Interface and Integration. 

The ID system and the RMA will communicate with each other for record passing using a 

Middleware Standard (within the Integration Service Type), and specifically, an Object 

Request Broker Specification has been selected. The XML Specification will be the Data 

Format/Classification Standard, and the XML Schema Specification will be the Data 

Types/Validation Standard for ensuring that the ID system and the RMA both understand the 

record characteristics and metadata being passed. 

5.2.1.4 Addressing DRM-Related Questions

The Agency develops the RMSCs to meet DoD 5015.2-STD criteria, thus ensuring that 

minimum record metadata requirements are met. The Agency also identifies and adds additional 

agency-unique metadata.

5.2.1.5 Addressing PRM-Related Questions

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

As the system is not classified primarily as a recordkeeping system, and in light of the 

recommendations made in the Industry Advisory Council E-Government Shared Interest Group 

White Paper on The Use of Metrics in Electronic Records Management (ERM) Systems 
December 15, 2005 FEA Records Management Profile, Version 1.0 63

(http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf), the 

Agency chooses to cast system performance metrics in terms of distinct process-related 

improvements (e.g., reduction in time for ID application processing). 

The agency already has NARA-approved disposition authorities for the output records generated 

by the application adjudication system. The Records Officer has carefully evaluated all steps in 

the workflow to determine at which points in the workflow it is necessary to capture 

recordkeeping copies in order to provide accountability and document work processes. This 

records management performance-related analysis will inform subsequent business and service 

component reference model-related questions. 
December 15, 2005 FEA Records Management Profile, Version 1.0 64

 Chapter 6: Next Steps

The Records Management Profile is a work in progress that will continue to evolve as more 

records management resources are identified and the technologies supporting the FEA mature. 

During the review process of this document, several agencies and industry groups provided 

recommendations on preliminary next steps for Fiscal Year 2006. Though these actions have not 

been reviewed or approved by the AIC, they do provide an indication as to where future work on 

the RM Profile might lead.

• Explore the 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.
December 15, 2005 FEA Records Management Profile, Version 1.0 65

Appendix A: Selected Resources

FEA Reference Models

Federal Enterprise Architecture Program Management Office, “FEA Consolidated Reference 

Model Document ” ( May 2005). Available at:

http://www.whitehouse.gov/omb/egov/documents/CRM.PDF

General 

Electronic Records Policy Working Group, “Barriers to the Effective Management of 

Government Information on the Internet and Other Electronic Records: A Report to the 

Interagency Committee on Government Information” (June 28, 2004). Available at: 

http://www.cio.gov/documents/ICGI/ERPWG_Barriers.pdf

Electronic Records Policy Working Group, “Recommendations for the Effective Management of 

Government Information on the Internet and Other Electronic Records: A Report to the 

Interagency Committee on Government Information” (December 16, 2004). Available at: 

http://www.cio.gov/documents/ICGI/ICGI-207e-report.pdf

Federal Enterprise Architecture Program Management Office, “The FEA Security and Privacy 

Profile Phase I Final: A Foundation for Government-wide Improvement ” (July 29, 2004). 

Available at:

http://www.cio.gov/documents/FEA%20Security%20Profile%20Phase%20IFINAL07-29-04.doc

National Archives and Records Administration, “NARA's Strategic Directions for Federal 

Records Management” (July 31, 2003). Available at:

http://www.archives.gov/records-mgmt/initiatives/strategic-directions.html

BRM Resources

International Standards Organization (ISO). ISO 15489-1: Information and Documentation –

Records Management (2001). Available at: (http://www.niso.org/international/index.html and 

http://webstore.ansi.org/ansidocstore/default.asp. In addition, agencies may obtain a discount on 

standards available through GSA Advantage 

(https://www.gsaadvantage.gov/advgsa/advantage/main/start_page.do)

National Archives and Records Administration, “Guidance for Coordinating the Evaluation of 

Capital Planning and Investment Control (CPIC) Proposals for ERM Applications” (June 2003). 

Available at: http://www.archives.gov/records-mgmt/policy/cpic-guidance.html

National Archives and Records Administration, “Guidance for Managing Web Records” 

(January 2005). Available at: http://www.archives.gov/records-mgmt/policy/managing-webrecords.html
December 15, 2005 FEA Records Management Profile, Version 1.0 66

National Archives and Records Administration, “Guidance on Methodology for Determining 

Agency-unique Requirements” (August 2004). Available at: http://www.archives.gov/recordsmgmt/policy/requirements-guidance.html

Office of Management and Budget. Circular A-130, Revised, (Transmittal Memorandum No. 4), 

Management of Federal Information Resources (11/28/2000). Available at: 

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

SRM Resources

Architecture and Infrastructure Committee, Federal Chief Information Officers Council, 

“Component-Based Architectures,” Version 2.0 (June 2004). Available at:

http://cio.gov/documents/CIOC_AIC_Service%20Component%20Based%20Architectures%20_

2.0_FINAL.pdf

National Archives and Records Administration, “Records Management Service Components 

Requirement Development Project,” Final Report (March 31, 2005). Available at: 

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

TRM Resources

Department of Defense, “STD-5015.2: Design Criteria Standard for Electronic Records 

Management Software Applications” (June 19, 2002). Available at: 

http://jitc.fhu.disa.mil/recmgt/standards.html

National Archives and Records Administration, “Records Management Guidance for Agencies 

Implementing Electronic Signature Technologies” (October 18, 2000). Available at: 

http://www.archives.gov/records-mgmt/policy/electronic-signature-technology.html

National Archives and Records Administration, “Records Management Guidance for PKI Digital 

Signature Authenticated and Secured Transaction Records,” (March 28, 2005). Available at: 

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

National Archives and Records Administration, “Records Management Guidance for PKIUnique Administrative Records,” (March 14, 2003). Available at: 

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

National Archives and Records Administration, “Transfer Instructions for Permanent Electronic 

Records” [Six format-specific products issued between September 2002-September 2004]. 

Available at:

http://www.archives.gov/records-mgmt/initiatives/erm-products.html
December 15, 2005 FEA Records Management Profile, Version 1.0 67

DRM Resources

Department of Defense, “STD-5015.2: Design Criteria Standard for Electronic Records 

Management Software Applications (Minimum Metadata Profile),” (June 19, 2002). Available 

at: http://jitc.fhu.disa.mil/recmgt/standards.html

PRM Resources

Industry Advisory Council, “The Use of Metrics in Electronic Records Management (ERM) 

Systems (White Paper),” (August 2004). Available at:

http://www.actgov.org/actiac/documents/sigs/egov/08032004ERMMetricsFinal.pdf
December 15, 2005 FEA Records Management Profile, Version 1.0 68

Appendix B: Glossary

Business Reference Model (BRM): a function-driven framework to describe the Lines of 

Business and internal functions performed by the Federal Government independent of the 

agencies that perform them. Agencies’ major IT investments are mapped to the BRM to identify 

collaboration opportunities.

Capital Planning and Investment Control (CPIC): a decision-making process for ensuring that 

IT investments integrate strategic planning, budgeting, procurement, and the management of IT 

in support of agency missions and business needs.

Component: a self-contained process, service, or IT capability with pre-determined functionality 

that may be exposed through a business or technology interface. 

Component-based Architecture: an enterprise architecture based upon categorizing business, 

service, performance, technical, and data entities, at their lowest level, as components, then 

recognizing larger lines of business, service, and technology infrastructures as combinations of 

components, enabling the design of enterprise solutions using pre-manufactured components.

Data Reference Model (DRM): describes, at an aggregate level, the data and information that 

support government program and business line operations. The DRM enables agencies to 

describe the types of interaction and exchanges that occur between the Federal Government and 

citizens. The DRM categorizes government information into greater levels of detail. It also 

establishes a classification for Federal data and identifies duplicative data resources. 

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

Agency business.

Electronic records: include numeric, graphic, and text information, which may be recorded on 

any medium capable of being read by a computer and which satisfy the definition of a record. 

This includes, but is not limited to, magnetic media, such as tapes and disks, and optical disks. 

Unless otherwise noted, these requirements apply to all electronic information systems, whether 

on microcomputers, minicomputers, or mainframe computers, regardless of storage media, in 

network or stand-alone configurations (36 CFR 1234.1).

Federal Enterprise Architecture (FEA): a framework for describing the relationship between 

business functions and the technologies and information that support them. Agencies’ major IT 

investments are aligned against each reference model within the FEA framework.

Information: any communication or representation of knowledge such as facts, data, or opinions 

in any medium or form, including textual, numerical, graphic, cartographic, narrative, or 

audiovisual forms.

Information system: a discrete set of information resources organized for the collection, 

processing, maintenance, transmission, and dissemination of information, in accordance with 

defined procedures, whether automated or manual. An electronic information system is a system 
December 15, 2005 FEA Records Management Profile, Version 1.0 69

that contains and provides access to computerized Federal records and other information (36 

CFR 1234.2).

Metadata: are data describing stored data, that is, data describing the structure, content, and 

context, and other characteristics of electronic records.

Performance Reference Model (PRM): a standardized performance measurement framework to 

characterize performance in a common manner where necessary. The PRM will help agencies 

produce enhanced performance information; improve the alignment and better articulate the 

contribution of inputs, such as technology, to outputs and outcomes; and identify improvement 

opportunities that span traditional organizational boundaries.

Public Key Infrastructure (PKI): a set of policies, processes, server platforms, software and 

workstations used for the purpose of administering certificates and public-private key pairs, 

including the ability to issue, maintain, and revoke public key certificates.

Records: all books, papers, maps, photographs, machine readable materials, or other 

documentary materials, regardless of physical form or characteristics, made or received by an 

agency of the United States Government under Federal law or in connection with the transaction 

of public business and preserved or appropriate for preservation by that agency or its legitimate 

successor as evidence of the organization, functions, policies, decisions, procedures, operations, 

or other activities of the Government or because of the informational value of data in them. 

Library or museum material made or acquired and preserved solely for reference or exhibition 

purposes, extra copies of documents preserved only for convenience of reference, and stocks of 

publications and of processed documents are not included (44 USC 3301).

Records management: the field of management responsible for the systematic control of the 

creation, maintenance, use, and disposition of records." From the Federal perspective, it is the 

planning, controlling, directing, organizing, training, promoting, and other managerial activities 

involved in records creation, maintenance and use, and disposition in order to achieve adequate 

and proper documentation of the policies and transactions of the Federal Government and 

effective and economical management of agency operations (44 USC 2901).

Records Management Application (RMA): software used by an organization to manage its 

records. An RMA's primary management functions are categorizing and locating records and 

identifying records that are due for disposition. RMA software also stores, retrieves, and 

disposes of the electronic records that are stored in its repository.

Records Management Service Component (RMSC): a piece of software that provides services 

that support the creation, management, transfer, and destruction of electronic records within a 

computing environment.

Recordkeeping requirements: all statements in statutes, regulations, and agency directives or 

authoritative issuances, that provide general and specific requirements for Federal agency 

personnel on particular records to be created and maintained by the agency (36 CFR 1220.14). 

Agencies may also identify recordkeeping requirements in their business and systems processes 
December 15, 2005 FEA Records Management Profile, Version 1.0 70

that are not mandated by laws or regulations, but are equally valid. Recordkeeping requirements 

should be outlined in procedural manuals and other issuances that specify which records need to 

be included in agency files or other recordkeeping systems.

Records Schedule: provides mandatory instructions for what to do with records (and nonrecord 

materials) no longer needed for current Government business. Also retention schedule, 

disposition schedule, records control schedule.

Service Component Reference Model (SRM): provides a common framework and vocabulary 

for characterizing the IT and business components that collectively comprise an IT investment. 

The SRM will help agencies rapidly assemble IT solutions through the sharing and re-use of 

business and IT components. 

Service-Oriented Architecture (SOA): defines how two computing entities interact in such a 

way as to enable one entity to perform a unit of work on behalf of another entity. The unit of 

work is referred to as a service, and the service interactions are defined using a description 

language.

Technical Reference Model (TRM): provides a foundation to describe the standards, 

specifications, and technologies supporting the delivery, exchange, and construction of business 

(or Service) components and E-Gov solutions. The TRM unifies existing agency TRMs and 

electronic Government (E-Gov) guidance by providing a foundation to advance the re-use of 

technology and component services from a Government-wide perspective.
December 15, 2005 FEA Records Management Profile, Version 1.0 71

Appendix C: List of Exhibits

No. Title Page

2.0 Records Life Cycle 8

3.0 Viewing Records Management through the FEA 13

3.1 Business Reference Model 14

3.2 Service Component Reference Model 19

3.3 Records Management Activities Supportable by Service 

Components

21

3.4 Technical Reference Model 23

3.5 Data Reference Model Structure 27

3.6 Data Reference Model “Categorization of Data” Area 28

3.7 Information Exchange Package 29

3.8 Data Reference Model “Structure of Data” Area 29

3.9 Performance Reference Model 31

3.10 Sample Use of PRM to Identify Measurement Indicators 32

3.11 Illustration of the FEA Integrated with Records Management 33

4.0 Records Management Integration into the SDLC 36

4.1 Illustration of the Utility of Component Based Architectures 41

4.2 Records Management Component Discovery 42

4.3 FEA Reference Model Order when Considering an IT Investment 43

5.0 Illustrative Navigation through the FEA Reference Models 48
December 15, 2005 FEA Records Management Profile, Version 1.0 72

Appendix D: List of Acronyms

AIC Architecture and Infrastructure Committee

BRM Business Reference Model

CBA Component-Based Architecture

CCB Configuration Control Board

CFR Code of Federal Regulations

CIO Chief Information Officer

COI Community of Interest

COTS Commercial Off-the-Shelf

CPIC Capital Planning and Investment Control

DoD Department of Defense

DRM Data Reference Model

EA Enterprise Architecture

ERM Electronic Records Management

ERPWG Electronic Records Policy Working Group

FEA Federal Enterprise Architecture

FEA PMO Federal Enterprise Architecture Program Management Office

GC General Counsel

GPEA Government Paperwork and Elimination Act

GSA General Services Administration

HTTP Hypertext Transfer Protocol

IAC Industry Advisory Council

ICGI Interagency Committee on Government Information

IRM Information Resources Management

ISO International Standards Organization

IT Information Technology

MOU Memorandum of Understanding

NARA National Archives and Records Administration

OMB Office of Management and Budget

PKI Public Key Infrastructure

PRM Performance Reference Model

RM Records Management

RMA Records Management Application

RMO Records Management Officer. Also Records Officer.

RMSC Records Management Service Component(s)

SDLC Systems Development Life Cycle

SOA Service-Oriented Architecture

SRM Service Component Reference Model

TRM Technical Reference Model

USC United States Code

WSDL Web Services Description Language

XML eXtensible Markup Language