Federal Data Architecture Subcommittee Co-chairs: What Does the DRM Mean to Me? – The FEA DRM Management Strategy 19 July 2006 Bryan Aucoin, DNI Suzanne Acar, DOI Build to Share

Agenda FEA DRM Concept Three Pillar Strategy Governance for Managing Data As a National Asset Implementation Examples Summary

FEA DRM Concept

DRM Purpose The Data Reference Model provides a structure that facilitates: the development of government data sharing within and across agency boundaries improvement of mission performance and services to citizens.

Goals Provide data to support business needs Reduce data redundancy and inconsistency within and across communities of interest

FEA DRM Concepts Data Sharing Query Points and Exchange Packages Data Description Data Elements Data Context Taxonomies (Categories) How do I exchange the data? What does the data mean? How do I find and access the data?

FEA DRM Structure Based on FEA DRM Version 1.0 and 2.0 Data Sharing Data Context Business Context Subject Area Information Class Information Exchange & Query Points Data Description Data Representation Structured Semi-structured Unstructured The broad categories of data that support business processes of a line of business or community of interest. The sub-categories of data used for mapping data groupings of many lines of business or communities of interest. Information that is generated or required by a Unit of Work and is subsequently passed to another Unit of Work. Units of Work consume and produce data. The organized description of data to convey semantic understanding usually through an entity relationship diagram. Data that has characteristics of both structured and unstructured data, such as an . Data that is of more free-form format, such as multimedia files, images, sound files, or unstructured text. How do I find and access the data? How do I exchange the data? What does the data mean? Data Element Data Object Data Property Data Representation

The DRM Approach (A Readers Digest Version) 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 whats 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 Data Context: Figure out the Data that the Enterprise (aka Community of Interest) cares about. 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 Description: Figure out the standards: Standard Meanings Standard Structures Data Sharing: Figure out the services required to share information Data Sharing: Figure out the services required to share information

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 Maps data to inputs and outputs that support Performance Outcomes Maps data to processes by Lines of Business Maps data to Service Components by information flows Maps data to the infrastructure to plan for interoperability Data Reference Model (DRM) The DRM relates to each of the other FEA Reference Models

Three Pillar Strategy

The Data Strategy Framework Goals drive; governance controls; structure defines; and services enable data strategy. Business & Data Goals drive Information Sharing/Exchang e (Services) Governance Data Strategy Data Architecture (Structure) The Rule: All 3 pillars are required for an effective data strategy.

Data Strategy Framework Elements Oversight Policy & Procedures Processes and Practices Education/Training Issue Resolution Governance Data Transfer Standards Pedigree Authoritative Sources Security/Protection Data Discovery Data Inventory Definitions/Semantics Structure Syntax Data Architecture (Structure) Access Services Brokering Services Shared Spaces Data Catalogs Data Registries Communities of Interest Search Information Sharing/Exchange (Services) Data Strategy Metrics/Incentives Mediation Broker

Mapping the Strategy to the DRM Data Context enables… Data Description captures… Data Sharing guides…

DRM Governance Strategy for Managing Data as a National Asset

The Basics Establishing Federal level governance structure Building process for formally chartered COIs DRM provides guidance to establish the 3 pillars Business-driven, outcome-oriented resolution of issues and opportunities related to data or information management Elevate best practices to a National and Federal level Harmonizing between COIs

Governance Strategy Federal Data Architecture Subcommittee (DAS) Chartered by Federal CIOCs AIC 2 Co-chairs appointed by AIC Suzanne Acar – DOI Bryan Aucoin – DNI Membership CIO representation Various work groups Communities of Interest (COIs) Formal or informal collaborative groups of users/organizations Aligned to a line of business or issues of common concern Introduction of two roles :

Data Architecture Subcommittee Vision Engage COIs in advancing the management of Federal data as a valued national asset. Authoritative knowledge center for: Best practices DRM Implementation solutions Strategies Frameworks Standards Policies, procedures, and other guidance Stewards of the FEA DRM and related documents Federal Data Broker

Communities of Interest (COI) Vision Each COI will implement the 3 pillar framework strategy. Business & Data Goals drive Information Sharing/Exchange (Services) Governance Data Strategy Data Architecture (Structure)

Implementation Examples

One Approach: Intelligence Community (IC) EA Relationship to the FEA Data Reference Model IC Data Architecture IC Conceptual Data Model IC Logical Data Models IC Metadata Standards FEA DRM Dimensions IC EA Products Context Description Sharing IC Technical Architecture Apps. Ref Architecture Data Services Ref. Architecture IC EA Artifacts Entities of Interest Subject Areas Entities of Interest Subject Areas Person (TWPDES) Organization (TBR) Facility (TBR) … Person (TWPDES) Organization (TBR) Facility (TBR) … Implementation Specifications and Guidance Search Retrieval Subscription Notification … Implementation Specifications and Guidance Search Retrieval Subscription Notification …

From Context to Description to Shared Data at Recreation One Stop Physical Model Schema (RIDB*) CREATE TABLE RECAREA (RECAREA_IDCHAR(12) NOT NULL, RECAREA_NMVARCHAR(50) NOT NULL PRIMARY KEY (RECAREA_ID)); CREATE UNIQUE INDEX XPKRECAREA ON RECAREA ( RECAREA_ID ASC); CREATE TABLE RECAREA_ACT (RECAREA_IDCHAR(12) NOT NULL, RECAREA_ACT_CDCHAR(2) NOT NULL, RECAREA_ACT_DESCVARCHAR(240) NULL, RECAREA_ACT_FEEVARCHAR(240) NULL); CREATE UNIQUE INDEX XPKRECAREA_ACT ON RECAREA_ACT ( RECAREA_IDASC, RECAREA_ACT_CDASC); XML Schema A recreational activity available at a Recreation Area. The code that denotes a specific kind of Recreational Activity. Information Exchange Package: RECREATION ACTIVITY QUERY Subject Area: RECREATION Information Class: RECREATION ACTIVITY RECREATION-AREA RECREATION-AREA IDENTIFIER RECREATION-AREA NAME RECREATION-AREA MAP URL TXT 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: RECREATION-ACTIVITY TYPE CODE Data Object: DOI Conceptual Data Entities (Standardized) REGISTRY ENTRY: RECREATION-ACTIVITY TYPE CODE 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 * RIDB = Recreation Information Database

DOI DRM Recreation Implementation Summary Requirements & ChallengesDOI DRM RoleOutcomes Needed a basis for data sharing among multiple Federal, State, Local & Commercial parties Share data from multiple business lines Translate data sharing to a database and XML Must be easily extensible to accommodate new requirements Provided a basis for requirements gathering and data analysis – Rapid Standardization Provided a mechanism for discussion and validation amongst data sharing partners Identification of data sharing opportunities Translation of conceptual analysis into database and XML Schema All parties agree to data sharing requirements – greatly increased collaboration Integrated data requirements and data sharing across business lines Extensibility proven through inclusion of Trails and Museum data standard Implemented single source of Recreation data and an XML Schema

Summary

Consistent implementation of the 3 pillar framework strategy among COIs Governance establishment are comprised of key roles: DAS and COIs Launched first monthly meeting of DAS in May 2006

Questions