NIST E-Gov Standards Resource CenterNIST E-Gov Standards Resource CenterESRC_af7c7044-e0b2-41df-8673-64abf0e84dc9Analysis of E-Gov StandardsDevelop an analysis document that evaluates the present state of selection of private sector consensus standards and development of U.S. Government unique standards by all of the E-Gov Initiatives and Lines of Business (LOBs)._de892cc7-b96f-4144-afc4-7415512cf14c1E-Gov OverviewBroad Overview of E-Gov Initiatives and Lines of Businesses_50f79e10-97c9-4f53-bcf4-2f549b7abcf41http://www.whitehouse.gov/omb/egov/c-presidential.htmlFEA StandardsUse of Standards in FEA_6673ce64-9c03-4078-b9db-86026972ea8f2Some Examples of use of Standards in FEA: Data Reference Model: For example, the DRM abstract model can be implemented using different combinations of technical standards. As one example, the Exchange Package concept in the Data Sharing standardization area may be represented via different messaging standards (e.g. eXtensible Markup Language (XML) schema2, Electronic Data Interchange (EDI) transaction set) in a concrete system architecture for purposes of information sharing (Page 8 of DRM_2_0_Final.pdf). - Data Context is a standardization area within the DRM. - Data Description is a standardization area within the DRM. - Data Sharing is a standardization area within the DRM- Data Description Standardization: the purpose is to provide a means for a COI to agree to the structure (syntax) and meaning (semantics) of the data that it uses. Department of Interior used ISO/IEC 11179 Metadata Registries Standard for the metadata attributes that describe the data. ISO/IEC 11179 is a Metadata Registry Standard that can be used by implementations based on the DRM to register and represent the metadata describing data within their data assets. The purpose of the Data Context standardization area is to enable identification and discovery of data and to provide linkages to the other FEA reference models. Data Sharing: (Page 47) “Analytical Databases” under the “Data Supplier-to-Consumer Matrix” includes directories (e.g., repositories that support the Light Weight Directory Access Protocol, LDAP or X.500 Data Schema: A representation of metadata, often in the form of data artifacts such as logical data models or conceptual data models Query Languages: SQL-92, CQL(Z39.50), XQuery, HTTP GET etc. Standards Best Practices GuideDevelop a guidance document on recommended best practices for private sector consensus standards selection and criteria for U.S. Government unique standards development that can be applied across all E-Gov Initiatives and LOBs in the future._93fb61de-5ea8-4ed5-b447-ef82c477d4b62Private Sector Standards Evaluation CriteriaModel Evaluation Criteria for Selection of Private Sector Consensus Standards to be E-Gov Standards _61c3da8f-3b48-40bc-877c-87f6b5a2febf1Analysis Model for Selection of Private Sector Consensus Standards[i] to be E-Gov StandardsApplicability of standard: Is it clear who should use the standard and for what applications? How does the standard fit into the Federal Enterprise Architecture (FEA)? What was done to investigate viable alternative standards (i.e., due diligence) before selecting this standard?Availability of standard: Is the standard published and publicly available? Is a copy of the standard free or must it be purchased? Are there any licensing requirements for using the standard? Completeness of standard: To what degree does the candidate standard define and cover the key features necessary to support the specific E-Gov functional area or service?Implementations to standard: Does the standard have strong support in the commercial marketplace? What commercial products exist for this standard? Are there products from different vendors in the market to implement this standard? If the standard is proprietary, are there nevertheless many products readily available from a variety of vendors? Are there any existing or planned mechanisms to assess conformity of implementations to the standard?Interoperability of standard: How does this standard provide users the ability to access applications and services through Web services? What are the existing or planned mechanisms to assess the interoperability of different vendors’ implementations?Legal considerations: Are there any patent assertions made to this standard? Are there any IPR assertions that will hinder USG distribution of the standard?Maturity of standard: How technically mature is the standard? Is the underlying technology of the standard well-understood (e.g., a reference model is well-defined, appropriate concepts of the technology are in widespread use, the technology may have been in use for many years, a formal mathematical model is defined, etc.)? Is the standard based upon technology that has not been well-defined and may be relatively new?Source of standard: What standards body developed and now maintains this standard? Is this standard a de jure or de facto national or international standard? Is there an open process for revising or amending this standard?Stability of standard: How long as this standard been used? Is the standard stable (e.g., its technical content is mature)? Are major revisions or amendments in progress that will affect backward compatibility with the approved standard? When is the estimated completion date for the next version?Government-Unique Standards Evaluation CriteriaModel Evaluation Criteria for Deciding to Develop USG Unique E-Gov Standards _53aadbcd-ac4a-42cb-9e5b-0f13fac459102Analysis Model for Developing a USG Unique E-Gov Standard 1. Review and Approval of a Project Proposal for Development of a USG E-Gov Standard Title: Does the title clearly and adequately describe the project?Type of Standard: Is the type of standard (e.g., standardized: form, policy, process, data elements, model, web interface) identified?Proposer: Is the submitting organization(s) identified?Point of Contact: Is a point of contact identified?Purpose and Need of Standard: Is the purpose and need (e.g., security, interoperability) clearly stated? Is there adequate justification for why this standard is needed? How does the standard fit into the Federal Enterprise Architecture (FEA)? What has been done (i.e., due diligence) to establish that there is no available, suitable private sector consensus standard?Scope: Is the scope clearly defined and reasonable for this standard?Related Standards: If related standards or related standards projects exist, are there overlap issues that need to be resolved, or is there a need to coordinate with other standards projects? If an existing standard is being moved forward for adoption or is being modified for adoption, is the original standard identified?Placement of project: Are there any appropriate private sector consensus standards developing organizations which could develop this standard? If not, what is the most appropriate USG group for development of the standard? Development approach and completion schedule: Is the technical development approach sound? Is schedule reasonable? Who will serve as the chairperson for this project? Who will serve as the project editor for this project? Will there be a public review of the draft standard? What is the target date for releasing the draft document for public review?Resources required: Does the proposal identify adequate resources to carry out the project?Potential participants: Are participants and lead organization identified? Is participation broadly based?Legal considerations: Is the proposer aware of any patent assertions that may be made? If so, describe. Is the proposer aware of any IPR assertions that will hinder distribution of the approved standard? If so, describe.Life expectancy of this standard: What is the expected useful life of this standard? Is the standard independent of technology? Can the standard be implemented with known or future technology?2. Review of a USG E-Gov Standard Prior to Approval Title: Does the title clearly and adequately describe the standard?Scope: Is the scope clearly defined? Is it clear what is within and not within the scope of the standard? Is the purpose and need (e.g., security, interoperability) clearly stated? Is there adequate justification for why this standard is needed? Applicability and intended uses of standard: Is it clear who should use the standard and for what applications?Description of relationship to existing standards if applicable: If there are related standards, are they identified and the relationship explained?Description of the development process: Is there a brief description that adequately describes the process by which the standard was developed (including meetings held, participants, etc.)? Is the basis for the standard identified, for example is this an existing standard, a modification of an existing standard or a new standard?Identification of participants: Are the participating organizations identified? (Individual names may or may not be included in the draft.)Maintenance of the Standard: Is the maintenance authority for the standard identified? If a maintenance strategy is described, is it understandable and reasonable?Body of the standard: Is the standard clearly organized and presented in an understandable manner? Does the standard follow a specific format guideline?References: Is there a reference section? Are the references clearly identified so that someone can readily obtain them?Appendices/Annexes: Is it clear whether these are informative (not part of what is being standardized) or normative (part of what is being standardized)?Legal considerations: Have any patent assertions been made? If so, describe. Are there any IPR assertions that will hinder distribution of the approved standard? If so, describe.Other Issues: How does the standard fit into the Federal Enterprise Architecture (FEA)? What mechanisms will be used to assess conformity of implementations to the standard? What mechanisms will be used to assess the interoperability of different vendors’ implementations? Are any editorial corrections required? Does the standard reflect the requirements of the original project proposal? Is the standard independent of technology? Can the standard be implemented with known or future technology? Are there other similar standards available or are there other related standards development efforts going on? If so, are there overlap issues that need to be resolved, or is there a need to coordinate with other standards projects? Are there any questions that need to be answered or clarifications required before approval? Was there a public review? If so, was the public review based on a broad cross-section of users? In revising the standard, was the development group responsive to the comments received during the public review period? What has been done (i.e., due diligence) to establish that there is no available, suitable private sector consensus standard? Are there any appropriate private sector consensus standards developing organizations to which this standard should be submitted for further processing as a private sector consensus standard? If so, who will take responsibility for submitting the standard?Policy RecommendationsDevelop recommendations on specific mechanisms to promulgate government policy for the instantiation of standards that are adopted by each E-Gov Initiative and LOB._fe525742-74cf-40ca-a96c-662723bfa87f3NIST Validation Process for E-Gov StandardsProvide a formal, streamlined process and central reference site for USG validated (i.e., officially approved) E-Gov standards._bd3cc100-b061-41f9-9a14-24652e43e1481Background: The mission of each E-Gov Initiative and LOB requires deployment of innovative, web-based information technology (IT) services. Standards are required for deployment of E-Gov services in order to ensure the necessary interoperability and security between government agencies/businesses/citizens. To date, some of the E-Gov Initiatives and LOB have adopted specific standards deemed to be necessary for accomplishing their respective missions. In some instances, no suitable private sector consensus standards were available and USG unique standards have been developed and adopted. Due to the innovative nature of the E-Gov services and the lessons learned from initial deployments, changes (e.g., additions, amendments) to some of the adopted standards are occurring on a regular basis (e.g., yearly).Requirements of USG Validation Process: - E-Gov standards (new and revised) are validated promptly (i.e., in days, rather than in weeks or months). -Timely, comprehensive information about all USG validated E-Gov standards is available from one, central official source. - OMB/GSA policy mandates the use of USG validated E-Gov standards for the acquisition and deployment of E-Gov services. Synopsis of USG Validation Process: Analysis models for the selection of private sector consensus standards and for the development of USG unique standards are posted by NIST on the NIST administered web site (Standards.gov) under “E-Gov Standards Resource Center.” In cooperation with the E-Gov Initiatives and LOB, NIST identifies all E-Gov standards that have already been adopted by each E-Gov Initiative and LOB. For each identified standard, the relevant E-Gov Initiative or LOB submits to NIST their answers to the questions in the relevant analysis model, including their analysis of fit with the FEA. Using the posted analysis models, NIST reviews and validates E-Gov standards that have already been adopted by each E-Gov Initiative and LOB. All pertinent information about the initial set of validated E-Gov standards is posted by NIST on the “E-Gov Standards Resource Center.” As each new E-Gov standard is selected or developed by a specific E-Gov Initiative or LOB, the standard and the answers to the questions in the relevant analysis model, including their analysis of fit with the FEA, is submitted to NIST. Using the relevant analysis model, NIST reviews and validates each submitted E-Gov standard. All pertinent information about newly validated E-Gov standards is posted by NIST on the “E-Gov Standards Resource Center.” On an annual basis NIST, polls all E-Gov Initiatives and LOB to confirm all of the posted information about validated E-Gov standards. Embed Standards in Acquisition ProcessEmbed validated E-Gov standards into the USG procurement process._1c40476b-11e1-4435-bfe5-3914b73d8b872Incorporation of Validated E-Gov Standards into the Planning, Acquisition and Deployment of E-Gov Services: OMB/GSA includes the requirements for validated E-Gov standards in appropriate procurement policy (e.g., FAR, Exhibit 300). USG RFIs, RFPs, and awarded contracts reference the relevant, mandatory validated standards at Standards.gov.2010-02-08http://ts.nist.gov/standards/e-gov/ArthurColman (www.drybridge.com)colman@drybridge.com