Overview of theFederalEnterpriseArchitecture

8618 Westwood Center DriveSuite 310Vienna, Virginia 22182Ph: (703) 827-0638Fax: (703) 734-0987

© 2004 Blueprint Technologies, Inc. All Rights Reserved

Presented by Craig MillerDirector of Enterprise Planning Solutions

2© 2004 Blueprint Technologies, Inc. All Rights Reserved

Agenda

• Introducing the Federal Enterprise Architecture

• The FEA Reference Models– Business

– Performance

– Technical

– Service Component

– Data and Information

• Applying the FEA– FEA or FEAF?

– Benefits

– Limitations

3© 2004 Blueprint Technologies, Inc. All Rights Reserved

Introducing the Federal Enterprise Architecture

• The Federal Enterprise Architecture to develop an enterprisearchitecture framework for federal agencies

• The FEA is the responsibility of the Office of Managementand Budget with input from the federal CIO Council

• OMB statement: “The FEA is a tool that enables the FederalGovernment to identify opportunities to leverage technology andalleviate redundancy, or to highlight where agency overlap limitsthe value of IT investments”

• It is a framework designed to help agencies identifyopportunities for business improvement via standardization,interoperability, consolidation, data sharing

• All major agency IT investments are required to documenthow they align to the FEA (OMB Exhibit 300)

4© 2004 Blueprint Technologies, Inc. All Rights Reserved

FEA Reference Models Overview

• The FEA consists of five related reference models thatdescribe enterprise domains that may benefit fromstandardized taxonomies to facilitate improvements tobusiness processes

5© 2004 Blueprint Technologies, Inc. All Rights Reserved

The Business Reference Model (BRM)

• The BRM is considered to be the foundation of the FEA

• Provides astandardizedtaxonomy of businessservices

– Business areas

– Lines of business

– Business sub-functions

• Goal: promote cross-agency collaboration

• Related FEA initiativesunderway to describebusiness processes indetail for specificdomains (healthcare,finance, etc.)

6© 2004 Blueprint Technologies, Inc. All Rights Reserved

The Performance Reference Model (PRM)

• The PRM exists to provide a “line of sight” between ITinvestments and the agency programs they support

• PRM definesgenericperformancemeasurementareas,categories andindicators

• Up to agenciesto definespecificperformancegoals andmetrics

7© 2004 Blueprint Technologies, Inc. All Rights Reserved

The Service Component Reference Model (SRM)

• The SRM is based on the idea of “service components” thatlink IT services to business processes

• SRM provides the linkagebetween the business andtechnical views of theenterprise architecture

• Service componentsrepresent opportunities fororganizational reuse

8© 2004 Blueprint Technologies, Inc. All Rights Reserved

The Technical Reference Model (TRM)

• The TRM provides astandardizedtaxonomy forservices,specifications andtechnologies

• It does NOT dictatewhichspecs/standardsshould be adoptedby an agency

9© 2004 Blueprint Technologies, Inc. All Rights Reserved

The Data and Information Reference Model (DRM)

• The DRM provides a standardized taxonomy of dataclassifications that can be used to identify opportunities fordata sharing and exchange

• FEA PMO will provide common datasubject areas

• Agencies / communities of practicewill define information exchangepackages and data objects

• DRM is incomplete and currently indraft form only

– Data concept taxonomy defined

– No standardized descriptions of data areasor subject types yet

10© 2004 Blueprint Technologies, Inc. All Rights Reserved

FEA or FEAF?

– More ambitious scopethan FEA

– Less detail (nostandardizedtaxonomies)

– More emphasis on theprocess of developingan EA (baseline andtarget architectures,sequencing plans)

• The two frameworksmay be harmonizedby OMB/ CIO Councilin the future

The Federal Enterprise Architecture Framework was aprevious initiative to provide a standardized govt. EAframework

11© 2004 Blueprint Technologies, Inc. All Rights Reserved

FEA Benefits

• FEA takes an important step to defining standardizedtaxonomies for several important facets of an enterprisearchitecture

• Ongoing initiative that is expanding into additional EA areas:– Security profile

– Detailed EA “drilldowns” through specific sectors

• Documenting FEA alignment a prerequisite for funding majorfederal IT initiatives

• Adoption likely to spread beyond federal agencies (e.g.states, perhaps private sector)

• Some tool support in progress

12© 2004 Blueprint Technologies, Inc. All Rights Reserved

FEA Limitations

• High-level and generic

– Designed to apply across all agencies

– In most cases you must define more concrete elements thatare specific to your organization’s needs

• NOT a complete enterprise architecture framework

– Does not address important aspects of strategy, stakeholders,business activities, infrastructure, workforce, facilities, etc.

• NOT a process for developing an enterprise architecture– Does not describe how to differentiate between baseline and target

architecture development

– Does not describe how to develop a transition plan

– Does not describe best practices for EA

13© 2004 Blueprint Technologies, Inc. All Rights Reserved

For More Information

• FEA Program Management Office site:http://www.feapmo.gov

– Reference models

– Latest news and developments

– OMB Guidance

• Chief Information Officers Council site:http://www.cio.gov/Enterprise Architecture

– Guidance on applying EA

– Older FEAF materials

• Blueprint Technologies:http://www.blueprinttech.com

– “Best Practices in Enterprise Architecture” whitepaper

14© 2004 Blueprint Technologies, Inc. All Rights Reserved

Questions?

•Thank you!