World Library  
Flag as Inappropriate
Email this Article
 

Federal enterprise architecture

A federal enterprise architecture (FEA) is the

  • e-gov FEA Program Office webpage
  • Federal Enterprise Architecture Institute website
  • Federal Chief Information Officers Council website
  • DoD CIO Enterprise Architecture & Standards

External links

  1. ^ a b c d e f g h i j k l m n FEA Consolidated Reference Model Document.FEA Consolidated Reference Model Document Version 2.3 October 2007. Accessed 28 April 2009.
  2. ^ a b c d e f Federal Enterprise Architecture Program Management Office (2007). FEA Practice Guidance.
  3. ^ a b c Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture. Feb. 2001.
  4. ^ FEA Consolidated Reference Model Document.Federal Enterprise Architecture Framework version 2 January 29, 2103. Accessed 2 April 2015.
  5. ^ a b FEA (2005) FEA Records Management Profile, Version 1.0. December 15, 2005.

References

See also

"Solution architecture" defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers. Solution architecture is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level.[2]

  • 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.[2]

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:

By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.[2]

  • Enterprise architecture,
  • Segment architecture, and
  • Solution architecture.
Federal Enterprise Architecture levels and attributes[2]

In 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:[2]

FEA Architecture levels

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.[1]

The figure on the right provides a high-level depiction of the TRM.

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

The TRM consists of:

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.[1]

Technical Reference Model.[1]

Technical Reference Model (TRM)

The DRM is the starting point from which data architects should develop modeling standards and concepts. The combined volumes of the DRM support data classification and enable horizontal and vertical information sharing.

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

Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document:

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.[1] 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.

The DRM Collaboration Process.[1]

Data Reference Model (DRM)

Each Service Domain is decomposed into Service Types. For example, the three Service Types associated with the Customer Services Domain are: Customer Preferences; Customer Relationship Management; and Customer Initiated Assistance. And each Service Type is decomposed further into components. For example, the four components within the Customer Preferences Service Type include: Personalization; Subscriptions; Alerts and Notifications; and Profile Management.[5]

  • Customer Services
  • Process Automation Services
  • Business Management Services
  • Digital Asset Services
  • Business Analytical Services
  • Back Office Services
  • Support Services

The SRM establishes the following domains:

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.[1] 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.

Service Component Reference Model.[5]

Service Component Reference Model (SRM)

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.[1]

The Business Reference Model provides a framework that facilitates a functional (as opposed to organizational) view of the federal government’s LoBs, including its internal operations and its services for the citizens, independent of the agencies, bureaus and offices that perform them. By describing the federal government around common business areas instead of by a stovepiped, agency-by-agency view, the BRM promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies.[1]

  • Services for Citizens
  • Mode of Delivery
  • Support Delivery of Services
  • Management of Government Resources

The BRM is broken down into four areas:

[1] The "FEA

Business Reference Model overview.[1]

Business Reference Model (BRM)

  • Mission and Business Results
  • Customer Results
  • Processes and Activities
  • Technology

The PRM uses a number of existing approaches to performance measurement, including the Balanced Scorecard, Baldrige Criteria, value measuring methodology, program logic models, the value chain, and the Theory of Constraints. In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, enterprise architecture, and Capital Planning and Investment Control. The PRM is currently composed of four measurement areas:

  1. Help produce enhanced performance information to improve strategic and daily decision-making;
  2. Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear “line of sight” to desired results;
  3. Identify performance improvement opportunities that span traditional organizational structures and boundaries

The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance.[1] The PRM has three main purposes:

Performance reference model, 2005.[1]

Performance Reference Model (PRM)

It is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. It is an initiative of the US Office of Management and Budget that aims to comply with the Clinger-Cohen Act.

  • performance reference model,
  • business reference model,
  • service component reference model,
  • data reference model and
  • technical reference model.

The FEA is built using an assortment of reference models that develop a common taxonomy and ontology for describing IT resources. FEA Version 1 reference models (see image) included the following:

Federal Enterprise Architecture.[1]

Version 1 Reference models

The SRM provides a common language and methodology for discussing security and privacy in the context of federal agencies’ business and performance goals.

Security Reference Model (SRM)

The IRM categorizes the network/cloud related standards and technologies to support and enable the delivery of voice, data, video, and mobile service components and capabilities.

Infrastructure Reference Model (IRM)

The ARM categorizes the system- and application-related standards and technologies that support the delivery of service capabilities, allowing agencies to share and reuse common solutions and benefit from economies of scale.

Application Reference Model (ARM)

The DRM facilitates discovery of existing data holdings residing in “silos” and enables understanding the meaning of the data, how to access it, and how to leverage it to support performance results.

Data Reference Model (DRM)

This reference model, which combines the Business and Service Component Reference Models from FEAF v1, supports architectural analysis and reporting in the business services sub-architecture view of the overall EA. The BRM describes an organization through a taxonomy of common mission and support service areas instead of through a stove-piped organizational view, thereby promoting intra- and inter-agency collaboration.

Business Reference Model (BRM)

This reference model supports architectural analysis and reporting in the strategy sub-architecture view of the overall EA. The PRM links agency strategy, internal business components, and investments, providing a means to measure the impact of those investments on strategic outcomes.

Performance Reference Model (PRM)

  • Performance Reference Model (PRM)
  • Business Reference Model (BRM)
  • Data Reference Model (DRM)
  • Application Reference Model (ARM)
  • Infrastructure Reference Model (IRM)
  • Security Reference Model (SRM)

The five reference models in version 1 (see below) have been regrouped and expanded into six in the FEAF-II.

The Consolidated Reference Model of the Federal Enterprise Architecture Framework (FEAF) equips OMB and Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way. Through the use of the FEAF and its vocabulary, IT portfolios can be better managed and leveraged across the federal government, enhancing collaboration and ultimately transforming the Federal government.

Federal Enterprise Architecture.

Version 2 Reference models

  • A-11 : Preparation, Submission and Execution of the Budget
  • A-130 : OMB Circular A-130 Management of Federal Information Resources, first issued in December 1985

Supplementary OMB circulars have been:

Overall the Federal Enterprise Architecture (FEA) is mandated by a series of federal laws and mandates. These federal laws have been:

On January 29, 2013, the White House released Version 2 of the Federal Enterprise Architecture Framework (FEAF-II), to government agencies, making it public about a year later.[4] The document meets the criteria set forth by Common Approach, emphasizing that strategic goals drive business services, which in turn provide the requirements for enabling technologies. At its core is the Consolidated Reference Model (CRM), which equips OMB and Federal agencies with a common language and framework to describe and analyze investments.

In May 2012 OMB published a full new guide, the "Common Approach to Federal Enterprise Architecture". Released as part of the federal CIO’s policy guidance and management tools for increasing shared approaches to IT service delivery, the guide presents an overall approach to developing and using Enterprise Architecture in the Federal Government. The Common Approach promotes increased levels of mission effectiveness by standardizing the development and use of architectures within and between Federal Agencies. This includes principles for using EA to help agencies eliminate waste and duplication, increase shared services, close performance gaps, and promote engagement among government, industry, and citizens.

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—s 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 at that time (see image) includes the first three columns of the Zachman Framework and the Spewak's Enterprise Architecture Planning methodology.[3]

At the time of release, the Government's IT focus on Y2K issues and then the events of September 2001 diverted attention from EA implementation, though its practice in advance and subsequent to this may have ameliorated the impact of these events. Interim releases since that time have provided successive increases in definition for the core reference models (see below), as well as a very robust methodology for actually developing an architecture in a series of templates forming the "Federal Segment Architecture Methodology". [3] In September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1 for developing an

Structure of the U.S. "Federal Enterprise Architecture Framework" (FEAF) Components, presented in 2001.[3]

History

There are numerous benefits that accrue from implementing and using an enterprise architecture within the U.S. Federal Government. Among them is to provide a common approach for IT acquisition in the United States federal government. It is also designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services.

The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S. Office of Management and Budget, Office of E-Government and IT, that aims to realize the value of enterprise architecture within the U.S. Federal Government. Enterprise Architecture became a recognized strategic and management best practice in U.S. Federal Government with the passage of the Clinger-Cohen Act in 1996.

Enterprise architecture (EA) is a management best practice for aligning business and technology resources to achieve strategic outcomes, improve organizational performance and guide federal agencies to 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. A federal enterprise architecture is a work in progress to achieve these goals.[2]

Overview

Contents

  • Overview 1
  • History 2
  • Version 2 Reference models 3
    • Performance Reference Model (PRM) 3.1
    • Business Reference Model (BRM) 3.2
    • Data Reference Model (DRM) 3.3
    • Application Reference Model (ARM) 3.4
    • Infrastructure Reference Model (IRM) 3.5
    • Security Reference Model (SRM) 3.6
  • Version 1 Reference models 4
    • Performance Reference Model (PRM) 4.1
    • Business Reference Model (BRM) 4.2
    • Service Component Reference Model (SRM) 4.3
    • Data Reference Model (DRM) 4.4
    • Technical Reference Model (TRM) 4.5
  • FEA Architecture levels 5
  • See also 6
  • References 7
  • External links 8

The most familiar federal enterprise architecture is the enterprise architecture of the Federal government of the United States, the U.S. "Federal Enterprise Architecture" (FEA) and the corresponding U.S. "Federal Enterprise Architecture Framework" (FEAF). This lemma will focus on this particular enterprise architecture and enterprise architecture framework.

[1]

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.