Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

  • Be the first to comment


  2. 2. Agenda <ul><li>Executive Branch ECM Project Overview </li></ul><ul><li>Executive Summary </li></ul><ul><ul><li>EDMS/ERMS Integration with ITEA </li></ul></ul><ul><ul><li>SRCA Vision </li></ul></ul><ul><li>EDMS/ERMS Standards & Guidelines </li></ul><ul><ul><li>Multiple Disciplines </li></ul></ul><ul><ul><li>Interoperability and Metadata </li></ul></ul><ul><li>Benefits of EDMS/ERMS Integration with ITEA </li></ul><ul><li>Next Steps </li></ul>
  3. 3. NM ECM Project Overview <ul><li>Three agencies, HSD, TRD & SRCA submitted project requests for funding document & records management in 2003-2004 </li></ul><ul><ul><li>State CIO combined these requests into a multi-agency project due to their obvious synergies </li></ul></ul><ul><ul><li>Multi-agency Executive Steering Committee (ESC) structure oversees the project </li></ul></ul><ul><ul><li>Both the AOC JID and the ITC require continuing communication between the Judicial and Executive Branch ECM Projects </li></ul></ul>
  4. 4. Strategic Objectives <ul><li>Lower the Cost of Government </li></ul><ul><li>Improve Service Delivery to Constituents </li></ul><ul><li>Enterprise Model </li></ul><ul><ul><li>Define an ECM strategy that supports all content types and formats over the entire life cycle </li></ul></ul><ul><li>Centralized Electronic Records Repository </li></ul><ul><ul><li>Integrated approach for the capture, maintenance, storage, access, disposition and preservation of electronic records </li></ul></ul><ul><li>Business Process Management </li></ul><ul><ul><li>Content, documents and document management are inherent within Agency business processes. Reengineering the business processes in State Government is fundamental to implementing ECM </li></ul></ul>
  5. 5. Tactical Objectives <ul><li>Two current tactical projects: </li></ul><ul><ul><li>HSD Child Support Payments </li></ul></ul><ul><ul><ul><li>Capture and image payments and manage Child Support paper documents </li></ul></ul></ul><ul><ul><li>MVD Citations </li></ul></ul><ul><ul><ul><li>Capture MVD Citations, payments and manage paper documents </li></ul></ul></ul><ul><li>Improve ability to access and retrieve records: </li></ul><ul><ul><li>Find documents in 3 – 5 seconds </li></ul></ul><ul><ul><li>Instead of 3 – 5 days </li></ul></ul>
  6. 6. Executive Summary <ul><li>Proposed EDMS/ERMS Guidelines are: </li></ul><ul><li>A framework that overlays, or cross-cuts, the inter-related Information Technology Enterprise Architecture (ITEA) </li></ul><ul><li>A framework for incorporating </li></ul><ul><ul><ul><li>statutory records management requirements </li></ul></ul></ul><ul><ul><ul><li>and sound records management principles </li></ul></ul></ul><ul><ul><li>seamlessly into agency </li></ul></ul><ul><ul><ul><li>work processes </li></ul></ul></ul><ul><ul><ul><li>enterprise architectures </li></ul></ul></ul><ul><ul><ul><li>information systems </li></ul></ul></ul>
  7. 7. Executive Summary <ul><li>Agencies should use the proposed EDMS/ERMS Guidelines: </li></ul><ul><ul><li>In conjunction with the NM ITEA </li></ul></ul><ul><ul><ul><li>As the common State-wide framework </li></ul></ul></ul><ul><ul><ul><li>For identifying records management (RM) requirements </li></ul></ul></ul><ul><ul><li>To identify RM requirements and </li></ul></ul><ul><ul><ul><li>Link them to their information technologies </li></ul></ul></ul><ul><ul><ul><li>Link them to their business processes </li></ul></ul></ul><ul><ul><li>To educate all state employees in their records management responsibilities </li></ul></ul>
  8. 8. Executive Summary <ul><li>Agencies should use the proposed EDMS/ERMS Guidelines: </li></ul><ul><li>Build RM requirements into agency IT governance processes </li></ul><ul><ul><li>for planning IT funding </li></ul></ul><ul><ul><li>enterprise architecture </li></ul></ul><ul><ul><li>business process design </li></ul></ul><ul><ul><li>the systems development life cycle </li></ul></ul><ul><li>To establish a concise and coherent body of records management resources that places this information in the proper context within the ITEA </li></ul>
  9. 9. EDMS/ERMS & the ITEA
  10. 10. Federal Enterprise Architecture Records Management Profile <ul><li>Federal Enterprise Architecture Records Management Profile Version 1.0 </li></ul><ul><li>Initial Public Release Sponsored By: </li></ul><ul><ul><li>National Archives and Records Administration </li></ul></ul><ul><ul><li>Office of Management and Budget, Architecture and Infrastructure Committee </li></ul></ul><ul><ul><li>Federal Chief Information Officers Council </li></ul></ul><ul><li>December 15, 2005 </li></ul>
  11. 11. Potential Consequences of Inadequately Managing Records <ul><li>Inability to retrieve business critical information </li></ul><ul><li>Increased costs of doing business </li></ul><ul><ul><li>Caused by inefficiencies </li></ul></ul><ul><ul><li>Due to disparate/inaccessible data </li></ul></ul><ul><li>Failure to comply with statutory or regulatory retention and disposition requirements </li></ul><ul><li>Reduced ability to comply with </li></ul><ul><ul><li>Court orders & other litigation </li></ul></ul><ul><ul><li>Imperatives requiring access to existing information </li></ul></ul><ul><li>Inability to respond promptly to inquiries </li></ul>
  12. 12. Potential Consequences of Inadequately Managing Records <ul><li>Consequences of a failure vary depending upon the circumstances, but could range from minor to catastrophic: </li></ul><ul><ul><li>Inefficient service to state constituents </li></ul></ul><ul><ul><li>Regulatory fines and penalties, which have recently reached eight figure amounts </li></ul></ul><ul><ul><li>Civil litigation consequences, such as increased litigation costs and fines </li></ul></ul><ul><ul><li>Vicarious liability for responsible senior management </li></ul></ul><ul><ul><li>Criminal liability for agencies and individuals </li></ul></ul>
  13. 13. Intended Audience <ul><li>The following individuals should use these EDMS/ERMS Guidelines to support effective decision-making : </li></ul><ul><ul><li>Chief Information Officers (CIO) </li></ul></ul><ul><ul><li>Executive Management, Directors, Deputy Directors </li></ul></ul><ul><ul><li>Records Liaison Officers (RLO) </li></ul></ul><ul><ul><li>Program/Project Managers </li></ul></ul><ul><ul><li>General Counsels (GC) </li></ul></ul>
  14. 14. SCRA Vision <ul><li>Centralized Electronic Records Repository </li></ul><ul><ul><ul><li>integrated Electronic Document Management Systems & </li></ul></ul></ul><ul><ul><ul><li>an Electronic Records Management System (ERMS) </li></ul></ul></ul><ul><ul><li>a comprehensive, systematic, and dynamic means for preserving virtually any kind of electronic record </li></ul></ul><ul><ul><li>free from dependence specific hardware or software </li></ul></ul><ul><li>Benefits </li></ul><ul><ul><li>Make it easy for state agencies and constituents </li></ul></ul><ul><ul><ul><li>to find the records they want </li></ul></ul></ul><ul><ul><ul><li>easy for the SRCA to deliver those records </li></ul></ul></ul><ul><ul><ul><li>in any format suited to the users' needs </li></ul></ul></ul>
  15. 15. Centralized Electronic Records Repository <ul><li>Aligned with the IT Enterprise Architecture </li></ul>Data Model for the Centralized Electronic Records Repository
  16. 16. Multiple Disciplines <ul><li>The EDMS/ERMS Guidelines builds upon multiple disciplines as a foundation: </li></ul><ul><ul><li>Library Science </li></ul></ul><ul><ul><li>Records Management </li></ul></ul><ul><ul><li>Business Process Management </li></ul></ul><ul><ul><ul><li>Process Mapping </li></ul></ul></ul><ul><ul><li>Information Technology </li></ul></ul><ul><ul><ul><li>Enterprise Architecture </li></ul></ul></ul><ul><ul><ul><li>Data Modeling </li></ul></ul></ul><ul><ul><li>Metadata and XML </li></ul></ul>
  17. 17. Public Record defined <ul><li>A Public Record is Content </li></ul><ul><ul><li>regardless of physical form or characteristics - </li></ul></ul><ul><li>Made or received by any agency in pursuance of law or in connection with the transaction of public business </li></ul><ul><li>And preserved, or appropriate for preservation, by the agency or its legitimate successor </li></ul><ul><ul><li>As evidence of the organization, functions, policies, decisions, procedures, operations or other activities of the government; </li></ul></ul><ul><ul><li>For government responsiveness and accountability to state constituents; </li></ul></ul><ul><ul><li>To preserve the rights of citizens; </li></ul></ul><ul><ul><li>Or because of the informational and historical value of data contained therein. </li></ul></ul>
  18. 18. Records Management <ul><li>Records Management is the systematic control of Public Records </li></ul><ul><ul><li>from creation or receipt, </li></ul></ul><ul><ul><li>through processing, distribution, maintenance and retrieval, </li></ul></ul><ul><ul><li>to their ultimate disposition. </li></ul></ul><ul><li>The preservation, retrieval and non-alteration of Public Records - </li></ul><ul><ul><li>for the purpose of auditing </li></ul></ul><ul><ul><li>or potential litigation </li></ul></ul><ul><li>Statutory requirement that every executive is responsible for within each State Agency. </li></ul>
  19. 19. Implementing EDMS/ERMS
  20. 21. Analyze Agency Records Series
  21. 22. Imaging System Plan – File with SRCA
  22. 23. The Drive to Share Information <ul><li>Next step in government IT development: </li></ul><ul><li>Moving information across institutional boundaries </li></ul><ul><ul><li>between states </li></ul></ul><ul><ul><li>across executive agencies and to private entities </li></ul></ul><ul><ul><li>from courts to executive agencies, and between courts </li></ul></ul><ul><li>The drive to share information depends on: </li></ul><ul><ul><li>how successful the State is in framing the policy </li></ul></ul><ul><ul><li>the available technology </li></ul></ul><ul><li>Two interrelated concepts facilitate this effort: </li></ul><ul><ul><li>Enterprise Architecture (EA) </li></ul></ul><ul><ul><li>Service-Oriented Architecture (SOA) </li></ul></ul>
  23. 24. Interoperability <ul><li>The challenge for NM State agencies: </li></ul><ul><li>Embrace the opportunities of EA and SOA technologies </li></ul><ul><ul><li>To enhance the quality of executive, legislative and judicial information sharing </li></ul></ul><ul><ul><li>As an explicit objective of their systems development </li></ul></ul><ul><li>EA & SOA support interoperability </li></ul>
  24. 25. Interoperability Defined <ul><li>Interoperability has different meanings depending on the context: </li></ul><ul><ul><li>Information Technology – “the ability of independently developed and fielded applications that execute on heterogeneous computer platforms to communicate with one another and to exchange and use information (content, format, and semantics).” </li></ul></ul><ul><ul><li>Public safety – “the ability for public safety agencies and public services to talk to one another via radio communication systems and/or share information with one another accurately, on demand, in real time, when needed, and when authorized.” </li></ul></ul>
  25. 26. Federal E-Gov Architecture Guidance (Common Reference Model) <ul><li>“ XML provides a critical foundation for E-Gov data architectures. </li></ul><ul><li>“ XML is emerging as the Industry and Government standard for moving and sharing information. </li></ul><ul><li>“ XML provides an opportunity for Federal Lines of Business to define and standardize XML schemas for their functions and for interactions with other Lines of Business and external entities such as State and Local Governments or Industry. </li></ul><ul><li>“ Particularly powerful where Lines of Business can leverage emerging industry standards, or join with State and Local Governments to define joint XML schemas that provide data interoperability across tiers of government. </li></ul><ul><li>“ All E-Gov Initiatives should define and implement an approach for using XML.” </li></ul>E-Gov Architecture Guidance (Common Reference Model) Draft – Version 2.0, Interagency FEA Working Group, July 25, 2002
  26. 27. NASCIO Recommendations <ul><li>“ A common vocabulary is needed to facilitate cross boundary information exchange. </li></ul><ul><li>“ Extensible Markup Language (XML) has become the de facto standard for government data sharing. </li></ul><ul><ul><li>“ The Global Justice XML Data Model (GJXDM) is the standard being widely implemented by government agencies at all levels for inter-organizational communication and data sharing of public safety and criminal justice information.” </li></ul></ul>Connecting the Silos: Using Governance Models to Achieve Data Integration, NASCIO Research Brief, Interoperability and Integration Committee , June 2005 (Updated November 2005), page 3
  27. 28. JXDM Defined <ul><li>JXDM – The Justice XML Data Model (JXDM) was developed by the U.S. Department of Justice's (DOJ) Office of Justice Programs (OJP), together with the Global Justice Information Sharing Initiative (Global). </li></ul><ul><li>The purpose is to increase the ability of justice and public safety communities to share justice information at all levels laying the foundation for local, state, and national justice interoperability. </li></ul><ul><li>The DOJ began developing the requirements for the justice data model in 1998. </li></ul>Document Management System Interoperability -- The Need, The Answer: A White Paper for Federal Agency CIOs and IT Architects, February 1998 (Department of Justice)
  28. 29. GLOBAL defined <ul><li>Global - The Global Justice Information Sharing Initiative (Global) mission: </li></ul><ul><li>the efficient sharing of data among justice entities </li></ul><ul><li>at the very heart of modern public safety and law enforcement. </li></ul><ul><ul><li>Advises the U.S. Attorney General on justice information sharing and integration initiatives </li></ul></ul><ul><ul><li>Created to support the broad scale exchange of pertinent justice and public safety information </li></ul></ul><ul><ul><li>Promotes standards-based electronic information exchange to </li></ul></ul><ul><ul><ul><li>provide the justice community with timely, accurate, complete, and accessible information </li></ul></ul></ul><ul><ul><ul><li>in a secure and trusted environment </li></ul></ul></ul>
  29. 30. GJXDM Defined <ul><li>Global JXDM - a comprehensive product that includes </li></ul><ul><ul><li>a data model </li></ul></ul><ul><ul><li>a data dictionary </li></ul></ul><ul><ul><li>and an XML schema </li></ul></ul><ul><li>The Global JXDM is </li></ul><ul><ul><li>an XML standard designed specifically for criminal justice information exchanges </li></ul></ul><ul><ul><li>providing law enforcement, public safety agencies, prosecutors, public defenders & the judicial branch with a tool to effectively share data & information. </li></ul></ul>
  30. 31. GJXDM Defined <ul><li>Removes the burden from agencies to independently create exchange standards </li></ul><ul><ul><li>because of its extensibility </li></ul></ul><ul><ul><li>more flexibility to deal with unique agency requirements and changes </li></ul></ul><ul><li>Global JXDM enables interoperability </li></ul><ul><ul><li>through the use of a common vocabulary </li></ul></ul><ul><ul><li>that is understood system to system </li></ul></ul>
  31. 32. Developing Metadata - Process Diagram
  32. 33. Metadata Standards for ECM Agenda <ul><li>Definitions: </li></ul><ul><ul><li>Metadata </li></ul></ul><ul><ul><li>Data Dictionary </li></ul></ul><ul><ul><li>Data Model </li></ul></ul><ul><ul><li>XML </li></ul></ul><ul><ul><li>Interoperability </li></ul></ul>
  33. 34. Metadata Defined <ul><li>“ Metadata” means &quot;data about data&quot;; it is information that describes another set of data. </li></ul><ul><ul><li>Example is a library catalog card </li></ul></ul><ul><ul><ul><li>Contains data about the contents and location of a book: </li></ul></ul></ul><ul><ul><ul><li>It is data about the data in the book referred to by the card. </li></ul></ul></ul><ul><ul><li>Metadata is structured information that describes and/or enables finding, managing, controlling, understanding or preserving other information over time. </li></ul></ul><ul><li>In a records management context, metadata are data describing the context, content and structure of records and their management through time. </li></ul><ul><ul><li>As such metadata are structured or semi-structured information that enables the creation, registration, classification, access, preservation and disposition of records through time and within and across domains. </li></ul></ul>
  34. 35. Data Dictionary Defined <ul><li>A data dictionary is a set of metadata that contains definitions and representations of data elements. Amongst other things, a data dictionary holds the following information: </li></ul><ul><ul><li>Precise definition of data elements </li></ul></ul><ul><ul><li>Usernames, roles and privileges </li></ul></ul><ul><ul><li>General database structure </li></ul></ul><ul><li>A data dictionary supports consistency between data items across different tables. For example, several tables may hold telephone numbers, using a data dictionary the format of this telephone number field will be consistent. </li></ul><ul><li>Data dictionaries are one step along a pathway of creating precise semantic definitions for an organization. </li></ul>
  35. 36. Data Dictionary Example <ul><li>Telephone Number </li></ul>
  36. 37. Data Model Defined <ul><li>A data model is a model that describes in an abstract way how data is represented in a business organization, an information system or a database management system. </li></ul><ul><li>Data models include complex relationships between data elements </li></ul><ul><li>A data model shows how data of a specific business function is organized logically </li></ul>
  37. 38. Data Model Example <ul><li>Telephone Number </li></ul>
  38. 39. Data Model Example
  39. 40. XML Defined <ul><li>XML – Extensible Markup Language (XML) is a programming language devised for the web environment. </li></ul><ul><li>XML was designed to describe data and to focus on what data is. XML does not DO anything. </li></ul><ul><li>XML was created to structure, store and to send information. </li></ul><ul><li>XML is the most common standard for web programming </li></ul>
  40. 41. XML Example <ul><li>Telephone Number </li></ul><ul><li><?xml version=“1.0” encoding=“utf-16”?> </li></ul><ul><li><XS:schema xmlns:ns)=“http://NMDA_Schemas.NMDA_Telephone_Record” “http://NMDA_Schemas.NMDA_Telephone_Record: xmlns:b=“ ” elementFormDefault=“unqualified: targetTelephone= http:// NMDA_Schemas.NMDA_Telephone _ID version=“0.2” </li></ul><ul><li> <xs:import schemaLocation=“.NMDA_Telephone_ID.xsd” Telephone= http:// NMDA_Schemas.NMDA_Telephone /> </li></ul><ul><ul><li><xs:annotation> </li></ul></ul><ul><ul><li><xs:appinfo> </li></ul></ul><ul><ul><li><b:references> </li></ul></ul><ul><ul><li><b:reference targetTeleponeRecord=“http://NMDA_Schemas.NMDA_Telephone_Record:/> </li></ul></ul><ul><ul><li></b:references> </li></ul></ul><ul><ul><li></xs:appinfo> </li></ul></ul><ul><ul><li><xs:annotation> </li></ul></ul><ul><ul><li><xs:Telephone_ID name=“TelephoneID”> </li></ul></ul><ul><ul><li></xs:annotaiton> </li></ul></ul><ul><ul><li><xs:documentation> Database generated identifier assigned to each unique telephone contact record.>/xs:documentation> </li></ul></ul><ul><ul><li></xs:annotation> </li></ul></ul><ul><ul><li><xs:complexPARTYID> </li></ul></ul><ul><ul><li><xs:documentation>This is the ’link’ between the party and the entry in the telephone table<xs:documentation> </li></ul></ul>
  41. 42. Data Dictionary & Data Model
  42. 43. Common Administrative Metadata <ul><li>Metadata common to all agencies </li></ul><ul><li>The Metadata Standards have been organized into five tables: </li></ul><ul><ul><li>Table 1: Access Control/Rights/Redaction; </li></ul></ul><ul><ul><li>Table 2: Retention/Disposition Instructions; </li></ul></ul><ul><ul><li>Table 3: History or Audit Trail; </li></ul></ul><ul><ul><li>Table 4: Document/Records Description, and Document/Record Content; </li></ul></ul><ul><ul><li>Table 5: Agency Specific metadata </li></ul></ul><ul><li>These common metadata elements capture information needed to adequately administer content and documents </li></ul>
  43. 44. Common Administrative Metadata <ul><li>Table 1: </li></ul><ul><ul><li>Access Control /Rights/Redaction: </li></ul></ul><ul><ul><ul><li>Security Classification </li></ul></ul></ul><ul><ul><ul><li>Rights – (to read, write, change, delete) </li></ul></ul></ul><ul><li>Table 2: </li></ul><ul><ul><li>Retention and Disposition: </li></ul></ul><ul><ul><ul><li>Retention Schedule </li></ul></ul></ul><ul><ul><ul><li>Disposal Notification Flag </li></ul></ul></ul><ul><ul><ul><li>Record Series Number (NMAC Number) </li></ul></ul></ul>
  44. 45. Common Administrative Metadata <ul><li>Table 3: </li></ul><ul><ul><li>History or Audit Trail </li></ul></ul><ul><ul><ul><li>Date accessed </li></ul></ul></ul><ul><ul><ul><li>Preservation and migration history </li></ul></ul></ul><ul><ul><ul><li>Hardware </li></ul></ul></ul><ul><ul><ul><li>Software </li></ul></ul></ul><ul><li>Table 4: </li></ul><ul><ul><li>Document / Record Description </li></ul></ul><ul><ul><ul><li>Author/Creator/Originator </li></ul></ul></ul><ul><ul><ul><li>Date Created </li></ul></ul></ul><ul><ul><ul><li>Key words (for searching) </li></ul></ul></ul><ul><ul><ul><li>Retention Record Series Number </li></ul></ul></ul>
  45. 46. Agency Specific Metadata <ul><li>Table 5: </li></ul><ul><ul><li>Agency Specific Metadata for Discovery </li></ul></ul><ul><ul><li>These elements capture information contained in the content or document that support retrieval and searching. </li></ul></ul><ul><ul><ul><li>Record Type </li></ul></ul></ul><ul><ul><ul><li>Description </li></ul></ul></ul><ul><ul><ul><li>Subject(s) </li></ul></ul></ul><ul><ul><ul><li>Person(s) </li></ul></ul></ul><ul><ul><ul><li>Date(s) </li></ul></ul></ul><ul><li>See NM Court Workflow Design </li></ul>
  46. 47. Next Steps <ul><li>Developing NMAC Rules for EDMS/ERMS Application Standards, plus the Whitepaper </li></ul><ul><li>Updated Timeline - September </li></ul><ul><ul><li>Application Domain Team Review and Approval </li></ul></ul>