Daryll Prescott

1
Daryll Prescott

• DoD 5015.2
• and
• Records Management Services

2
What is an Application?

• Software usually divided into two classes,
  systems software and applications software.
• Systems software are low-level programs that
  interact with the computer at a very basic level
  including operating systems and utilities for
  managing computer resources.
• Applications (sometimes called end-user programs)
  include database programs, word processors,
  spreadsheets, etc.

3
What is an Application?

• Application software sits on top of systems
  software. Application software cannot run without
  an operating system and system utilities

4
Records Management Application

• Stand alone product
• The application through which a record is
  captured is different than the application used
  to generate it.
• Users must learn yet another application.
• The use of the application must be inserted in
  uncountable places in the business process

5
Records Management Application

• 1990s
• No RMA vendors existed
• Document management
• Application workflow integration into business
  process
• First RMAs were conglomerate companies
• Todays best RMAs are built by single companies

6
1996 - 2002
JITC Testing Starts
RMTF
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2004
2008
DoD 5015.2 1997(v1) 2002(v2) 2007(v3)
ASD(C3I))
(ASD(C3I)) DoD CIO
7
Records Management
Value Span With most RMA
8
Records Management Value Tomorrow
9
Service Oriented Architecture

• Provides methods for systems development and
  integration where grouped around business
  processes
• Use interoperable services.
• SOA allows different applications to exchange
  data with one another while participating in
  business processes.
• Developers can combine and reuse services in the
  production of business applications.

10
Services You Know already

• Basic Operating System services
• System clock and date
• Cursor movement and functions
• Display
• Clipboard
• Print
• Keyboard
• Common requirements met through central services
• This is the target for Records Management Services

11
RMS Interagency Project Team
12
Participant Requirements

• Must have letter of authority
• Speak on behalf of the agency
• Vote for the agency
• Authorize the publication of documents with
  agency logo

13

• 2004 RMS Program Office
• 2005 Jan Mar 2005
• 18 Contributing Agencies meet for six
• sessions to initiate requirements development

14
Functional Requirement and Attributes for Records
Management in a Component Based Architecture

• July 2005

2004
2005
2006
2008
2009
2010
2007
15
Dec 2005 U.S. Govt Adopts Requirements and
Attributes
16
RMS Program Office
Mar through Jun 2006 1. Records Capture Service
Modified Annotate 2. Case File Service Case
File Part
17
Interagency Project Team

• Reorganizes
• Community of Interest
• Updates Requirements

18
Managed Record
Disposition
Management Attributes gtgt the ltlt collection
of activities over its life-cycle until dispositio
n
Managed Record
Agency determines what data about the record are
kept for the destruction or transfer record
Document Set Aside

Record
19
The Identified RM Services

• Record Capture
• Provenance (establish, history, Recordkeeper
  establish, history)
• Category (establish, history)
• Authenticity (establish, validate, update)
• Case File (capture part, part history)
• Disposition (establish, history, suspension, and
  revocation of suspension)
• Reference (associate disassociate)

20
Provenance
Agency Policy
Agency Policy
Agency Policy
Agency
Agency
Agency
Required
Sub-Agency
Individual
Individual
Individual
Provenance Attributes
ProvenanceAgency ProvenanceSub-Agency ProvenanceIn
dividual
ProvenanceAgency ProvenanceIndividual
ProvenanceAgency
21
ProvenanceCoast Guard from Dot to DHS
DHS (Migrated DoT)
DHS New
DoT
AgencyCurrent
AgencyCurrent
AgencyCurrent
AgencyCurrentDate
AgencyCurrentDate
AgencyCurrentDate
RecordKeeperCurrent
RecordKeeperCurrent
RecordKeeperCurrent
RecordKeeperCurrentDate
RecordKeeperCurrentDate
RecordKeeperCurrentDate
AgencyPrevious
AgencyPreviousDate
22

• Object Management Group is a computer industry
  consortium that defines and develops software
  standards
• RMS standards are being developed through OMGs
  Government Domain Task Force, with submission to
  OMG for publication in March 2009, Washington DC.

23
Object Management Group

• Computer Independent Model Sept 2006 Functional
  Requirements U.S. Govt IPT
• Platform Independent Model (PIM) June 2006
  February 2009
• Model can be ported to any language solution
• Model can be ported to any other standard such as
  5015.2, MoReq, Dublin Core, etc.
• Platform Specific Model (PSM) shows actual
  working solution Web Service Definition
  Language (WSDL) February 2009

24
PIM to PSM Tools

• C, C, JAVA, Delphi, VB.net, WDSL, Visual
  Basic, Action Script, Personal Home Page (open
  source), XML (XML Schema Definition), Common
  Object Request Broker Architecture (CORBA by
  OMG), Interface Definition Language (OMG), allows
  automated engineering reverse engineering
  facilities
• Sparx EA
• Rational Environment (IBM)
• MagicDraw

25
Object Management Group
Functional Requirements September 2006
Computer Independent Model
Platform Independent Model

• Unified
• Modeling
• Language
• Relationship and cardinality
• State diagrams
• Sequence diagrams
• Also scenarios

NAME YOUR FLAVOR Current RFP WDSL But Others
JAVA, XML, C
Platform Specific Model
26
Object Management Group

• Changes in requirements
• Reflected in the Platform Independent Model (PIM)
• Tools regenerate code in whatever solution vendor
  is providing, WSDL, JAVA, etc.
• Updates come out of a OMG Finalization Task Force
  maintaining OMG standard
• No solutions? OMG drops standard

27
OMG GovDTF

• Working RMS standard since June 2006
• March 2009 publishes RMS standard (?)
• Moves RMS into OMG Finalization Task Force
• Vendors start developing products (they already
  have)
• RFP II issued for other platform solutionsJAVA,
  C

28
OMG Process

• Requires letters of intent to build before
  standard can be published
• 88 Solutions
• Model Drive Solutions (formerly Data Access
  Technologies)
• CA (formerly Computer Associates)
• IBM
• CSC
• Visumpoint
• Lockheed Martin

29
RMS is a Reality

• Object Management Group http//omg.org/
• Government Domain Task Force http//omg.org/
• Records Management Service Program Office
• http//www.archives.gov/era/rms/

30
Government Domain Task Force

• Records Management Services standard
• Records Management Maturity Model
• Federal Segment Architecture for the FEA
• Model Based Acquisition
• Federal Transition Framework FTF

31
Questions
Daryll Prescott drp_at_tethersend.com
32

• BMMN Business Process Modeling Notation

33
Records Management Putting Records First
Records Management Profile RMS Requirements
into CORE.gov
OMG Industry Standard Industry Interest Model
Drive Architecture for the FEA
Regulated Industry Examples
FDA Guidance for Industry, 2003 (Electronic
Records Electronic Signatures Scope and
Application) Sarbanes-Oxley Act of 2002 Health
Insurance Portability and Accountability Act of
1996 Occupational Safety and Health Act of
1970 (3245-09R, Recordkeepeing Handbook) Rule
2-06, Securities Exchange Act of 1934 (Retention
of Records Relevant to Audits and Reviews)
34
Putting Records First Records Management
Services Records Management Service Components
Program Electronic Records Archives
Program National Archives and Records
Administration Daryll Prescott Program Director

May 31, 2006
35
Overview

• Two revolutionizing activities
• Implementing lifecycle of electronic records
  management
• Records management through software services
• Overview the Records Management Service
  Components (RMSC) Requirements Development
  Project
• Identify current and future activities of the
  Program Office

36
Where Records Management (usually) comes in
37
Where we want Records Management to come in
38
RMSRequirements Development Project

• Records Management Services (RMS)

• What is an RMS?
• Software-based services that support the
  creation, management, transfer, and destruction
  of electronic records within a computing
  environment.

39
RMSRequirements Development Project

• Records Management Services (RMS)
• Initial Operating Concepts
• Front end of the business process
• Compliant with FEA
• Compatible with RMAs and the ERA
• Captures context of creation and relationship to
  other records at the point of creation
• Information about the record is carried forward
  through the lifecycle
• Establishes a baseline against which authenticity
  can be validated over time

40
RMSRequirements Development Project

• Objectives
• To facilitate the acquisition of RMS that provide
  interoperable RM functionality in any agency
  system that creates/manages electronic records
  by
• Identifying, documenting, normalizing, and
  socializing those core RM stakeholder
  requirements that services can support
• Aligning with the OMBs FEA reference models,
  profiles, and component registry program CORE.gov
• Leveraging industry interest in the RMS business
  case through the Object Management Group (OMG)

41
RMSRequirements Development Project

• Collaboration
• 18 Federal agencies
• nine IT vendors and two universities
• 11 NARA subject matter experts representing four
  offices
• Use state-of-the-art collaborative technology
• Offsite meetings led by experienced facilitators

42
RMS Participating Experts

• Over 30 experts in records management, enterprise
  architecture, e-Government, Privacy Act, FOIA,
  c.
• Departmental Records Officers
• Deputy Chief Information Officers
• Senior E-Government Architect
• Chief, FOIA Privacy Branch
• Director, Policy and Planning
• Division Chief, Directives Records
• Electronic Records Management Lead
• Chief, Life Cycle Management Branch
• Senior Records Analysts

43
RMSScope and Constraints

• View Point
• Records Management Activities
• Return on Investment Constraint
• RM activities used the most often
• RM activities used by government
  employees/business processes
• In Scope
• From Receipt, Identification, Declaration of a
  record
• To Disposition of a record
• Out of Scope
• Document creation (what makes up a
  document/record and how, who, and why it was
  created)
• Security, privacy, etc.
• Systems maintenance
• How it is stored and what it is stored on
  storage media
• Format e.g. .doc, PDF, TIFF
• System management backup and recovery

44
RMSRequirements Development Project- Results-
Requirements Development Project Final Report
March 31, 2005

• Identified defined eight RMSC components
• 21 functional requirements
• 33 RMSC attributes
• Prioritized RMSCs for acquisition

45
Making the Transition to TomorrowUse Case
Development

• Interagency Project Team, NARA experts,
• RMS Program Office
• Additional collaborative facilitated sessions
• NARA solicited industry comment via an RFI and
  
• provided responses back to the IPT
• NARA internal review provided comments to IPT
• IPT Nov Dec 2005 addressed RFI and NARA
• comments

46
Making the Transition to TomorrowUse Case
Development

• Bridge from business to developer communities
• Widely accepted technical engineering notation
• Documents purpose, conditions, flows,
• attributes, and functional requirements
• Normalizes granularity of components

47
Making the Transition to TomorrowInteragency
Project Team RMS Report

• IPT disposition of
• industry RFI comments
• IPT disposition of NARA
• comments
• Changed viewpoint to
• services not
• components
• Functional Requirements
• and Attributes
• IDEF0 and Unified
• Modeling Language views
• Ready for next steps

48
Making the Transition to TomorrowInteragency
Project Team RMS Report

• Seven RM services across the record life cycle

• Case File
• Disposition
• Reference

• Record Capture
• Provenance
• Category
• Authenticity

• Reliability

49
RM Services and the Record Life Cycle
Temporary/Permanent Records
Unscheduled Records
Record Capture Authenticity Provenance Category Ca
se File
Reference
Disposition
50
Making the Transition to TomorrowPutting
Records First

• Benefits of RMS
• Allows the management of records to begin much
  earlier in the business process
• Can be built into agencys enterprise
  architecture
• From users perspective, RMS are minimally
  intrusive, and often transparent
• Provide a hook to downstream management tools
  such as the NARA Electronic Records Archive (ERA)
  system

51
Making the Transition to TomorrowNext Steps at
NARA

• Internal work group, led by Deputy Archivist, to
• Review the RMS report, attributes, and models and
  determine its relationship to current
• NARA ERM policies existing external RM
  standards
• NARA guidance on RM acquisition options

52
Making the Transition to TomorrowLeveraging
Industry Interest in RMS

• Object Management Group and the RM
• Unified Modeling Language
• Model Driven Architecture
• XML Meta-data Interchange
• Common Object Request Broker
• Architecture Common
• Warehouse Metamodel
• Meta-Object Facility

Each logo is trademark and owned by the Object
Management Group used by permission.
53
Making the Transition to TomorrowLeveraging
Industry Interest in RMS

• Open member non-profit organization
• Task Force operates in the interest areas
  declared in their
• charter
• Government Special Interest Group created 2005
• RM RFP proposed March 2006, 11 federal
  agencies and
• 13 members of OMG in attendance
• GovSIG upgraded to Government Task Force April
  2006
• GovTF votes to publish RFP on RMS April 2006
• European Business Rules June 2006
• GovTF meets in Boston to publish RFP June 2006
• GovTF deadline for responses and sponsors
  September 2006
• RFP published as OMG Standard March 2006?

54
Why is this important to you?

• All records are documents not all documents
  are records Knowing the difference makes all
  the difference
• Your Stuff can be scheduled and destroyed or
  transferred legally and legitimately
• Reduced electronic holdings
• Increases system efficiencies
• Reduces system disaster recovery time
• Reduces media requirements (aerial density
  factor loss)
• Supports regulatory and litigation requirements

55
Why is this important to you?

• Today, we are all records managers
• Applying RM early provides efficiencies
• MDA can support the identification of RM
• Identifies business transaction evidence
• Identifies points of records creation
• Identifies where, when and how RM can be applied
  within an agency
• architecture, or
• system environment
• Allows RM to be included in business solutions

56
Questions?
Daryll R. Prescott Program Director RMSC Program
Office daryll.prescott_at_nara.gov 301-837-0974
Ken Hawkins RMSC Project Manager ERA Program
(NHE) ken.hawkins_at_nara.gov301-837-1798
Additional Informationhttp//www.archives.gov/era
/rms/
57
(No Transcript)
58
Records Management Application

• A stand alone product
• Receives objects and takes either
• Physical control, or
• Logical control (the creating application cannot
  change it once this takes place)
• Record creator (IAW U.S. Law)
• Has never met requirements originally documented
  in the 1990s