How to Manage Data Across Agencies Using the FEA DRM 11 September 2006 Implementing the Federal Enterprise Architecture Data Reference Model (FEA DRM) How to Manage Data Across Agencies Using the FEA DRM 11 September 2006 “Build to Share”

Agenda FEA DRM Basic Concepts Three Pillar Data Strategy Framework Federal Data Architecture Subcommittee Agency DRM Implementation Examples

FEA DRM Concept How do I exchange the data? Data Sharing Query Points and Exchange Packages Data Description Data Data Context Taxonomies How do I exchange the data? What does the data mean? How do I find the data and access it? Based on FEA DRM Version 2.0

FEA DRM Structure

The DRM relates to each of the other FEA Reference Models FEA Data Reference Model (DRM) relationship with Other FEA Reference Models Business Reference Model (BRM) Lines of Business Agencies, Customers, Partners Service Component Reference Model (SRM) Technical Reference Model (TRM) Performance Reference Model (PRM) Inputs, Outputs, and Outcomes Uniquely Tailored Performance Indicators Service Domains, Service Types Business and Service Components Service Component Interfaces, Interoperability Technologies, Recommendations Map data to inputs and outputs that support Performance Outcomes Map data to processes by Lines of Business Map data to Service Components by information flows Map data to the infrastructure to plan for interoperability Use DRM Context to: The DRM relates to each of the other FEA Reference Models

The DRM Approach (Summary) Data Context: Figure out the Data that the Enterprise (aka Community of Interest) cares about. Data Description: Figure out the standards: Standard Meanings Standard Structures Data Sharing: Figure out the services required to share information The DRM provides basic guidance on what to capture in each of these areas and how to capture it. (i.e., the Abstract Model) Intentionally, the DRM does not delve into specific models or artifacts that the architects will create: Organizations use different EA Frameworks. There are a lot of right ways. The models/artifacts developed will depend on what’s needed As we define best practices, we will consider more definitive guidance in the DRM However, the objective is to provide actionable guidance to your programs: We should be building with data sharing in mind up front. - “Build to Share”

FEA DRM Abstract Model (Guidance for Organizing Information About Agency Data)

Three Pillar Data Strategy Framework FEA DRM Three Pillar Data Strategy Framework

The DRM Data Strategy Framework Business & Data Goals drive Information Sharing/Exchange (Services) Governance Data Strategy Data Architecture (Structure) The Rule: All 3 pillars are required for an effective data strategy. This slide illustrates the Data Strategy Framework. As shown, it consists of Goals, and a data strategy of three components, that is of governance, structure, and services. Data strategy starts with goals. These goals are business goals and are normally well outside the bounds of the data strategy itself. Business goals include things like “increase market share” and “decrease cycle time”. Business goals drive the data strategy and there are comprehensive methods of translating them into data management goals that support attainment of the business goals. Goals drive the data strategy. Within the data strategy, we find ourselves dealing with the Structure of our data (which is where a lot of us live and never come up for air). We find ourselves dealing with Services that make the data available and with Governance which establishes procedures, sets standards, and generally specifies how everything fits and works together to meet the corporate goals, so maybe the arrow from Goals to Data Strategy needs to be two ended. Goals drive; governance controls; structure defines; and services enable data strategy. Special thanks to Laila Moretto and Forrest Snyder, MITRE Corp.

Data Strategy Framework Sample Elements Information Sharing/Exchange (Services) Data Architecture (Structure) Governance Oversight Policy & Procedures Processes and Practices Education/Training Issue Resolution Metrics/Incentives Data Transfer Standards Pedigree Authoritative Sources Security/Protection Data Discovery Data Inventory Definitions/Semantics Structure Syntax Access Services Brokering Shared Spaces Data Catalogs Data Registries Communities of Interest Search Mediation Here, the items identified as areas to be addressed by the data strategy according to the components of the Data Strategy Framework. All three components are represented. Use of specific elements depend on the goals

Sample Data Management Goals and the Sample Elements of a Data Strategy Shared Spaces Access Services Data Catalogs Communities of Interest Search Data Registries Inventory Metrics/Incentives Policy & Procedures Processes and Practices Education/Training Discovery Data Structure Definitions/Semantics Pedigree Syntax Oversight Authoritative Sources Security/Protection Data Data Transfer Standards Brokering Mediation Governance Data Goals: Visible Accessible Institutionalized Data Architecture Understandable Making data accessible, like making data visible, requires that it be registered, and cataloged (so it can be discovered), and posted to shared spaces (so it can be accessed). In addition , making data accessible may require some kind of search engine to go out and find and retrieve it. Trusted Interoperable Responsive Information Sharing

Mapping the Sample Elements of the Strategy Framework to the DRM Data Context enables… Data Description captures… Data Sharing guides…

Governance Overview

Federal CIO Council Organization Executive Committee Director, Administrator of the Office of e-Government (OMB) Chair, Deputy Director for Management (OMB) Vice Chair (Agency CIO) Architecture & Infrastructure Committee Workforce & Human Capital for IT Committee Best Practices Committee Emerging Technologies Subcommittee Governance Subcommittee Services Subcommittee The Federal Data Architecture Subcommittee is one of four subcommittees under the Architecture and Infrastructure Committee. Data Architecture Subcommittee

Governance Strategy Federal Data Architecture Subcommittee (DAS) Chartered by Federal CIO Council 2 Co-chairs appointed by AIC Membership Federal CIO representation Various work groups Vision: Engage communications in advancing the management of Federal data as a valued national assets that supports the business of the Federal Government. Key FY06/FY07 Activities/Deliverables 1. FEA DRM updates and revisions 2. Implementation strategies, best practices, and success stories Establish an authoritative knowledge center for Federal data- related issues and opportunities Purpose: To advances the management of Federal data as a national asset; stewardship of the Federal Enterprise Architecture (FEA) Data Reference Model (DRM), FEA DRM Management Strategy; to promote the use and improvement of data and data standards across the Federal Government; to facilitate of community collaboration and information sharing using communities of interests, both federal and intergovernmental.

Communities of Interest (COI) and Line of Business (LOB) Vision Data Goals drive Information Sharing/Exchange (Services) Governance Data Strategy Data Architecture (Structure) Each COI or LOB will implement the three pillar framework strategy and will focus on business requirements.

DRM Implementation Examples

E-Gov Initiative: Recreation One Stop

E-Gov Initiative: Recreation One Stop One of the President’s E-Gov inter-agency Initiatives led by DOI Requirements: Share data among multiple Federal, State, Local and Commercial partners Share data across multiple business lines Data standards must be easily extensible to accommodate new requirements Data sharing standards must be translated to a database and XML drive (Services) Gover-nance Data Strategy (Structure) Goals

E-Gov Initiative: Recreation One Stop (Challenge) drive (Services) Gover-nance Data Strategy (Structure) Goals E-Gov Initiative: Recreation One Stop (Challenge) Finding: There are 15+ redundant systems that should be retired, and 12 other systems that should be interfaced to Recreation One Stop Recommendations: Interface 12 systems Retire 8 systems with databases and web front ends Conduct BPR on 2 systems to standardize processes and consolidate into Recreation One Stop. Retire 5 “systems” which consist of html pages and manual processes Leverage training available free of charge through NRRS Customers see too many sources for Federal recreation information.

E-Gov Initiative: Recreation One Stop drive (Services) Gover-nance Data Strategy (Structure) Goals E-Gov Initiative: Recreation One Stop Financial-Transaction Recreation Area Reservation Event/Incident Recreation Activity Vendor Geospatial- Location Country State River Recreation Facility Person Organization Descriptive- Postal- Sale Trail Permit (Blue = Shared Data Concept) Finding: 67 of the 99 conceptual data entities should be managed outside of the Recreation LoB Recommendations: Identify data required by Recreation LoB Identify stewards and standardized required Recreation data Map standard data to potential data sources Designate an “authoritative” source Execute investments to supply data from an authoritative source Structure: High Percentage of Data Reuse Identified

E-Gov Initiative: Recreation One Stop drive (Services) Gover-nance Data Strategy (Structure) Goals E-Gov Initiative: Recreation One Stop Physical Model Schema (RIDB) CREATE TABLE RECAREA (RECAREA_ID CHAR(12) NOT NULL, RECAREA_NM VARCHAR(50) NOT NULL PRIMARY KEY (RECAREA_ID)); CREATE UNIQUE INDEX XPKRECAREA ON RECAREA ( RECAREA_ID ASC); CREATE TABLE RECAREA_ACT RECAREA_ACT_CD CHAR(2) NOT NULL, RECAREA_ACT_DESC VARCHAR(240) NULL, RECAREA_ACT_FEE VARCHAR(240) NULL); CREATE UNIQUE INDEX XPKRECAREA_ACT ON RECAREA_ACT ( RECAREA_ID ASC, RECAREA_ACT_CD ASC); XML Schema <?xml version="1.0" ?> <xsd:Schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xs:element name="RecAreaActivity"> <xs:annotation> <xs:documentation>A recreational activity available at a Recreation Area. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="RecAreaActivityType" type="xs:string"> <xs:documentation>The code that denotes a specific kind of Recreational Activity.</xs:documentation> </xs:element> Information Exchange Package: RECREATION ACTIVITY QUERY Subject Area: RECREATION Information Class: RECREATION ACTIVITY RECREATION-AREA RECREATION-AREA DENTIFIER RECREATION-AREA NAME RECREATION-AREA MAP URL TEXT RECREATION-AREA IDENTIFIER (FK) RECREATION-ACTIVITY TYPE CODE RECREATION-AREA-ACTIVITY DESCRIPTION TEXT RECREATION-AREA-ACTIVITY FEE DESCRIPTION TEXT RECREATION-AREA-ACTIVITY A1|AIR-HANG GLIDING B1|BOATING-SAILING B2|BOATING-CANOEING B3|BOATING-KAYAKING C1|CAMPING-CAMP SITES C2|CAMPING-FREE SPACE H1|HIKING-TRAILS H2|HIKING-FREE RANGE S1|SWIMMING-LAKE, POND S2|SWIMMING-POOL DOMAIN: Data Object: DOI Conceptual Data Entities (Standardized) REGISTRY ENTRY: DATA TYPE: CHARACTER LENGTH: 2 DEFINITION: The code that denotes a specific kind of Recreational Activity CLASS WORD: CODE METADATA REGISTRY/REPOSITORY Glossary of Metadata Data Property: DOI Conceptual Data Elements (Standardized) Data Representation: Data Element Description Services: RecML is based on standards described in Recreation ERD

E-Gov Initiative: Recreation One Stop drive (Services) Gover-nance Data Strategy (Structure) Goals E-Gov Initiative: Recreation One Stop Services: Information Sharing Result

E-Gov Initiative: Recreation One Stop (Governance) drive (Services) Gover-nance Data Strategy (Structure) Goals E-Gov Initiative: Recreation One Stop (Governance) COI is Federal Recreation providers Recreation Executive Council Members are deputy assistant secretary level (DOI, USDA, & DOD) Provides strategic perspective Provides adjudication Recreation Managers Committee Senior level Recreation managers Sets priorities Members include Smithsonian, DOT, and 16 other agencies Various implementation groups One group is responsible for the adoption of data standards Another group stewards the data Another group responsible for data implementation

Cross-Cutting Initiative: Continuity Communications Architecture (CCA)

Continuity Communications Architecture (CCA) drive (Services) Gover-nance Data Strategy (Structure) Goals Continuity Communications Architecture (CCA) Objective Provide a high-level architectural design which can be used by Federal Departments and Agencies (D/As) to ensure execution of their Mission Essential Functions (MEFs) during all circumstances (including disasters, terrorism, and war) and operational states (including ECG, COG, and COOP) Scope Address Federal Executive Branch (FEB), with planned extensions into States, for all MEFs ECG = Enduring Constitutional Government COG = Continuity of Government COOP = Continuity of Operations COOP is single agency ability to continue work COG = Continuity of a Federal Branch ECG = Ability of the Government to continue operations

CCA Metamodel Three Major Components Environment/Situation The Scenarios under which the D/As must operate Operations/Business What the D/As must do in any given Scenario Infrastructure The facilities, communications systems, hardware/software, and other capabilities the D/As use to accomplish their priority missions Infrastructure Operations/ Business Environment/ Situation Preserve our Constitutional form of government Provide visible leadership to the Nation and the world Defend against all enemies, foreign or domestic Maintain and foster foreign relations Protect against threats to the homeland Provide rapid response to emergency situations Protect and stabilize the nation's economy Provide critical Federal government services

CCA Structure: Metamodel Relationships drive (Services) Gover-nance Data Strategy (Structure) Goals NEFs Drive PMEFs Drive Scenarios Other Orgs Define Perform Perform Reside at Require/ Produce Effects Other Functions D/As Perform Environment/Situation Enable Reside at Affect Use Require/Produce Information Content Services Geographic Locations Operations/Business Implement Described by Understand the ‘what’ and the relationships important to the business of the Executive Branch Agencies of the Government. Info content and Info reps is the glue between the operational and technical worlds. Design is focused on info sharing in a stressed environment to accomplish the National Essential Functions (NEFs): Preserve our Constitutional form of government Provide visible leadership to the Nation and the world Defend against all enemies, foreign or domestic Maintain and foster foreign relations Protect against threats to the homeland Provide rapid response to emergency situations Protect and stabilize the nation's economy Provide critical Federal government services Infrastructure Affect Information Representations Are Identified With Applications Process Exchanges Store Reside on Communications Security Restricts Connect Protects Computing/Storage Platforms Reside at Facilities

CCA Analytical Toolset drive (Services) Gover-nance Data Strategy (Structure) Goals CCA Analytical Toolset CCA Toolset An integrated repository to store CCA information D/As and PMEFs Information Needs and Representations Communications and Security Capabilities Networks and Protocols Analytical Capabilities Identify interoperability and compatibility gaps Assess ability of D/As to accomplish PMEFs Provides reports and other “views” Information exchange disconnects Communications infrastructure deficiencies User-friendly “front-end” to organize and catalog “As-Is” data Employs “pick lists” based on consistent terminology Facilitates data loading and minimizes data entry errors Built an rdb based on the metamodel. Accounts for facilities, & other concepts in the metamodel. Purpose is to gather and analyze info stored in a single repository.

P O CCA Analysis Sample PMEF Analysis Information Gaps NEF PMEF drive (Services) Gover-nance Data Strategy (Structure) Goals Sample PMEF Analysis Information Gaps Provides INPUT 1 NEF D/A # 2 P Supports INPUT1 Report PMEF INPUT 2 Secure Call O Does NOT produce INPUT 2 Inputs required to perform PMEF Use this analysis to id info gaps. Id gaps in communicating facilities D/A # 3 D/A # 1

CCA Data Context “Information” is Key Information Content standardized drive (Services) Gover-nance Data Strategy (Structure) Goals CCA Data Context “Information” is Key What “Information Content” do the D/As need to share to support their Mission Essential Functions? Information Content standardized Aligned to BRM Lines of Business/Subject Areas Seven basic types of information exchanges Requests for Information Report of Facts or Statistics Guidance Direction Advice or Recommendations Request for Authority Financial Transaction Specific types of “Information Representations” associated with each Imagery, Voice, E-mail, Database, Text, etc. In general, the basis for governance is to learn the players and understand the processes. With CCA, knowledge gained during this phase of the analysis is used to improve governing policies, processes, procedures.

Agency Initiative: HUD

HUD Single Family Integration drive (Services) Gover-nance Data Strategy (Structure) Goals HUD Single Family Integration Project Mission: Consolidate the functionality and data from 35 legacy systems operating on multiple platforms written in multiple programming languages into a single integrated system operating in a service-oriented J2EE and Oracle environment.

HUD Single Family Integration drive (Services) Gover-nance Data Strategy (Structure) Goals HUD Single Family Integration Challenges Complexity of Target Logical Data Model - Functions being defined and refined - Capture of institution knowledge - Moving target Challenges Legacy Data System - System Focused - Data Duplication - Data Quality Data that is not used ( obsolete ) Legacy System Data that is redundant Legacy System Target Data that has been decomposed Logical Data In the Target LDM Model Data elements – unknown ? Legacy System Data that has been normalized In the Target LDM

HUD Single Family Integration (Structure) drive (Services) Gover-nance Data Strategy (Structure) Goals HUD Single Family Integration (Structure) Registry consisting of Legacy System Architecture Target Architecture Data & Service Mapping Bi-directional Traceability

HUD Single Family Integration (Governance) drive (Services) Gover-nance Data Strategy (Structure) Goals HUD Single Family Integration (Governance) Modeled after the HUD Data Control Board Charter Members: Legacy System Subject Matter Experts (SME) Target Architecture Experts Attendees: SF Integration Team members and other HUD staff Board approves final data migration plans

HUD Single Family Integration (Information Exchange Services) drive (Services) Gover-nance Data Strategy (Structure) Goals In early stage Metadata Management Oracle Middleware Connecting Software Applications Exchanging Data Leverage SOA to streamline information lifecycle

EPA Central Data Exchange Agency Initiative: EPA Central Data Exchange (CDX)

EPA Central Data Exchange / Exchange Network Vision drive (Services) Gover-nance Data Strategy (Structure) Goals EPA Central Data Exchange / Exchange Network Vision The States and EPA are committed to a partnership to: Build locally and nationally accessible, cohesive and coherent environmental information systems that will Ensure the public and regulators have access to the information needed to document environmental performance, understand environmental conditions, and make sound decisions to ensure environmental protection.

EPA Central Data Exchange / Exchange Network (Requirements) drive (Services) Gover-nance Data Strategy (Structure) Goals EPA Central Data Exchange / Exchange Network (Requirements) Service Oriented Architecture (SOA) Framework Standards Based Strong Extensible Security Model Utilizes Shared Services and Components Interoperates Across Platforms XML Schema Based Exchanges Developed from Data Standards Reuses Shared Schema Components We have built a successful interoperable Network and Governance model in the Exchange Network and CDX We need to leverage these experiences to jump start our Agency SOA We can’t afford web service proliferation chaos (anyone/ any tool can create a web service , but that does not insure interoperabilty) We have obtained interoperability across using the Network Protocol and Specifications This is still a maturing set of technologies We need to provided infrastructure, tools, software and documentation to make it easier

drive (Services) Gover-nance Data Strategy (Structure) Goals EPA Challenge Universities Tribes Analysis and Access Systems Program Data Repositories & Data Warehouses Registries Program Silo 50+ Front End Data Collection Systems Program Information Consumers Program Silo 1 Program Silo 2 Program Silo 3 Program Silo 4 Program Silo 5 Program Silo 6 Program Silo 7 Program Silo 8 Program Silo 9 Program Silo 10 Program Silo 11 Program Silo 12 Program Silo 13 Program Silo 14 Program Silo 15 Program Silo 16 Program Silo 17 Program Silo 18 Program Silo 19 Program Silo 20 Industry States Local Govt Citizens Policy Makers Legislators Unmanageable Complexity (>100 data flows with custom formats and processes But increased reporting and data use led to more and more complexity

EPA Solution Exchange Network Standards Driven Data Sharing, (Services) Gover-nance Data Strategy (Structure) Goals EPA Solution Standards Driven Data Sharing, (not just data delivery) Citizens Policy Makers Legislators Universities Tribes Industry States Local Govt Exchange Network

EPA Exchange Network Governance drive (Services) Gover-nance Data Strategy (Structure) Goals EPA Exchange Network Governance Operations happens in gray NOB is for oversight and approval and reviews work of NTG/NPRG We are Network Technology Group: front-line responsibility for technical activities on Network

Central Data Exchange / Exchange Network (XML Schema Management) EPA Central Data Exchange / Exchange Network (XML Schema Management) drive (Services) Gover-nance Data Strategy (Structure) Goals Diagram provides birds-eye overview of schema development, review, and registration on the Exchange Network, and is intended to accompany a short document of the same name (not yet completed) Intended to be posted on the Exchange Network website as an introduction to schema and XML on the Network, with links to the appropriate guidance documents Diagram depicts four main processes: Standards and Shared Schema Component Development (as currently produced by EDSC and TRG) Flow schema development (using SSC and other Network guidance to produce flow specific schema) Schema review (conformance report development) Schema registration (completing the process of saving the schema to the Repository and registering the schema on the Network)

EPA Exchange Network Status drive (Services) Gover-nance Data Strategy (Structure) Goals

EPA Example Service Integration drive (Services) Gover-nance Data Strategy (Structure) Goals EPA Example Service Integration This is an example of a state permit application integrating multiple shared services to improve data quality and simplify data submission The state application calls our SRS web service for chemical information that is integrated into a permit IT then calls the QA service (to check other parts of the XML document) before submitting it to CDX CDX Calls internal services for archive logging etc. then it calls a service on the operational data store to load the new data into the national system

Contact Info for Each Implementation Example Recreation One Stop Charlie Grymes E-mail: charlie.grymes@ios.doi.gov HUD – Single Family Integration Beverly Hacker E-mail: beverly_s._hacker@hud.gov EPA – Central Data Exchange/Exchange Network Mark Luttner E-mail: luttner.mark@epa.gov CCA Gary Amato E-mail: Gary.amato@dhs.gov

Future Directions

What’s Next Working Toward Six Strategic Goals: Improve decision making by citizens and government Improve availability of government information and services to citizens Improve communication among government entities and with citizens Reduce cost of Government through re-use of quality data Improve quality, visibility, discovery, accessibility of and confidence in available information

What’s Next Continued Continue Work of Six DRM Work Groups DRM Governance DRM Communications and Outreach DRM ERP Harmonization PERSON Harmonization DRM Best Practices XML Interoperability

What’s Next Continued Engagement with various E-Gov Initiatives Develop DRM version 3 Develop DRM Implementation Guide

Summary

Summary The FEA DRM consists of three basic concepts: Context, Description, and Information Sharing. DRM Governance includes DAS and COI’s Agencies can implement the FEA DRM in many ways.

Questions Co-chair contact info: Suzanne Acar: suzanne_acar@ios.doi.gov Bryan Aucoin: bryanja@dni.gov