Federal enterprise architecture

Last updated

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement. [1]

Contents

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.

Overview

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]

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.

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.

History

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

In 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. [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. As part of the President's Management Agenda, in August 2001, the E-Government Task Force project was initiated (unofficially called Project Quicksilver). A key finding in that strategy was that the substantial overlap and redundant agency systems constrained the ability to achieve the Bush Administration strategy of making the government "citizen centered". The Task Force recommended the creation a Federal Enterprise Architecture Project and the creation of the FEA Office at OMB. This was a shift from the FEAF focus on Information Engineering, to a J2EE object re-use approach using reference models comprising taxonomies that linked performance outcomes to lines of business, process services components, types of data, and technology components. 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 (FSAM) and its next generation replacement, the Collaborative Planning Methodology (CPM), which was designed to be more flexible, more widely applicable, and more inclusive of the larger set of planning disciplines.

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]

In May 2012 OMB published a full new guide, the "Common Approach to Federal Enterprise Architecture". [4] 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.

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

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

Supplementary OMB circulars have been:

Collaborative planning methodology

The Collaborative Planning Methodology (CPM) is a simple, repeatable process that consists of integrated, multi-disciplinary analysis that results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers. It is intended as a full planning and implementation lifecycle for use at all levels of scope defined in the Common Approach to Federal Enterprise Architecture: International, National, Federal, Sector, Agency, Segment, System, and Application. [4] [5]

Version 2 reference models

Federal Enterprise Architecture. FEA Consolidated Reference Model.png
Federal Enterprise Architecture.

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.

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

Performance Reference Model (PRM)
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.
Business Reference Model (BRM)
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.
Data Reference Model (DRM)
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.
Application Reference Model (ARM)
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.
Infrastructure Reference Model (IRM)
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.
Security Reference Model (SRM)
The SRM provides a common language and methodology for discussing security and privacy in the context of federal agencies' business and performance goals.

Version 1 reference models

Federal Enterprise Architecture. FEA Reference Models.jpg
Federal Enterprise Architecture.

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

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 (PRM)

Performance reference model, 2005. Performance Reference Model.jpg
Performance reference model, 2005.

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:

  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 uses a number of existing approaches to performance measurement, including the Balanced Scorecard, Baldrige Criteria, [6] 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:

Business Reference Model (BRM)

Business Reference Model overview. BRM Overview.jpg
Business Reference Model overview.

The "FEA business reference model" is 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. [1]

The BRM is broken down into four areas:

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]

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]

Service Component Reference Model (SRM)

Service Component Reference Model. Service Component Reference Model.jpg
Service Component Reference Model.

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.

The SRM establishes the following domains:

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

Data Reference Model (DRM)

The DRM Collaboration Process. DRM Collaboration Process.jpg
The DRM Collaboration Process.

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.

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

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.

Technical Reference Model (TRM)

Technical Reference Model. Technical Reference Model.jpg
Technical Reference Model.

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]

The TRM consists of:

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

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]

Architecture levels

In the FEA, enterprise, segment, and solution architectures 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]

Federal Enterprise Architecture levels and attributes Architectural Levels and Attributes.jpg
Federal Enterprise Architecture levels and attributes

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]

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:

"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]

Program results

Results of the Federal Enterprise Architecture program are considered unsatisfactory:

See also

Related Research Articles

<span class="mw-page-title-main">Zachman Framework</span> Structure for enterprise architecture

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.

<span class="mw-page-title-main">Business process modeling</span> Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

Enterprise architecture (EA) is a business function concerned with the structures and behaviors of a business, especially business roles and processes that create and use business data. An Enterprise Architect is at the highest level of the architect hierarchy. This means they have more responsibilities than solutions architects. While solutions architects focus on their solution, an enterprise architect focuses on the overview of the whole organization. An enterprise architect leads over many solutions architects and business functions. By international consensus, Enterprise Architecture has been defined as "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

<span class="mw-page-title-main">System Architect</span> Enterprise architecture tool

Unicom System Architect is an enterprise architecture tool that is used by the business and technology departments of corporations and government agencies to model their business operations and the systems, applications, and databases that support them. System Architect is used to build architectures using various frameworks including TOGAF, ArchiMate, DoDAF, MODAF, NAF and standard method notations such as sysML, UML, BPMN, and relational data modeling. System Architect is developed by UNICOM Systems, a division of UNICOM Global, a United States-based company.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models - typically matrices and diagrams - for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

The Queensland Government Enterprise Architecture is an initiative of the Queensland Government Chief Information Office (QGCIO) in Australia. QGEA 2.0 is the collection of ICT policies and associated documents that guides agency ICT initiatives and investments to improve the compatibility and cost-effectiveness of ICT across the government. The QGEA provides the decision making and management structures to support the development of better services for Queenslanders, more efficient and effective use of information and ICT in government and effective partnering with the private sector through the application of whole-of-Government, cross agency and agency information and information communications technology policies and practices.

<span class="mw-page-title-main">Enterprise life cycle</span> Process of changing an enterprise over time

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of a whole system from the perspective of a related set of concerns.

<span class="mw-page-title-main">Enterprise Architecture Assessment Framework</span>

The Enterprise Architecture Assessment Framework (EAAF) is created by the US Federal government Office of Management and Budget (OMB) to allow federal agencies to assess and report their enterprise architecture activity and maturity, and to advance the use of enterprise architecture in the federal government.

<span class="mw-page-title-main">Business reference model</span>

Business reference model (BRM) is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency.

<span class="mw-page-title-main">Treasury Enterprise Architecture Framework</span>

Treasury Enterprise Architecture Framework (TEAF) was an enterprise architecture framework for treasury, based on the Zachman Framework. It was developed by the US Department of the Treasury and published in July 2000. May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".

<span class="mw-page-title-main">FDIC Enterprise Architecture Framework</span>

FDIC Enterprise Architecture Framework was the enterprise architecture framework of the United States Federal Deposit Insurance Corporation (FDIC). A lot of the current article is about the enterprise architecture framework developed around 2005, and currently anno 2011 out-of-date.

<span class="mw-page-title-main">Enterprise architecture planning</span>

Enterprise architecture planning (EAP) in enterprise architecture is the planning process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.

<span class="mw-page-title-main">TAFIM</span>

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

<span class="mw-page-title-main">Open-system environment reference model</span>

Open-system environment (OSE) reference model (RM) or OSE reference model (OSE/RM) is a 1990 reference model for enterprise architecture. It provides a framework for describing open system concepts and defining a lexicon of terms, that can be agreed upon generally by all interested parties.

<span class="mw-page-title-main">NIST Enterprise Architecture Model</span> Reference model of enterprise architecture

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

<span class="mw-page-title-main">Treasury Information System Architecture Framework</span>

The Treasury Information System Architecture Framework (TISAF) is an early 1990s Enterprise Architecture framework to assist US Treasury Bureaus to develop their Enterprise Information System Architectures (EISAs).

Segment architecture is a detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.


The Singapore Government Enterprise Architecture (SGEA) programme was established to support and enable the business strategies, objectives, and a vision of a 'Networked Government'. It adopted a federated architecture approach similar to the United States government. It is a set of blueprints: the Business Architecture (BA), Information Architecture (IA), Solution Architecture (SA) and Technical Architecture (TA) of the Singapore Government. It provides a holistic view of business functions, common data standards, and shared ICT systems and infrastructure. This programme facilitates the identification of opportunities for collaboration among agencies, encouraging greater sharing of data, systems and processes across agencies.

Jaap Schekkerman is a Dutch computer scientist and founder of the Institute For Enterprise Architecture Developments (IFEAD) in the Netherlands. He is particularly known for his 2003 book How to Survive in the Jungle of Enterprise Architecture in which he compared 14 Enterprise Architecture Frameworks.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 FEA Consolidated Reference Model Document.FEA Consolidated Reference Model Document Version 2.3 October 2007. Accessed 28 April 2009.
  2. 1 2 3 4 5 6 Federal Enterprise Architecture Program Management Office (2007). FEA Practice Guidance. Archived October 16, 2010, at the Wayback Machine
  3. 1 2 3 Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture Archived 2008-10-10 at the Wayback Machine . Feb. 2001.
  4. 1 2 "Common Approach to Federal Enterprise Architecture" (PDF). Office of Management and Budget. May 2012. Archived (PDF) from the original on January 22, 2017.
  5. 1 2 FEA Consolidated Reference Model Document. Federal Enterprise Architecture Framework version 2 January 29, 2013. Accessed 2 April 2015.
  6. ↑ "2015–2016 Baldrige Excellence Framework". Baldrige Performance Excellence Program. National Institute of Standards and Technology. January 15, 2015. Archived from the original on August 4, 2016.
  7. 1 2 FEA (2005) FEA Records Management Profile, Version 1.0. December 15, 2005.
  8. ↑ "Why Doesn’t the Federal Enterprise Architecture Work?" Archived June 11, 2016, at the Wayback Machine , Stanley B. Gaver, visited 19 May 2016.
  9. ↑ GAO (2011). Opportunities to Reduce Potential Duplication in Government Programs, Save Tax Dollars, and Enhance Revenue. Washington, DC: Government Accountability Office.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.