FEAF in Sparx EA: Implementing the Federal Enterprise Architecture Framework

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 a requirement: OMB Circular A-130 establishes enterprise architecture, and FEAF supplies the structure. The 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 comes together.

A Federal architect uses FEAF to describe the agency in a common language and to show how each investment serves the mission. Today the architect builds the reference-model packages and the investment views by hand and collects system facts from many owners. The AI-augmented way is to decide the structure and the classification rules, let AI build the packages and relationships in the repository, and connect the systems that already hold investment, cost and authorization data. The skill is knowing the reference models well enough to state the classification precisely and to review what AI produces.

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. It replaced the earlier Federal Enterprise Architecture reference models, which used a Service Component Reference Model and a Technical Reference Model, with Application and Infrastructure reference models. Many Federal practitioners still use the older names, so expect to see both. The six reference models are:

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 and Motivation layers 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.

Application Reference Model (ARM). A classification of applications and the service components they provide, which surfaces reuse and shared-services opportunities across agencies. In Sparx EA, ARM elements are Application Services and Application Components in the Application layer.

Infrastructure Reference Model (IRM). The infrastructure vocabulary: platforms, networks, and facilities, together with the standards that apply to them, such as NIST guidance, Section 508 for accessibility, and FedRAMP-authorized cloud services. In Sparx EA, IRM 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 Application layer, with NIEM (National Information Exchange Model) references captured as tagged values where they apply.

Security Reference Model (SRM). The security controls and boundaries that run across all of the others, modeled as the Requirements, controls, and system boundaries described later in this article.

ArchiMate-to-FEAF domain mapping

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

ArchiMate-to-FEAF domain mapping

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
Application (ARM)	Application Layer	Application Components, Application Services
Infrastructure (IRM)	Technology Layer	Technology Nodes, System Software, Communication Networks
Data (DRM)	Application Layer	Data Objects, Application Interfaces
Security (SRM)	Motivation / Technology	Requirements, Constraints, the Technology elements that implement controls

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 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 estate, 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. Each Application Component carries its CPIC investment ID and FISMA categorization (Low, Moderate, High). Lifecycle phase, annual operating cost and similar facts are held by your project and portfolio, financial management, and risk and compliance systems, and the AI-augmented way is to connect those systems to the model rather than record the values in the repository.

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.

Relationships and connected system data 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).

Reports and extracts generated from the repository can supply the views and data that ITPM contributions need, which cuts manual effort and improves 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:

1. «FEAF BRM Function», a Business Function stereotype with Line of Business and Sub-Function tagged values aligned to the BRM taxonomy.
2. «FEAF ARM Component», an Application Component stereotype with Service Type and Service Component tagged values from the ARM.
3. «FEAF IRM Standard», a Technology Node stereotype with IRM Service Area and Standard/Specification tagged values.
4. «FEAF DRM Data Object»: a Data Object stereotype with NIEM reference, data classification (public/controlled/classified), and DRM context tagged values.
5. «CPIC Investment»: an Application Component stereotype for major investments, with the CPIC investment ID and a link to the investment record.
6. «FISMA System»: an Application Component stereotype with the FISMA impact level and the system boundary it belongs to. ATO status, expiry date, and the responsible ISSO are held by your governance, risk and compliance system and connected to the model.

Model validation rules do the enforcement: every CPIC investment must link to a system and an owner, and every system categorized Moderate or High must sit inside a defined system boundary. 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), with the authorization date brought in from the system that tracks it, 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. The model links those values to systems and owners, and dashboards in Prolaborate or Power BI (see reporting and Power BI) generate the 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. Routes depend on your reseller and your agency's contract vehicles, so confirm them with your contracting office.

Accessibility. Federal systems must meet Section 508 requirements. Web-based access to the architecture, served through Pro Cloud Server, lets architecture consumers view the model without the full modeling tool. Confirm accessibility conformance against your own Section 508 requirements.

Frequently asked questions

What this means for the architect

A Federal EA program needs its Sparx EA environment, reference-model packages and ways of working set up for Federal architecture from the start. Configure the Solution covers the environment and governance around your FEAF model. If your agency is still assessing its readiness before committing to a full FEAF build, Paralysis to a Plan is a starting point. The architect's contribution is the classification rules and the review of what AI builds.