Architecture and Infrastructure Committee AIC

1
Architecture and Infrastructure Committee (AIC)

• Briefing to FOSE 2003

April 9, 2003
2
AIC Objectives

• Integrate OMB and CIOC Architecture Efforts
• Develop (simpler) and Consistent Taxonomy and
  Terminology
• Facilitate Cross-agency efforts common meta
  data, tools
• Oversee operationalization of architecture
  efforts

A new subcommittee structure was developed to
support these objectives
3
New AIC Structure
AIC Laura Callahan, DHS John Gilligan, USAF
Norm Lorentz, OMB
Move from ad hoc efforts to priority and
schedule-driven efforts with committed staff
Governance John Przysucha, DOE Bob Haycock, FEAPMO
Components Reynolds Cahoon, NARA Bob Haycock,
FEAPMO
Emerging Tech. Dawn Meyerriecks, DISA Mark Day,
EPA
Working Groups
XML - Marion Royal, GSA Owen Ambur, DOI
PKI - Judith Spencer, GSA
XML Web Services - Brand Niemann, EPA
Universal Access - Susan Turnbull, GSA
4
CIO Council has established expectations for
federal agency participation in AIC

• Agencies have begun designating senior-level
  representatives to the Governance and Components
  Subcommittees (25 time commitment per
  subcommittee).
• Volunteers have begun populating the Emerging
  Technology Subcommittee and its ongoing working
  groups.
• Subcommittee participation contributes to
  executive development objectives of CIOC.

AIC products will benefit all agencies and
accelerate achievement of CIOC goals
5
Enterprise Architecture Governance Subcommittee

• Leadership John Przysucha, DOE Bob Haycock,
  OMB
• Subcommittee Mission
• Develop policy, direction and guidance by which
  the Federal Enterprise Architecture (FEA) is a
  driver of business process improvement,
  investment management, and technical decisions in
  order to institutionalize the FEA throughout
  Government
• Assist in implementing the FEA and other
  Enterprise Architectures (EAs) throughout
  Government
• Three Subcommittee Goals
• Integrate EA into the Governments management
  processes
• Define the alignment of department/agency EAs
  with the FEA
• Describe how the FEA will facilitate the
  connection of State and Local EAs to Federal
  business lines and agency architectures
• Recent Progress
• Subcommittee members selected and subcommittee
  activated
• FY 2003 work plan completed

6
Enterprise Architecture Governance Subcommittee
Tasks

• Develop FEA Principles
• Integrate EA into the Capital Planning and
  Investment Control Process
• Integrate EA into the Strategic Management and
  Budget Formulation/Execution Processes
• Integrate EA into the Project Management,
  Workforce Planning and Security Management
  Processes
• Determine the major EA frameworks used by
  Federal agencies
• Analyze how agencies align with the emerging
  FEA
• Propose a federated FEA model that complements
  agency EAs
• Develop a Government Enterprise Architecture
  Framework
• Conduct a Joint Architecture Integration Pilot
• Conduct a Joint Component Directory/Repository
  Pilot
• Develop a Joint Government Data and Information
  Reference Model
• Identify new approaches to Joint Enterprise
  Software Licensing
• Conduct expanded Joint Architecture Integration
  Pilots

Mission-related
Goal 1 Integrate EA into the Governments Manage
ment processes
Goal 2 Define alignment of department/ agency
EAs with FEA
Goal 3 Describe how the FEA will facilitate the
connection of State and Local EAs to Federal
business lines and agency architectures
7
Components Subcommittee

• Leadership Reynolds Cahoon, NARA Bob Haycock,
  OMB
• Draft Subcommittee Mission
• Foster the identification, maturation, and re-use
  of enterprise architecture components and
  component-based enterprise architectures in
  Government
• Draft Subcommittee Goal
• Facilitate cross-Agency development and
  implementation of enterprise
  architecture components
• Recent Progress
• Subcommittee members selected and subcommittee
  activated
• FY 2003 workplan completed four tasks
  identified
• Develop a Components Based Architecture
  White Paper
• Develop a Components Registry/Repository
  Concept Paper
• Develop a Solution Development Life Cycle
• Develop and Market Quick Win

An Enterprise Architecture Component
is defined as "a self contained
business process or service
with predetermined functionality
that may be exposed through a business
or technology interface."
8
Emerging Technology

• Leadership Mark Day, EPA Dawn Meyerriecks,
  DISA
• Goal Coordinate and guide technology tracking
  efforts of the federal government. Accelerate
  the implementation of commercially-developed
  technology resolving common challenges
• Initial Objectives
• To provide a clearinghouse function between
  industry and agencies
• To help discover and close technological gaps in
  the federal business and technology
  infrastructure
• Recent progress
• Activation of the subcommittee
• Development if initial draft 2003 work plan

9
Architecture and Infrastructure Committee
Interrelationships
Industry
Opportunities for Public-Private Interactions
Inherently Governmental Functions
ComponentsSRMTRM DRM
GovernancePRMBRM
EmergingTechnology
Component Voids Candidate Components
Priorities Policy Recommendations
10
FEA - Program Management Office Reference Model
Release Schedule
11
Development of the Draft BRM, Version 2.0 is
nearing completion
DRAFT Business Reference Model, Version 2.0
12
The Draft BRM, Version 2.0 aligns with three
critical management frameworks / improvement
initiatives

• The Presidents Budget and Performance
  Integration Initiative and the FEA Performance
  Reference Model
• The revised model differentiates between the
  purpose of the government and mechanism/process
  used to deliver services to the customer
• This distinction aligns with the Performance
  Reference Models focus on outcomes (purpose of
  government) and outputs (mechanism/process)
• OMBs Budget Function Classifications
• These classifications provide a similar
  functional description of Federal activities
• JFMIPs New Framework for Financial Management
  Systems
• Within the revised BRM, financial management is
  an element of the Lines of Business and
  Sub-functions throughout the four Business Areas
• The core processes of financial management - as
  defined by JFMIP - have been incorporated into
  the models Financial Management Line of Business

13
Within the Draft BRM, Version 2.0, Mode of
Delivery and Services for Citizens should be
thought of collectively

• What is the purpose of government?
• What outcomes is the government hoping to
  achieve?

Services for Citizens

• What mechanisms does the government use to
  achieve these outcomes?
• What are the outputs of these processes?

Mode of Delivery
With this relationship in place, all Government
programs, agencies, mission-related IT systems,
etc., can be aligned to both a Service for
Citizens and a Mode of Delivery
14
The Draft FEA Performance Reference Model
(PRM)At-A-Glance
15
The PRM will help agencies identify the
performance improvement opportunities that will
drive Government transformation
16
The PRM structure is designed to clearly
articulate Line of Sightthe cause and effect
relationship between inputs, outputs and outcomes
17
The Draft Service Component Reference Model (SRM)
framework is comprised of three inter-related
service-oriented tiers each of which describes
capabilities in greater levels of granularity
Service Domain The collection of business
oriented service categories that align service /
component capabilities to a level in which they
support the objectives and performance of the
business.
7 Service Layers
Service Types A collection of business-driven,
service types (or categories) that assist the
Service Layer in accomplishing of mission and/or
performance objectives.
Level of Granularity
29 Service Types
Service Components The collection of components
and/or capabilities that support the Service Type.
163 Service Components
18
The SRM is a business-driven, functional
framework that classifies capabilities (or
service components) according to how they support
business and performance objectives
Access and Delivery Channels
Business Process
Performance Measures
Service Types
Customer Services
Process Automation Services
Business Management Services
Cross-Cutting Service Areas (i.e., Search,
Security)
Support Services
Digital Asset Services
Service Components
Business Analytical Services
Back Office Services
Service Domain
19
The SRM is supported by multiple access and
delivery channels that provide a foundation for
accessing and leveraging the Service Component
Accessing the Component (Example Renewal of
Drivers License )
Access Channels (FEA-TRM)
Mobile, Wireless
Web Browser
PDA
Kiosks
Private/Public Partnership
Other
System to System
EAI
Web Service
Phone, Fax
Delivery Channels (FEA-TRM)
Intranet
Extranet
Peer to Peer
Internet
Mail
Face to Face
Portal
Marketplace
Exchange
Commerce
Integration
Service Level Agreement to structure how Service
Components are accessed and leveraged
Service Domains Service Types, and Service
Components (FEA-SRM)
20
The SRM will assist in defining business process
and performance gaps that may be leveraged to
improve services to stakeholders (citizens,
business partners, agencies)
Access Channels (FEA-TRM)
Access Channels (FEA-TRM)
Delivery Channels (FEA-TRM)
Delivery Channels (FEA-TRM)
What level of process, performance, and outcome
is the Service Component achieving? Does this
help to close a performance gap?
Performance Measures (FEA-PRM)
Business Process
Performance Measures
Service Domains Service Types, and Service
Components (FEA-SRM)
21
The Draft Technical Reference Model (TRM) is
comprised of three technical tiers to support the
construction, exchange, and delivery of service
components
FEA TRM Technical Tiers
How to leverage and access Service Components
Service Access and Delivery The collection of
Access and Delivery Channels that will be used to
leverage the Service Component, and the
Legislative Requirements that govern its use and
interaction
How to build, deploy, and exchange Service
Components
Service Framework The underlying foundation and
technical elements by which Service Components
are built, integrated and deployed across
Component-Based and Distributed Architectures.
How to support and maintain Service Components
Service Platform A collection of platforms and
specifications that embrace Component-Based
Architectures and Service Component reuse
22
The TRM provides an effective means by which
service components can be leveraged, built, and
deployed across the Federal Government
Service Access and Delivery
How to leverage and access Service Components
How to build, deploy, and exchange Service
Components
Service Framework
How to support and maintain Service Components
Service Platforms
Service Platforms
23
The TRM will provide guidance and recommendations
that support the development and implementation
of service components that embrace a
Component-Based Architecture
Partial List
Security
Component Architecture

• X.509
• NIST / FIPS 186
• Secure Socket Layers (SSL)

Security
Presentation / Interface
Business Logic
Presentation / Interface
Data Interchange

• HTML
• JSP, ASP, ASP.Net
• DTHML, CSS, XHTMLMP

Data Management
Data Management
Business Logic
Data Interchange

• XML
• ebXML
• RDF, WSUI
• XSLT

• Java/J2EE (EJB)
• C, C, JavaScript
• COM/COM, C
• Visual Basic

• XBRL, JOLAP, OLAP
• JDBC, ODBC
• ADO, ADO.Net

24
The goal of the Draft Data and Information
Reference Model (DRM) is to support investment
and E-Gov planning by providing a framework in
which agencies can leverage existing data
components across the Federal Government
Goals and Objectives

• Promote horizontal and vertical information
  sharing between business lines
• Business-focused data standardization that can be
  categorized for re-use
• Re-Use and integration of data as opposed to
  duplication
• Enabler to support Cross-agency collaboration
• Facilitate Cross-agency information exchanges
• Consistent means to categorize and classify data

Integrated Enterprise
Agency 1
Agency 2
FEA-DRM
State
Local
Agency 3
Agency 4
25
The DRM framework provides a consistent method of
categorizing and describing the data supporting
the Business Lines and Sub-Functions of the BRM
Conceptual
FEA-BRM (Business Functions / Sub-Functions)
Classifications
DRM Framework Focus Points

• Based on ISO 11179
• Will heavily leverage XML and interoperability
  principles
• Classifications of data will form the basis for
  the definition of business-driven XML Schemas
• Will leverage industry vocabularies
• XML Schemas will be stored within a central
  repository (e.g.., XML.Gov, FEAMS)
• Security and data privacy are TOP priorities
• Will provide effective means to communicate with
  State and local governments

Criminal Suspects
Illegal Aliens
Terrorist Activity
Apprehensions
Events
26
Questions and Answers
27
Contact Information