Federal Enterprise Architectureen.wikipedia.org | Jan 29th 2011 10:43 PM
Federal Enterprise Architecture (FEA) is the Enterprise Architecture of a Federal Government. It provides a common methodology for information technology (IT) acquisition, use, and disposal in the Federal government.
Enterprise Architecture (EA) is a management practice for aligning resources to improve business performance and help agencies better execute their core missions. An EA describes the current and future state of the agency, and lays out a plan for transitioning from the current state to the desired future state. Federal Enterprise Architecture is a work in progress to achieve these goals.
The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S. Office of Management and Budget that aims to comply with the Clinger-Cohen Act and provide a common methodology for information technology (IT) acquisition in the United States federal government. It is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services.
HistoryIn September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1 for developing an Enterprise Architecture (EA) within any Federal Agency for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that cross organizational boundaries, among others the NIST Enterprise Architecture Model. The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government.
These Federal architectural segments collectively constitute the Federal Enterprise Architecture. In 2001, the Federal Architecture Working Group (FAWG) was sponsoring the development of Enterprise Architecture products for trade and grant Federal architecture segments. Method—a prescribed way of approaching a particular problem. As shown in the figure, the FEAF partitions a given architecture into business, data, applications, and technology architectures. The FEAF overall framework created that time, see image, includes the first three columns of the Zachman Framework and the Spewak's Enterprise Architecture Planning methodology.
Reference modelsMain article: Reference Model
The FEA is built using an assortment of reference models, that develop a common taxonomy and ontology for describing IT resources. These include the, see image:
- Performance Reference Model,
- Business Reference Model,
- Service Component Reference Model,
- Data Reference Model and
- Technical Reference Model.
Performance Reference Model (PRM)
The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes:
- Help produce enhanced performance information to improve strategic and daily decision-making;
- Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear “line of sight” to desired results; and
- Identify performance improvement opportunities that span traditional organizational structures and boundaries
- Mission and Business Results
- Customer Results
- Processes and Activities
Business Reference Model (BRM)Main article: business reference model
The "FEA Business Reference Model" is business reference model, a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them. This business reference model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government using a functionally driven approach. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology.
The BRM is broken down into four areas:
- Services For Citizens
- Mode of Delivery
- Support Delivery of Services
- Management of Government Resources
While the BRM does provide an improved way of thinking about government operations, it is only a model; its true utility can only be realized when it is effectively used. The functional approach promoted by the BRM will do little to help accomplish the goals of E-Government if it is not incorporated into EA business architectures and the management processes of all Federal agencies and OMB.
Service Component Reference Model (SRM)
The Service Component Reference Model (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM is intended for use to support the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services.
The SRM establishes the following domains:
- Customer Services
- Process Automation Services
- Business Management Services
- Digital Asset Services
- Business Analytical Services
- Back Office Services
- Support Services
Data Reference Model (DRM)Main article: Data Reference Model
The Data Reference Model (DRM) describes, at an aggregate level, the data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within the Federal government and between government and external stakeholders.
Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document:
- Provides an introduction and high-level overview of the contents that will be detailed in Volumes 2-4 of the model;
- Encourages community of interest development of the remaining volumes; and
- Provides the basic concepts, strategy, and structure to be used in future development.
Technical Reference Model (TRM)
The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective.
The TRM consists of:
- Service Areas : represent a technical tier supporting the secure construction, exchange, and delivery of Service Components. Each Service Area aggregates the standards and technologies into lower-level functional areas. Each Service Area consists of multiple Service Categories and Service Standards. This hierarchy provides the framework to group standards and technologies that directly support the Service Area. (Purple headings)
- Service Categories : classify lower levels of technologies and standards with respect to the business or technology function they serve. In turn, each Service Category comprises one or more Service Standards. (Bold-face groupings)
- Service Standards : define the standards and technologies that support a Service Category. To support agency mapping into the TRM, many of the Service Standards provide illustrative specifications or technologies as examples.(Plain text)
Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in a hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and application Service Components that may be used and leveraged in a component-based or service-oriented architecture.
FEA Architecture levelsIn the FEA enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture:
- Enterprise architecture,
- Segment architecture, and
- Solution architecture.
By contrast, "segment architecture" defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles:
- structure: segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service.
- reuse : segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies.
- alignment : segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures.
FEA toolsA number of modeling tools enable you to capture the Federal Enterprise Architect reference models and align your enterprise architecture against them; some of these are listed below.
- Adaptive Inc. 
- Future Tech Systems, Inc.
- IBM (formerly Telelogic) System Architect (software)
- Troux Technologies Architect
- Iteraplan - Open Source EA Tool
- Business reference model
- Department of Defense Architecture Framework
- FDIC Enterprise Architecture Framework
- Reference model
- Treasury Enterprise Architecture Framework
- FEA with ADOit
- Baldrige Performance Excellence Program
- ^ a b c d e f g h i j k l m n FEA Consolidated Reference Model Document. at whitehouse.gov May 2005. This document is revised to FEA Consolidated Reference Model Document Version 2.3 October 2007. Accessed 28 April 2009.
- ^ a b c Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture. Feb 2001.
- ^ a b c d e f Federal Enterprise Architecture Program Management Office (2007). FEA Practice Guidance.
- ^ Overall the FEA is mandated by a series of federal laws and mandates. These federal laws have been:
- GPRA 1993 : Government Performance and Reform Act
- PRA 1995 : Paperwork Reduction Act
- CCA 1996 : Clinger-Cohen Act
- GPEA 1998 : The Government Paper work Elimination Act
- FISMA 2002 : Federal Information Security Management Act
- E-Gov 2002 : Electronic Government
- A-11 : Preparation, Submission and Execution of the Budget
- A-130 : OMB Circular A-130 Management of Federal Information Resources
- A-76 : Performance of Commercial Activities.
- ^ a b FEA (2005) FEA Records Management Profile, Version 1.0. December 15, 2005.
- ^ 
- ^ Envision VIP
- e-gov FEA Program Office webpage
- Federal Enterprise Architecture Institute website
- Federal Chief Information Officers Council website
- ASD(NII)/DoD CIO Enterprise Architecture Summary
Shared from Read It Later
Sent from my iPad | ross | email@example.com |