FEAF – Federal 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.

Several EA frameworks 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.

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

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

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.

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