A definitive Guide to

FEAF – Federal Enterprise Architecture Framework

The Federal Enterprise Architecture Framework (FEAF) is an Enterprise Architecture framework designed to provide structure and guidance to U.S. federal agencies.

► See the whole picture with this agile enterprise architecture framework.

Introduction

When approaching a new objective, enterprise architects will look for the most efficient ways to align an organization's business and technology resources to optimize or rework processes. There are several frameworks that help guide architects through the EA process. Architects will either use one of these to facilitate their plan or a combination of two or three.

The most well-known and implemented frameworks among enterprise architects include TOGAF, the Zachman Framework, Gartner Framework, and FEAF (Federal Enterprise Architecture Framework).

 

What is the Federal Enterprise Architecture Framework – FEAF?

FEAF is the Federal Enterprise Architecture Framework developed by the Federal Government of the United States and is the industry standard framework for government enterprise architecture frameworks. This framework guides the integration of strategic, business, and technology management architecture processes. A central benefit of the FEAF framework is that it provides a common approach to IT acquisition within all U.S. federal agencies.

Architects wanting to add FEAF to their enterprise toolkit can complete the Federal Enterprise Architecture Certification. The FEAF certification gives enterprise architects a basic understanding of the methodology using real-world challenges the Federal Government is facing.

FEAF differs from other EA frameworks in a number of ways. Firstly, it’s a specialized framework designed specifically for U.S. federal agencies, unlike Zachman and TOGAF which can be implemented in any commercial enterprise setting.

FEAF is designed to work within a bureaucratic environment, to help enterprise architects be more efficient while promoting collaboration and highlighting cost-saving opportunities. 

FEAF can be combined with any of the more popular and general enterprise architecture frameworks. It simply depends on the architect and which methodology they feel will most effectively meet the needs of the organization. 

There are six domains of enterprise architecture for government agencies; these are Performance Reference Model (PRM), Business Reference Model (BRM), Data Reference Model (DRM), Application Reference Model (ARM), Infrastructure Reference Model (IRM), and Security Reference Model (SRM) which will be discussed in more detail further down.

 

Advantages of FEAF

The advantages of the FEAF framework are numerous, but there are four key benefits:

Interoperability

This is the ability of two or more systems or entities to share information accurately. Interoperability helps assist the enterprise in its evaluation of the overall process and deliver cross-agency services efficiently.

Agility

The agility provided by FEAF assists in an enterprise's ability to act quickly to any unpredictable changes. Over time, changes in politics, processes, and regulation will affect the systems already in place, which means it’s important for federal agencies to have the flexibility to adapt to new requirements and provide timely responses.

Integration

The integration combines subsections to help various departments make sure functions are compatible and can work together, avoiding any over expenditure and time-wasting. This area of FEAF offers a method to enable consistency between systems.

Reusability

FEAF’s reusability means that components can be applied and used across multiple government systems, meaning that different authorities can benefit from the same common parts across the E-government system.

 

Collaborative Planning Methodology

The Collaborative Planning Methodology (CMP) is the full lifecycle of planning and implementation at the heart of FEAF’s methodology and working process. It is designed to be used at all levels of Federal Enterprise Architecture. These are International, National, Federal, Sector, Agency, Segment, System, and Application.

The CMP consists of two main phases–organize and plan, and implement and measure–further split into five key sections.

Identify and validate

When approaching the FEAF methodology, the purpose, planner’s role and outcome help define what steps need to be taken.

  • Purpose
    During this stage, the architect will identify and assess what needs to be achieved, and the purpose will be outlined alongside the major drivers of the change and the stakeholders. Initial performance metrics are outlined, and the appropriate governance is identified.

  • The Planner’s Role
    The planners—architects and other IT specialists—will collaborate with the stakeholders and sponsors to outline, validate and prioritize their needs to come to a shared understanding of the outcome and what needs to be achieved.

  • Outcome
    During the purpose and planning stages, the outcome will be identified and defined, as well as which performance metrics will be measured, who the key stakeholders are, and which governance will oversee and approve any recommended changes.

Research and leverage

  • Purpose
    The purpose of research and leverage is to identify whether other organizations or service providers have formally faced or are facing similar needs and to analyze their experiences to determine if the same approaches can be leveraged or if a partnership can be formed.

  • The Planner’s Role
    The planner then needs to facilitate and lead the assessment of the other organizations’ experiences and results, and determine whether they have similar needs. Once those needs have been identified, the planner assesses and determines opportunities for collaboration or leverage.

  • Outcome
    The outcome of research and leverage is to ensure the sponsors, stakeholders, and planners involved have a clear overview and understanding of the experiences and results of other organizations, and whether those can be leveraged to achieve the same needs. This is hugely valuable to the upcoming planning stages.

Define and plan

  • Purpose
    Here, the planner will develop an integrated plan of how to achieve the needs outlined in the first step. The plan will cover what needs to be done, how, the timeline, how success will be measured, how much it will cost, etc. It will include adjustments within all architecture domains (strategy, business, data, applications, infrastructure, or security). The final plan will then be approved by the sponsor.

  • The Planner’s Role
    The architect is then responsible for applying analysis and planning methods within each of the architecture domains to produce artifacts to capture and visualize the changes outlined in step one. During this step the architect will produce a roadmap that reflects a course of action.

  • Outcome
    The outcome of the define and planning stage is the sponsors, stakeholders, and related governance have a cohesive and integrated plan of what will be achieved, with clear guidelines as to timeline, cost and outcome.

Invest and execute

  • Purpose
    This is the step that will successfully implement the planned changes. The investment decision will be made with the various groups involved, and the changes defined in the integrated plan will be executed.

  • The Planner’s Role
    During this stage, the architect will assist in the investment and implementation of all activities by providing support, revisions, and guidance of the integrated plan. They may also be required to do further research and analysis, engage stakeholders for feedback, and ensure plans are followed and architectural requirements are met.

  • Outcome
    This stage moves the process forward from planning to implementation. If the investment is not approved, the planner, stakeholders, and sponsor will return to the previous stages, consider new recommendations and alter plans for future consideration.

Perform and measure

  • Purpose
    The final step in the process is to measure the performance outcomes against metrics identified during the earlier stages.

  • The Planner’s Role
    While the architect has little control over the final performance data, they will be able to collect the results to leverage and assess whether the implemented capabilities achieve the desired and planned outcomes. The data and feedback collected during this final stage will impact future planning efforts, and help identify immediate implementation adjustments as required.

  • Outcome
    The most important outcome in this final stage is to measure the key performance data against identified metrics. This may influence future projects.
2022 Gartner Customers' Choice for Enterprise Architecture Tools distinction

Report

2022 Gartner Customers' Choice for Enterprise Architecture Tools..

Learn about all vendors in the Enterprise Architecture tool space.

Enterprise Architects on IT Priorities for 2022

Report

Enterprise Architects on IT Priorities for 2022

From Technical Debt to Sustainability: International LeanIX EA & IT Strategy Survey 2022. To see how your priorities align with the priorities of IT teams from around the world, download the report..

Faster Time to Value with LeanIX EAM

Poster

Faster Time to Value with LeanIX EAM

Learn how LeanIX EAM will help you turn data into insight, and insight into action, faster than you can say "Time to Value!"
LeanIX named a leader in SPARK Matrix: EA Tools, 2021

Report

LeanIX named a leader in SPARK Matrix: EA Tools, 2021

A Quadrant Knowledge Solutions report of the global Enterprise Architecture (EA) Tools market

LeanIX M&A Survey 2021

Report

LeanIX M&A Survey 2021

The Role of Enterprise Architects in M&A

4 Steps to M&A Success with LeanIX

Poster

4 Steps to M&A Success with LeanIX

Download our poster to see how LeanIX helps enterprise architecture teams accelerate IT workstreams following a merger or acquisition.

Enterprise Architecture Success Kit

White Paper

Enterprise Architecture Success Kit

Enterprise Architecture Roadmap

Poster

Enterprise Architecture Roadmap

6 Steps for Achieving Quick and Sustainable Value

Version 2 reference models

The Consolidated Reference Model (CRM) differs from the CMP by equipping the Federal agencies with a common language to describe and analyze investments. Rather than the steps outlined above, version 2 uses interrelated “reference models” to facilitate a common and consistent framework of describing important elements across federal agency operations.

Using this FEAF reference model, IT projects can be better managed and leveraged, facilitating cross-agency analysis and collaboration.

This framework comprises the six reference models that have been expanded from the five developed in version one.

Performance Reference Model (PRM)

  • Purpose
    The purpose of the performance reference model (PRM) is to link strategy, internal business components, and investments between federal agencies. The PRM will also provide ways to measure the impact of those investments on strategic outcomes.

  • Structure
    The structure of the PRM is divided into three areas: the Goal, the Measurement Area, and the Measurement Category. The Goal groups investments and activities through a common framework. It enables common performance elements to be identified and cross-platform information linkages to be established between systems. The Measurement Area applies detailed performance indicators associated with the investments and activities, while the Measurement Category simply refines the measurement area. 

  • Outcome
    The outcome of the PRM is to describe the relationship between the investment and agency goals, provide investment-specific performance measurements, and create reports on the desired results.

  • Touchpoints with other reference models
  BRM DRM ARM IRM SRM
PRM - will provide metrics for measuring: Business performance Data information management performance Application performance Infrastructure performance Security performance

Realizing Post-Merger Synergies in Your IT Application Landscape [White Paper]: Find out what methods for consolidating IT Application Landscapes exist and  what steps should be taken to consolidate an IT landscape from a merger. »

Business Reference Model (BRM)

  • Purpose
    Much like the research and leverage stage of FEAF, the Business Reference Model (BRM) promotes intra- and inter-agency collaboration. This enables business and IT leaders across the Federal Government to uncover cost-saving opportunities and new business capabilities that will help to achieve the strategic objectives set out in the PRM.

  • Structure
    The BRM is structured into a three-tiered hierarchy: the Mission Sector, Business Function, and Service. These tiers enable the aggregation and analysis of investments and applications for a variety of different purposes, across various business areas of the Federal Government.

  • Outcome
    The outcome of the BRM is to provide all Government agencies with a standard means of categorizing investments, encourage collaboration and consolidation and help advance and improve the overall IT architecture to better accomplish goals. 

  • Touchpoints with other reference models
  PRM DRM ARM IRM SRM
BRM - will provide metrics for measuring: Outlines the relationships between IT strategy and business functions Identifies duplicates and gaps in data information Identifies opportunities for reuse and collaboration & improve application management Finds opportunities for consolidation and outline technology needs Describes security business processes

 

Data Reference Model (DRM)

  • Purpose
    The role of the Data Reference Model (DRM) is to facilitate the identification and understanding of the data, how to access it, and how to leverage it to support performance results.

  • Structure
    The DRM is also divided into a hierarchy of three tiers. The top tier is composed of four domains (Mission Support Data, Enterprise Support Data, Guidance Data, and Resource Data). The middle tier lists 22 subject elements and the lowest tier includes 144 individual topic elements. 

  • Outcome
    The role of the DRM is to provide both the structure and vocabulary on how to describe, identify, categorize and share data/information across all Federal Government agencies. 

  • Touchpoints with other reference models
  PRM BRM ARM IRM SRM
DRM Outlines the relationships between IT strategy and business functions Uses data sharing to improve business processes and decision making Establishes relationships between systems through relationships among data elements Identifies technical infrastructure requirements Provides input for security categorization and privacy analysis

 

Application Reference Model (ARM)

  • Purpose
    The Application Reference Model (ARM) is the basis for categorizing applications and their individual components. It is an important step in identifying any gaps and redundancies, and identifies opportunities for consolidation and sharing between agencies as they map their Information Systems into ARM categories.

  • Structure
    The ARM reference model is also organized into three categories: Systems, Application Components, and Interfaces. The systems are sets of IT, data, and related resources which are organized for the processing and use of information to support specific business processes. The application components are self-contained software programs that can be configured to support business objectives (e.g. workflow or document management). The interfaces describe protocols used to transfer information from one system to another.

  • Outcome
    The outcome is to identify opportunities for cost-saving and reduce redundancies across all Government agencies. 

  • Touchpoints with other reference models
  PRM BRM DRM IRM SRM
ARM Improves strategic performance through application reuse and sharing Improves business processes and identifies new business capabilities Outlines data storage needs and exchange requirements Identifies technical infrastructure requirements Provides specific asset inventory

 

Infrastructure Reference Model (IRM)

  • Purpose
    The Infrastructure Reference Model (IRM) is used in the categorization of IT infrastructure, as well as the facilities and networks that host said structure. Through the reuse and sharing of infrastructure across agencies, the IRM helps facilitate cost-saving and increases Interoperability to enable greater access to information.

  • Structure
    The IRM taxonomy consists of three levels which provide a categorization scheme for physical IT assets. Level one, also called the Domain, comprises the Platform, Network, and Facility which relate to each other to enable an analysis of IT assets across these three dimensions. Level two, or the Area, consists of 13 “areas” linked to the Domains in Level one. Level three consists of 90 Categories which are further linked to the 13 areas in level two.

  • Outcome
    The outcome of the IRM is to support multiple levels of stakeholders and executives across agencies to improve IT resource decision-making, provide cost-saving opportunities, reduce redundancies, and promote information sharing.

  • Touchpoints with other reference models
  PRM BRM DRM ARM SRM
IRM Improve strategy performance through identifying related infrastructure Finds opportunity to improve business process and new business capabilities Identify data storage requirements Identifies tech constraints and outlines opportunities for upgrades and innovation Provides specific asset inventory

 

Security Reference Model (SRM)

  • Purpose
    The Security Reference Model (SRM) allows architects to categorize security architecture across all levels of Federal Architecture (International, National, Federal, etc.). Security is integral to all architectural domains and at all levels of an organization. Therefore security must be considered and woven throughout every level of the Enterprise and across all reference models. 

  • Structure
    Structurally, the SRM has three key areas; Purpose, Risk, and Controls; which are further divided into six sub-categories; Regulatory conditions, Risk, Risk assessment processes, Impact mitigation, Compliance, and Control categories. These manage risk reduction and regulatory compliance which drive security choices based on the specific purposes of an agency or segment.

  • Outcome
    By linking security and privacy to agency enterprise architecture, the SRM ensures all agencies receive appropriate security and privacy considerations. It also improves the consolidation and standardization of security capabilities. 

  • Touchpoints with other reference models
  PRM BRM DRM ARM IRM
SRM Identifies the risk for strategy performance and implementation Informs businesses on policies and regulations which affect security  Outlines encryption needed for information storage and processing Identify privacy considerations Determines cross-domain requirements

 

FEAF vs. TOGAF

Most Enterprise Architects will already be familiar with the TOGAF framework due to its popularity in the practice, but FEAF contains guidance analogous that accompany TOGAF’s Foundation Architecture, viewpoints, and views.

While the FEAF is oriented toward enterprise architecture, TOGAF is more oriented toward IT architecture. This means there are benefits of having insights into both frameworks and methodologies.

feaf-vs-togaf-matrixFigure 1: FEAF Matrix (Source: TOGAF)

The key difference between TOGAF vs FEAF is that the FEAF is designed to provide guidance to federal agencies for structuring their enterprise architecture. The way the FEAF matrix is structured also does not directly map to the TOGAF structure but corresponds more to the Zachman Framework.

That said, three of the four architecture domains covered by TOGAF also correspond directly to the columns of the FEAF matrix (see above).

 

Conclusion

The Federal Enterprise Architecture Framework (FEAF) is an enterprise architecture methodology designed to guide the integration of strategic, business, and technology management architecture processes across all U.S. Federal agencies.

Alongside TOGAF and the Zachman Framework, a deep understanding of all important frameworks, as well as selecting the right EA tool capabilities, is hugely beneficial for architects looking to better meet an organization's EA requirements and goals.

Free Poster

Re-Invent Your IT With a Lean Enterprise Architecture Framework

Align Business and IT for Enterprise Architecture to succeed and achieve a simple, lean, and structured overview!

Get your free Copy

Lean enterprise architecture framework
check

A lean and agile data model is key for Enterprise Architects, IT Architects, Business Architects or others.

check

See the whole picture with this agile enterprise architecture framework.

Answers to frequently asked questions on FEAF

What is the FEAF?

FEAF is the Federal Enterprise Architecture Framework developed by the Federal Government of the United States and is the industry standard framework for government enterprise architecture frameworks.

Who uses FEAF?

FEAF is designed to work within a bureaucratic environment, to help enterprise architects be more efficient while promoting collaboration and highlighting cost-saving opportunities.

What are the goals of FEAF?

The FEAF framework guides the integration of strategic, business, and technology management architecture processes. A central benefit of the FEAF framework is that it provides a common approach to IT acquisition within all U.S. federal agencies.

What is the difference between FEAF and TOGAF?

Most Enterprise Architects will already be familiar with the TOGAF framework due to its popularity in the practice, but FEAF contains guidance analogous that accompany TOGAF’s Foundation Architecture, viewpoints, and views. While the FEAF is oriented toward enterprise architecture, TOGAF is more oriented toward IT architecture. This means there are benefits of having insights into both frameworks and methodologies.

The key difference between TOGAF vs FEAF is that the FEAF is designed to provide guidance to federal agencies for structuring their enterprise architecture. The way the FEAF matrix is structured also does not directly map to the TOGAF structure but corresponds more to the Zachman Framework. That said, three of the four architecture domains covered by TOGAF also correspond directly to the columns of the FEAF matrix (see above).

lean-enterprise-architecture-framework

Free Poster

Re-Invent your IT

Download now!