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

Query Points and Exchange Packages

Data Description

Data Elements Data Elements

Data Context

Taxonomies (Categories)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 ContextBusiness Context

Subject AreaSubject Area

Information ClassInformation Class

Information Exchange & Query Points

Information Exchange & Query Points

Data Description

Data Representation Data Representation

StructuredStructured

Semi-structuredSemi-structured

UnstructuredUnstructured

The broad categories of data that support business processes of a line of business or community of interest.

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.

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.

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.

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 e-mail.Data that has characteristics of both structured and unstructured data, such as an e-mail.

Data that is of more free-form format, such as multimedia files, images, sound files, or unstructured text.

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 ElementData Element

Data ObjectData Object

Data PropertyData Property

Data RepresentationData Representation

The DRM Approach(A Reader’s 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 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”

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 requiredfor an effectivedata strategy.

Data Strategy Framework Elements

OversightPolicy & Procedures

Processes and PracticesEducation/Training

Issue Resolution

Governance

Data Transfer Standards

PedigreeAuthoritative Sources

Security/Protection Data

Discovery DataInventory

Definitions/SemanticsStructure

Syntax

Data Architecture (Structure)

Access ServicesBrokering Services

Shared SpacesData Catalogs

Data Registries

Communities of InterestSearch

Information Sharing/Exchange

(Services)

Data Strategy

Metrics/Incentives

Mediation

Broker

Mapping the Strategy to the DRM

Data Contextenables…

Data Contextenables…

Data Descriptioncaptures…

Data Descriptioncaptures…

Data Sharingguides…

Data Sharingguides…

DRM Governance Strategyfor

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 CIOC’s 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 SubcommitteeVision

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 StrategyData Architecture

(Structure)

Implementation

Examples

One Approach: Intelligence Community (IC) EA Relationship

to the FEA Data Reference Model

IC Data ArchitectureIC Data Architecture

IC Conceptual Data Model

IC Conceptual Data Model

IC Logical Data Models

IC Logical Data Models

IC Metadata Standards

IC Metadata Standards

FEA DRMDimensions

IC EAProducts

Context

Description

Sharing

IC Technical ArchitectureIC Technical Architecture

Apps. Ref Architecture

Apps. Ref Architecture

Data Services Ref. Architecture

Data Services Ref. Architecture

IC EAArtifacts

• 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_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_ID CHAR(12) NOT NULL, 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:annotation> <xs:documentation>The code that denotes a specific kind

of Recreational Activity.</xs:documentation> </xs:annotation> </xs:element>

Information Exchange Package: RECREATION ACTIVITY QUERY

Subject Area: RECREATION

Information Class: RECREATION ACTIVITY

RECREATION-AREA

RECREATION-AREA IDENTIFIER

RECREATION-AREA NAMERECREATION-AREA MAP URL TXT

RECREATION-AREA IDENTIFIER (FK)RECREATION-ACTIVITY TYPE CODE

RECREATION-AREA-ACTIVITY DESCRIPTION TEXTRECREATION-AREA-ACTIVITY FEE DESCRIPTION TEXT

RECREATION-AREA-ACTIVITY

A1|AIR-HANG GLIDINGB1|BOATING-SAILINGB2|BOATING-CANOEINGB3|BOATING-KAYAKINGC1|CAMPING-CAMP SITESC2|CAMPING-FREE SPACEH1|HIKING-TRAILSH2|HIKING-FREE RANGES1|SWIMMING-LAKE, PONDS2|SWIMMING-POOL

DOMAIN:RECREATION-ACTIVITY TYPE CODE

Data Object:

DOI Conceptual Data Entities (Standardized)

REGISTRY ENTRY:RECREATION-ACTIVITY TYPE CODE

DATA TYPE: CHARACTERLENGTH: 2DEFINITION:

The code that denotes a specific kind of Recreational Activity

CLASS WORD: CODE

METADATA REGISTRY/REPOSITORYGlossary of Metadata

Data Property:

DOI Conceptual Data Elements (Standardized)

Data Representation:

Da

ta E

lem

en

t D

es

cri

pti

on

*RIDB = Recreation Information Database

DOI DRM Recreation Implementation Summary

Requirements & Challenges DOI DRM Role Outcomes

Needed a basis for data sharing among multiple Federal, State, Local &

Commercial parties

Needed a basis for data sharing among multiple Federal, State, Local &

Commercial parties

Share data from multiple business lines

Share data from multiple business lines

Translate data sharing to a database and XML

Translate data sharing to a database and XML

Must be easily extensible to accommodate new

requirements

Must be easily extensible to accommodate new

requirements

Provided a basis for requirements gathering and

data analysis – Rapid Standardization

Provided a basis for requirements gathering and

data analysis – Rapid Standardization

Provided a mechanism for discussion and validation

amongst data sharing partners

Provided a mechanism for discussion and validation

amongst data sharing partners

Identification of data sharing opportunities

Identification of data sharing opportunities

Translation of conceptual analysis into database and XML

Schema

Translation of conceptual analysis into database and XML

Schema

All parties agree to data sharing requirements – greatly

increased collaboration

All parties agree to data sharing requirements – greatly

increased collaboration

Integrated data requirements and data sharing across business

lines

Integrated data requirements and data sharing across business

lines

Extensibility proven through inclusion of Trails and Museum

data standard

Extensibility proven through inclusion of Trails and Museum

data standard

Implemented single source of Recreation data and an XML

Schema

Implemented single source of Recreation data and an XML

Schema

Summary

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