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

Implementing the Federal Enterprise Architecture

Data Reference Model (FEA DRM)

“Build to Share”

How to Manage DataAcross Agencies

Using the FEA DRM

11 September 2006

Agenda

FEA DRM Basic Concepts

Three Pillar Data Strategy Framework

Federal Data Architecture Subcommittee

Agency DRM Implementation Examples

FEA DRM Concept

Data Sharing

Query Points and Exchange Packages

Query Points and Exchange Packages

Data Description

DataData

Data Context

TaxonomiesTaxonomies

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

FEA Data Reference Model (DRM) relationship with Other FEA Reference Models

The DRM relates to each of the 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 Approach(Summary)

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 DRM Abstract Model(Guidance for Organizing Information About Agency Data)

FEA DRM

Three Pillar Data Strategy Framework

The DRM Data Strategy Framework

Goals drive; governance controls; structure defines; and services enable data strategy.

Business &Data Goals drive

Information Sharing/Exchang

e(Services)

Information Sharing/Exchang

e(Services)

Governance

Data Strategy

Data Architecture(Structure)

The Rule: All 3 pillars are requiredfor an effectivedata strategy.

Special thanks to Laila Moretto and Forrest Snyder, MITRE Corp.

Data Strategy Framework Sample Elements

Governance

Data Transfer Standards

PedigreeAuthoritative Sources

Security/Protection Data

Discovery DataInventory

Definitions/SemanticsStructure

Syntax

Data Architecture (Structure)

Information Sharing/Exchange

(Services)

Use of specific elements depend on the goals

OversightPolicy & Procedures

Processes and PracticesEducation/Training

Issue ResolutionMetrics/Incentives

Access ServicesBrokering

Shared SpacesData Catalogs

Data Registries

Communities of InterestSearch

Mediation

Sample Data Management Goals and the Sample Elements of a Data Strategy

Visible

Understandable

Trusted

Interoperable

Responsive

Institutionalized

Data Goals:

Shared SpacesAccess Services

Data Catalogs

Communities of InterestSearch

Data Registries

Inventory

Metrics/Incentives

Policy & Procedures

Processes and PracticesEducation/Training

Discovery Data

StructureDefinitions/Semantics

PedigreeSyntax

Education/Training

Oversight

Authoritative SourcesSecurity/Protection DataData Transfer Standards

BrokeringMediation

Govern

ance

Data A

rchitectu

reIn

formation

Sh

aring

Accessible

Mapping the Sample Elements of the Strategy Framework to the

DRM

Data Contextenables…

Data Contextenables…

Data Descriptioncaptures…

Data Descriptioncaptures…

Data Sharingguides…

Data Sharingguides…

Governance Overview

Federal CIO Council Organization

Executive CommitteeDirector, Administrator of the Office of e-Government (OMB)

Chair, Deputy Director for Management (OMB)Vice Chair (Agency CIO)

Architecture &

Infrastructure CommitteeWorkforce & Human

Capital for IT CommitteeBest Practices Committee

Emerging Technologies

Subcommittee

Governance Subcommittee

Services Subcommittee Data Architecture

Subcommittee

The Federal Data Architecture Subcommittee is one of four subcommittees under theArchitecture and Infrastructure Committee.

The Federal Data Architecture Subcommittee is one of four subcommittees under theArchitecture and Infrastructure Committee.

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 revisions2. Implementation strategies, best practices, and success stories3. Establish an authoritative knowledge center for Federal data-

related issues and opportunities

Communities of Interest (COI) and Line of Business (LOB)

Vision

Each COI or LOB will implement the three pillar framework strategy and willfocus on business requirements.

Business &

Data Goals drive

Information Sharing/Exchange

(Services)

Governance

Data StrategyData Architecture

(Structure)

DRM Implementation

Examples

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)

DataGoals


(Challenge)

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Customers see too many sources for Federal recreation information.Customers see too many sources for Federal recreation information.


drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Financial-Transacti

on

Recreation AreaReservation

Event/IncidentRecreation Activity

Vendor Geospatial-Location

Country StateRiver

Location

Recreation Facility

Person

Organization

Descriptive-Location

Postal-Location

Sale

Trail

Permit

(Blue = Shared Data Concept)

Structure: High Percentage of Data Reuse Identified


drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Services: RecML is based on standards described in Recreation ERD

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 DENTIFIER

RECREATION-AREA NAMERECREATION-AREA MAP URL TEXT

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:

Dat

a E

lem

ent

Des

crip

tio

n


drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Services: Information Sharing Result


(Governance)

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

• 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)

DataGoals

ObjectiveProvide 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)

ScopeAddress Federal Executive Branch (FEB), with planned extensions into States, for all MEFs

CCA MetamodelThree Major Components

Environment/SituationThe Scenarios under which the D/As must operate

Operations/BusinessWhat the D/As must do in any given Scenario

InfrastructureThe facilities, communications systems, hardware/software, and other capabilities the D/As use to accomplish their priority missions Infrastructure

Operations/Business

En

viro

nm

ent/

S

itu

atio

n

CCA Structure:Metamodel Relationships

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Communications

Computing/Storage Platforms

Information Content

D/As

Applications

Reside on

Process

Store

Operations/Business

PMEFsNEFs Drive

Use

Perform

Require/Produce

Require/Produce

Geographic Locations

Reside at

Reside at

Information Representations

Connect

Described by

Exchanges

ScenariosDrive

Define

Effects

Affect

Affect

Other Orgs

Services

Enable

Infrastructure

Other Functions

Implement

Perform

Perform Reside at

Env

ironm

ent/

Situ

atio

n

Security Restricts

Protects

Facilities

Are Identified

With

CCA Analytical Toolsetdrive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

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

CCA Analysis drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

PMEF

INPUT 2 Secure Call

D/A # 1

Sup

port

s

Inputs required to perform PMEF

INPUT1 Report

Provides INPUT 1

Does NOT produce INPUT 2

NEF D/A # 2

D/A # 3

Sample PMEF Analysis Information Gaps

CCA Data Contextdrive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

“Information” is KeyWhat “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 AreasSeven 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.

Agency Initiative:HUD

HUDSingle Family Integration

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.

Project Mission:

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals


Challenges Legacy Data System

- System Focused - Data Duplication - Data Quality

ChallengesComplexity of Target Logical Data Model

- Functions being defined and refined - Capture of institution knowledge - Moving target

TargetLogical Data

Model

Legacy System

Legacy System

Legacy System

Data that is not used (obsolete)

Data that is redundant

Data that has been normalizedIn the Target LDM

Data that has been decomposedIn the Target LDM

Data elements – unknown?

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals


(Structure)

Registry consisting ofLegacy System ArchitectureTarget ArchitectureData & Service Mapping

Bi-directional Traceability

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals


(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

Cai

ro

Task 4Analyze Information

Flow

Task 2Data Standardization

Charter

Task 3Setup Registry

Task 5Create Data

Disposition Plan

Task 6Identify Authoritative

Data Sources

EA/S

FI T

eam

Identify Systems Review Info FlowReview

Disposition Plan

Review Authoritative Data

Sources

Information FlowDocument

Data Disposition Plan

Authoritative Data Sources

Data Migration Specification

Review Migration Plan

List of Systems

Recommendations

Legacy System Data Mapping forSingle Family Housing Overview

SF D

ata

Stan

dard

izat

ion

BoardCreation and

Setup

BoardMeeting

BoardMeeting

BoardMeeting

BoardMeeting

BoardMeeting

BoardMeeting

List of Systems

Task 7Create Data

Migration Plan

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

HUDSingle Family Integration(Information Exchange Services)

In early stage

Metadata Management

Oracle Middleware Connecting Software Applications

Exchanging Data

Leverage SOA to streamline information lifecycle

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Agency Initiative:EPA Central Data Exchange

(CDX)

EPACentral 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.

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals


(Requirements)Service Oriented Architecture (SOA) Framework

Standards Based

Strong Extensible Security Model

Utilizes Shared Services and Components

Interoperates Across Platforms

XML Schema Based ExchangesDeveloped from Data StandardsReuses Shared Schema Components

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

But increased reporting and data use led to more and more complexity

Universities

Tribes

Analysis and Access Systems

Program Data Repositories & Data Warehouses

Registries Program Silo 50+

Front End Data Collection Systems

Program Information Consumers



RegistriesProgram Silo 1






























Registries Program Silo 7




































































Industry

States

Local Govt

Citizens

Policy Makers

Legislators

Unmanageable Complexity

(>100 data flows withcustom formats and

processes

EPAChallenge

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

•Standards Driven Data Sharing,

•(not just data delivery)

Citizens

Policy Makers

Legislators

Universities

Tribes

Industry

States

Local Govt

EPASolution

Exchange Network

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

EPAExchange Network Governance

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals


(XML Schema Management)

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

EPAExchange Network Status

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

State PermitApplication

Substance Registry ServicesChemicalSubstanceRegistry LookupService

1.

Extracts Permit

2.

Quality Assurance

3.

Submit Service

4.

CDX

Multiple Internal ProcessingServices

5.

National Systems

Quality Assurance Service

Exchange Network Node

Leveraging Registries and Shared Services

EPAExample Service Integration

drive

(Services)

Gover-nance

Data Strategy

(Structure)

DataGoals

Contact Info for Each Implementation Example

Recreation One StopCharlie Grymes

E-mail: [email protected]

HUD – Single Family IntegrationBeverly Hacker


EPA – Central Data Exchange/Exchange NetworkMark Luttner


CCAGary Amato


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

Continue Work of Six DRM Work Groups1. DRM Governance

2. DRM Communications and Outreach

3. DRM ERP Harmonization

4. PERSON Harmonization

5. DRM Best Practices

6. XML Interoperability

What’s Next Continued

Engagement with various E-Gov Initiatives

Develop DRM version 3

Develop DRM Implementation Guide

What’s Next Continued

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: [email protected] Aucoin: [email protected]

Documents

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