Insight · Framework

FEAF in Sparx EA: Implementing the Federal Enterprise Architecture Framework

By Sparx Services · January 26, 2026

The Federal Enterprise Architecture Framework (FEAF) 2.0 is the architecture governance framework for US Federal civilian agencies. It gives the Office of Management and Budget and the agencies a common reference for describing, comparing, and integrating their architectures across government. For a Federal EA team, FEAF is not optional — OMB Circular A-130 establishes enterprise architecture as a requirement, and FEAF supplies the structure. But FEAF's reference models are a real architectural commitment, and meeting it needs a capable, governed tool.

Sparx EA, configured with a FEAF-aligned MDG Technology and an ArchiMate-to-FEAF domain mapping, gives Federal teams the environment to meet OMB EA requirements, feed IT investment governance through the Capital Planning process, and align architecture documentation with FISMA compliance reporting. This article walks through how the implementation actually comes together.

What this covers

How FEAF 2.0's reference-model domains map directly onto ArchiMate layers in Sparx EA.
What a FEAF-configured MDG gives you — the stereotypes, tagged values, and package structure a Federal program needs.
What Federal teams actually build day to day: as-is and target architectures for major IT investments (CPIC), application portfolio management, and FISMA compliance architecture.
How OMB reporting — including IT Portfolio Management contributions — is supported by tagged values and reporting scripts in the repository.
The practical Federal deployment, procurement, and accessibility considerations that shape the environment.

FEAF 2.0 and its reference models

FEAF version 2 (2013) is built around a Consolidated Reference Model spanning six sub-architecture domains — Strategy, Business, Data, Applications, Infrastructure, and Security. These regrouped and extended the five reference models from the original Federal Enterprise Architecture, and most Federal practitioners still refer to the underlying reference models by name. Five of them carry the bulk of the modeling work:

Performance Reference Model (PRM). Connects IT investments to measurable outcomes and mission performance — what an investment is meant to achieve, how success is measured, how it serves the mission. In Sparx EA, PRM elements live in the Strategy layer as Goals and Outcomes linked to investments and capabilities.

Business Reference Model (BRM). A taxonomy of Federal business and support services that lets agencies compare functions and spot shared-service opportunities. The BRM organizes Federal functions into Mission Sectors and Lines of Business. In Sparx EA, BRM elements are Business Functions and Services in the Business layer, tied to the agency processes and capabilities they represent.

Service Component Reference Model (SRM). A classification of IT service components that surfaces reuse and shared-services opportunities across agencies. In Sparx EA, SRM elements are Application Services and Application Components in the Application layer.

Technical Reference Model (TRM). The approved technology vocabulary — standards for security (NIST), accessibility (Section 508), interoperability, and cloud (FedRAMP-authorized services). In Sparx EA, TRM elements are Technology Nodes and System Software in the Technology layer, with applicable standards recorded as tagged values.

Data Reference Model (DRM). A framework for describing Federal data and its relationships, supporting data governance and interoperability. In Sparx EA, DRM elements are Data Objects in the Information layer, with NIEM (National Information Exchange Model) references captured as tagged values where they apply. The Security domain runs across all of these, modeled as the controls and boundaries described later.

ArchiMate-to-FEAF domain mapping

FEAF and ArchiMate use different but compatible vocabularies. The mapping Sparx Services establishes for Federal teams is straightforward, and it is the spine of the configuration:

FEAF reference model	ArchiMate layer	Key element types
Performance (PRM)	Strategy / Motivation	Goals, Outcomes, Drivers, Assessments
Business (BRM)	Business Layer	Business Functions, Business Services, Business Processes
Service Component (SRM)	Application Layer	Application Components, Application Services
Technical (TRM)	Technology Layer	Technology Nodes, System Software, Communication Networks
Data (DRM)	Information / Data	Data Objects, Data Elements, Data Flows

This mapping is encoded in the package structure: a top-level package per reference model, each with sub-packages aligned to the FEAF classification hierarchy. ArchiMate elements within a package carry FEAF reference-model stereotypes from the MDG, so the FEAF classification stays visible inside the tool rather than living in a separate spreadsheet.

What Federal EA teams actually build

FEAF supplies the reference frame, but the day-to-day work centers on a few deliverables that feed agency governance and OMB reporting.

As-is and target architecture for major IT investments

The Capital Planning and Investment Control (CPIC) process requires agencies to document the business and technical justification for major IT investments. The as-is application landscape, the target architecture, and the transition plan are core CPIC deliverables. In Sparx EA, the as-is architecture is built at the Application and Technology layers for each major system in the CPIC portfolio. Tagged values on Application Components record system name, owning component, CPIC investment ID, lifecycle phase (Steady State, Development, Operations and Maintenance, Disposition), annual operating cost, and FISMA categorization (Low, Moderate, High).

The target architecture documents the planned state after a modernization or migration program, with ArchiMate Work Packages representing the transition steps and linked to CPIC milestones.

Application portfolio management

Every agency maintains a portfolio of IT systems, typically reflected in the OMB Federal IT Dashboard. Sparx EA provides the governed environment for that portfolio: each system is an Application Component, each organizational owner is a Business Actor, and the dependencies, integrations, and shared services between systems are ArchiMate Application relationships.

Tagged values on Application Components support OMB reporting — systems that share data across agencies, systems on a cloud-first path, and systems in scope for legacy modernization under the Technology Modernization Fund (TMF). This is the same discipline as application portfolio management in any large organization, with a Federal vocabulary layered on top.

IT Portfolio Management contributions

FEAF architecture feeds the OMB IT Portfolio Management (ITPM) process directly. The architecture repository becomes the authoritative source for system inventory (what exists and who owns it), system relationships (which systems share data or services), duplication and consolidation opportunities (where two agencies run the same capability), and investment alignment (which investments support which mission capabilities).

Sparx EA's reporting scripts generate the views and data extracts ITPM contributions need, cutting manual effort and improving data quality in OMB submissions.

FEAF-aligned MDG configuration

A FEAF-aligned MDG in Sparx EA provides a working set of stereotypes and tagged values:

«FEAF BRM Function» — a Business Function stereotype with Line of Business and Sub-Function tagged values aligned to the BRM taxonomy.
«FEAF SRM Component» — an Application Component stereotype with Service Type and Service Component tagged values from the SRM.
«FEAF TRM Standard» — a Technology Node stereotype with TRM Service Area and Standard/Specification tagged values.
«FEAF DRM Data Object» — a Data Object stereotype with NIEM reference, data classification (public/controlled/classified), and DRM context tagged values.
«CPIC Investment» — an Application Component stereotype for major investments, with CPIC investment ID, lifecycle phase, annual cost, and TMF status tagged values.
«FISMA System» — an Application Component stereotype with FISMA impact level, ATO status, ATO expiry date, and responsible ISSO tagged values.

Model validation rules do the enforcement: every CPIC investment must carry a lifecycle phase, and every system categorized Moderate or High must have an ATO status of Active or In Progress. That is governance built into the model rather than checked after the fact.

Integration with FISMA compliance architecture

The Federal Information Security Management Act (FISMA) requires agencies to run an information security program based on NIST SP 800-53 controls. Where FEAF architecture and FISMA compliance meet is the system boundary — the defined scope of each system for FISMA purposes.

In Sparx EA, the FISMA system boundary is a container package grouping every Application Component and Technology Node inside a given ATO (Authority to Operate) scope. The «FISMA System» stereotype records which boundary an Application Component belongs to.

NIST SP 800-53 controls are modeled as Requirement elements linked to the Technology elements that implement them — the same approach used for FedRAMP compliance, covered in a companion article. That yields architecture-embedded compliance documentation: each FISMA-scoped system has its control implementation in the model itself, rather than in a separate SSP that drifts out of date the moment the system changes.

For cloud services inside the boundary, FedRAMP-authorized services are modeled as Technology Nodes carrying FedRAMP authorization level (Low/Moderate/High) and authorization date, making their compliance status visible within the wider FEAF architecture.

Governance and OMB oversight

The Federal CIO Council and OMB provide oversight for agency EA programs. Agency Chief Architects report to their CIOs, and program health is assessed through OMB's EA reviews.

Sparx EA supports that structure through role-based access and reporting. The repository is the agency's authoritative architecture record: access controls ensure only authorized architects can change elements, while stakeholders across the agency can view diagrams and query data without touching the model.

The Federal IT Dashboard requires regular submissions on investment performance, system inventory, and cost. Those values live as tagged values in the repository, and Power BI connections against that data generate the dashboard views needed for OMB submissions and internal governance reporting.

Practical considerations for Federal deployment

Federal deployments come with specific requirements that shape the environment:

Security. FedRAMP-authorized deployment options (Azure Government, AWS GovCloud) are required for systems handling Controlled Unclassified Information (CUI). Sparx EA's Pro Cloud Server can run inside those environments; for classified architectures, on-premises deployment within a classified enclave is supported.

Procurement. Sparx EA is available through GSA Schedule. Professional services for configuration, MDG development, and training are available through GSA Schedule and agency-specific IDIQ vehicles.

Accessibility. Federal systems must meet Section 508 requirements. Sparx EA's web-based architecture portal, served through Pro Cloud Server, gives Section 508-compliant access to architecture consumers who do not need the full modeling tool.

Frequently asked questions

Is FEAF the same as TOGAF or DoDAF?

No. FEAF, TOGAF, and DoDAF are distinct frameworks with different origins and audiences. FEAF is specific to US Federal civilian agencies and is driven by OMB. TOGAF is a commercial framework used broadly across the private sector and government. DoDAF is specific to US defense programs. They can be complementary — some agencies run TOGAF's ADM as their process while using FEAF's reference models for classification, and Sparx EA supports both.

How does FEAF align with the Technology Modernization Fund (TMF)?

TMF funds Federal IT modernization repaid from future savings, and TMF proposals need architecture documentation showing the current-state system, the proposed modernized state, and the transition plan. A FEAF-aligned model in Sparx EA — as-is application landscape, target architecture, and a Work Package roadmap — produces exactly those artifacts. Sparx Services has supported TMF proposal architecture work.

Can Sparx EA support a multi-agency EA program such as an inter-agency shared service?

Yes. Sparx EA Pro Cloud Server supports federated repositories. A shared service serving multiple agencies can be hosted in one repository with agency-specific packages and access controls, so each agency contributes to the shared architecture while keeping its own work separate.

How does Sparx EA handle classified architecture documentation?

For architectures that include classified systems, Sparx EA can be deployed on-premises within a classified network enclave (SIPR or JWICS as appropriate). The repository is physically separated from unclassified systems, and access controls enforce classification handling. Sparx Services supports classified EA deployments through the appropriate clearance and handling arrangements.

What is the relationship between FEAF and the Federal Data Strategy?

The Federal Data Strategy (OMB M-19-18) sets principles and practices for Federal data governance; the FEAF Data Reference Model is the architecture framework for Federal data. In Sparx EA the Data package links to Federal Data Strategy requirements — data inventories, governance structures, NIEM interoperability, and OPEN Government Data Act obligations — giving a unified architecture-and-governance view of data assets.

How do agencies version FEAF architecture as their systems evolve?

Sparx EA's baseline and version management supports Federal version control. Architects baseline the repository at governance milestones — the annual CPIC cycle, major program gates, OMB submission deadlines — then compare baselines to see how the architecture has changed, which investments shipped, and which plans moved. That history is what OMB reporting on progress against targets depends on.

What training do Federal EA teams need to use Sparx EA with FEAF?

Three areas: Sparx EA modeling fundamentals (navigation, diagrams, element management); ArchiMate notation, the primary modeling language for FEAF-aligned work; and the FEAF-specific configuration — how the MDG, package structure, and tagged-value sets fit together. Sparx Services runs Federal-specific training covering all three in the context of a live FEAF implementation.

What does the Configure the Solution engagement deliver for a Federal agency starting FEAF in Sparx EA?

A Pro Cloud Server deployment in an appropriate environment (AWS GovCloud or Azure Government), a FEAF 2.0-aligned MDG with reference-model stereotypes, a package structure mapped to the FEAF domains and the agency's organization, an initial application-portfolio import from existing inventory data, and a training program for the agency EA team.

Work with Sparx Services

Federal EA programs deserve a Sparx EA environment configured for Federal architecture from day one. Sparx Services' Configure the Solution engagement delivers a FEAF-configured repository — reference-model packages, MDG stereotypes, OMB-aligned tagged values — ready for your team to be productive immediately. If your agency is still assessing its readiness before committing to a full FEAF build, Paralysis to a Plan is the right starting point.

Keep reading

Standing up FEAF in Sparx EA?

Talk to a practitioner about a FEAF-configured repository — reference models, MDG stereotypes, and OMB-aligned reporting from day one.

Book a call →