fea drm akm 2005 03 28

Federal Enterprise Architecture (FEA) Mandate

OMB Reference Models, Data Reference Model (DRM) Initiatives, & AF iTRM

Amit K. Maitra (MITRE)HQ AF CIO-A

AF CIO-A Amit K. Maitra 2

Business Reference Model (BRM)• Lines of Business• Agencies, Customers, Partners

Service Component Reference Model (SRM)

Technical Reference Model (TRM)

Busin

ess a

nd P

erfo

rmance

-Driv

en

Appro

ach

Performance Reference Model (PRM)

• Inputs, Outputs, and Outcomes• Uniquely Tailored Performance Indicators

.

Federal Enterprise Architecture (FEA)

• Service Domains, Service Types• Business and Service Components

• Service Component Interfaces, Interoperability• Technologies, Recommendations

Data and Information Reference Model (DRM)• Subject Areas, Classifications, Data Elements, • Data Properties, Data Representations

Inte

rop

era

bility

/ Info

rmatio

n S

harin

g(B

usin

ess-C

onte

xt D

riven

)

The Federal Enterprise Architecture (FEA) is a business and performance-based framework to support cross-agency collaboration, transformation, and government-wide improvement


Underlying Theme

Fully integrated information systems for a shared data environment


Focus

Information, Access, Authorization, Emerging Technologies Data Accessibility, Commonality, and

Compatibility Design


Global Environment

Characteristics Geographically distributed, dissimilar elements

of varying capabilities and responsibilities Data distributed to and redistributed among

system facilities, interconnected by both private and shared public communications networks


Revolutionary Moments: The Mandate

“Our success depends on agencies working as a team across traditional boundaries to serve the

American people, focusing on citizens rather than

individual agency needs.” ~ President George W.

Bush


No common framework or methodology to describe the data and information that supports the processes, activities, and functions of the business

No definition of the handshake or partnering aspects of information exchange

Existing systems offer diffused content that is difficult to manage, coordinate, and evolve

Information is inconsistent and/or classified inappropriately

Without a common reference, data is easier to duplicate than integrate

No common method to share data with external partners

Limited insight into the data needs of agencies outside the immediate domain

Data and Information context is rarely defined Stove piped boundaries, no central registry Lack of funding and incentive to share Data sensitivity and security of data New laws/issues result in continuous adding of

databases that can not share data

Primary Issues and Information Sharing Barriers

The Current Situation: The Federal Government is less than efficient in performing its business and meeting customer needs

due to data sharing inefficiencies caused by stove-piped data boundaries

Stove-Piped Data Boundaries“As Is State”

Have C

reate

d

HHS

INDUSTRY

Illustrative

Illustrative

CDC

DHS

TSA

USDA

DOI

ENERGY

LABOR

FDA INS

Denotes data and information sets within agencies.


The Solution: The Data Reference Model (DRM)

Subject Area

Data Object

DataProperty

DataRepresentation

DataClassification

The DRM provides:

A framework to enable horizontal and vertical information sharing that is independent of agencies and supporting systems

A framework to enable agencies to build and integrate systems that leverage data from within or outside the agency domain

A framework that facilitates opportunities for sharing with citizens, external partners and stakeholders


Pilot Project

Integrate DOJ and DHS data Explore governance evolution Explore framework evolution Collaborative funding by DOJ and DHS


National Information Exchange Model

(NIEM)


Institutionalizing Information Sharing

Business Information Exchange Reference Model Incorporates XML Messaging, Federated Query, and Business Rule

Execution to solve business problems


Process

Facilitate growth of data model through harmonization of new data components

Coordinate independent project teams within DOJ and DHS

Provide effective support and assistance for practitioners Facilitate discovery of reusable data components Facilitate assembly of exchange packages


CORE = Common


Core Data Type ExamplePERSON

Person Id

Person NamePerson AddressPerson Date Of BirthPerson GenderPerson EthnicityPerson Race

TWPDES-PERSON

Person Id (FK)

Person EducationPerson Physical DescriptionPerson KinshipPerson MedicalPerson SkillPerson Agency Interest

DOJ-PERSON

Person Id (FK)

Person Driving IncidentPerson Drivers LicensePerson AcquaintancePerson Day ContactPerson Evening ContactPerson Adopted ChildPerson Adoptive ParentPerson Gang AffiliationPerson Affiliation OrganizationPerson ChargePerson Detained Location

ICE-PERSON

Person Id (FK)

Alien NumberAlert CodePhoto CodeFinger PrintEntry DateFamily HealthFamily DetailEmployment Authorization

DOD-PERSON

Person Id (FK)

Person Eye ColorPerson Usual WeightPerson Hair ColorPerson Birth TimePerson Total Dependent QuantityPerson Adult Dependent Quantity

IAIP-PERSON

Person Id (FK)

Person Personal AttributesPerson Physical DescriptorsPerson EmploymentPerson CapabilitiesPerson AffiliationsPerson Possessions


Governance View

Core

U-Core

User Organizations

COIsUC Committee


Information Sharing Use Case (1)

Markle Report—http://www.markle.org/ “Creating a Trusted Network for Homeland Security”

Vignette 3 Scenario—terrorists planning an attack using rail lines and chlorine

gas



Agency X collects data Using the DRM, Agency X creates metadata that

describes this data in an unambiguous manner

Rail Yard

Terrorist Organization: + name: “Al Qaeda”

Incident + when + where + what + who

Zoo

Person

Chemical Plant

Terrorist

Terrorist Organization + name

Chemical + name

Chemical + name: “Chlorine”



Agency Y needs data to perform analysis Agency Y discovers Agency X has the data it needs

TargetTarget

OrganizationOrganization

IndicatorsIndicators

VulnerabilityVulnerability CapabilityCapability

LawEnforcement

LawEnforcement

IntelIntel

Lethal AgentLethal Agent

FacilityFacility

LOBLOB

InfrastructureProtection




Agency Y and Agency X assemble exchange packages

Incident Report + who + what + when + where + activity

HUMINT Report

Threat Report

Target CapabilityPolice

IncidentInfrastructure

Incident

Critical Noncritical

ChemicalPlant Rail Yard Zoo



Data is exchanged

CIA

Rail Yard

Police Dept.

Zoo

Chemical Plant



IntelIntel

LawEnforcement

LawEnforcement

Law AnalysisCenter

Industry Analysis Center

States

Shared Space

DHS

Threat Report

Incident

Incident

Incident

Incident

NCTC

DHS

DHS



Data is associated in a shared space

Shared Space

Threat Report 1

Capability: Chlorine Gas

Target: Rail Lines

Incident 2: Police

Incident 3: Chemical

Incident 1: Zoo

Incident 4: Rail Yard


OMB Inter-Agency DRM WG Position XML does not express rich semantics Need stronger languages

RDF OWL MOF

These have XML representation Their particular types add a lot


For Better Understanding of Our Data

A Gentle Transition From XML to Resource Description Framework (RDF)

The purpose of RDF is to give a standard way of specifying data “about” something

Advantage of using RDF

If widely used, RDF will help make XML more interoperable

Promotes the use of standardized vocabularies ... standardized types (classes) and standardized properties

Provides a structured approach to designing XML documents

The RDF format is a regular, recurring pattern

Quickly identifies weaknesses and inconsistencies of non-RDF-compliant XML designs

Helps us better understand our data!

Positions data for the Semantic Web!


Web Ontology Language (OWL)

RDF has limited expressive capability-- Mostly limited to taxonomic descriptions

The things we model have complex relationships so we need to capture many different facets, or restrictions on class and property descriptions


DRM Volume Strategies

OMB Inter-Agency DRM position is being captured in: Volume I: DRM Overview Volume II: DRM Management Strategy Volume III: Data description Volume IV: Data Sharing Volume V: Data Context


Infostructure-Technical Reference Model (i-TRM) Provides a common conceptual framework Defines a common vocabulary

Services, domains, sub-domains, interfaces, and their relationships

Diverse components within the Air Force can better integrate acquisition, development, and

implementation activities in regards to the Air Force Inforstructure


Infostructure-Technical Reference Model (i-TRM) Provides an extensive set of service definitions and relationships

Increase interoperability Improve compatibility Enhance warfighter capabilities Resolve related issues.

DOD C4ISR Architecture Framework compliant approach for modeling the technical information of the Enterprise and Infostructure Architectures.

Describes the main components of an information system, the applications, and the infostructure, itself, as a set of domains and services categorized by functional area.

These service areas can be implemented on a: Single component Collection of homogeneous or heterogeneous systems that

comprise the AF Infostructure.

fea drm akm 2005 03 28

Technology