Sparx EA gives US Federal agency EA teams the modeling environment to implement FEAF 2.0’s five reference models in a governed, OMB-aligned repository: with a FEAF-configured MDG, ArchiMate-mapped domain architecture, and integrated FISMA compliance modeling.
The Federal Enterprise Architecture Framework (FEAF) 2.0 is the architecture governance framework for US Federal agencies, providing a common reference model for describing, comparing, and integrating agency architectures across the Federal government. For Federal EA teams, FEAF is not optional: OMB Circular A-130 establishes EA as a requirement for Federal agencies, and FEAF provides the structure. But FEAF’s five reference models represent a significant architectural commitment that requires a capable, governed EA tool. Sparx EA, configured with a FEAF-aligned MDG and an ArchiMate-to-FEAF domain mapping, provides Federal EA teams with the environment they need to fulfill OMB EA requirements, support IT investment governance through the IT Portfolio Management process, and align architecture documentation with FISMA compliance reporting. This article explains how to implement FEAF in Sparx EA, what Federal EA teams actually build, and how Sparx Services configures the environment for immediate Federal EA productivity.
Key Takeaways
- FEAF 2.0’s five reference models (Performance, Business, Service Component, Technical, Data) map directly to ArchiMate layers in Sparx EA.
- A FEAF-configured MDG in Sparx EA provides the right stereotypes, tagged values, and package structure for Federal EA programs.
- Federal EA teams use Sparx EA primarily for as-is and target architectures for major IT investments (CPIC submissions), application portfolio management, and FISMA compliance architecture.
- OMB reporting requirements: including IT Portfolio Management process contributions: are supported by tagged values and reporting scripts in Sparx EA.
- Sparx Services’ Deploy engagement delivers a FEAF-configured Sparx EA repository ready for immediate use by Federal EA teams.
FEAF 2.0: The Five Reference Models
FEAF 2.0 is structured around five reference models that provide a common taxonomy and classification framework for Federal architecture:
Performance Reference Model (PRM): Connects IT investments to measurable outcomes and mission performance. The PRM asks: what is the IT investment supposed to achieve, how will success be measured, and how does it contribute to agency mission performance? In Sparx EA, PRM elements are modeled in the Strategy layer as Goals and Outcomes linked to IT investments and capabilities.
Business Reference Model (BRM): A classification of Federal business and support services, enabling cross-agency comparison and identification of shared services opportunities. The BRM organizes Federal functions into Domains (Services for Citizens, Mode of Delivery, Support Delivery of Services), Business Areas, Lines of Business, and Sub-Functions. In Sparx EA, BRM elements are modeled as Business Functions and Services in the Business layer, linked to the specific agency processes and capabilities they represent.
Service Component Reference Model (SRM): A classification of IT service components, enabling identification of shared services and reuse opportunities across agencies. The SRM organizes IT capabilities into Service Types and Service Components. In Sparx EA, SRM elements are modeled as Application Services and Application Components in the Application layer.
Technical Reference Model (TRM): A classification of standards, technologies, and specifications that support Federal IT. The TRM provides the approved technology vocabulary: standards for security (NIST), accessibility (Section 508), interoperability, and cloud (FedRAMP-authorized services). In Sparx EA, TRM elements are modeled as Technology Nodes and System Software in the Technology layer, with references to applicable standards as tagged values.
Data Reference Model (DRM): A framework for describing Federal data and its relationships: supporting data governance, data sharing, and interoperability across agencies. The DRM encompasses data context (the meaning and structure of data), data description (metadata standards), and data sharing (how data is exchanged). In Sparx EA, DRM elements are Data Objects in the Information layer, with NIEM (National Information Exchange Model) mapping as a tagged value where applicable.
ArchiMate-to-FEAF Domain Mapping
FEAF and ArchiMate use different but compatible vocabularies. The mapping that Sparx Services establishes for Federal EA teams:
| FEAF Domain | ArchiMate Layer | Key Element Types |
|---|---|---|
| Performance (PRM) | Strategy Layer | 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 Layer | Data Objects, Data Elements, Data Flows |
This mapping is encoded in the Sparx EA package structure: five top-level packages (one per reference model), each with sub-packages aligned to the FEAF classification hierarchy. ArchiMate elements within each package carry FEAF Reference Model stereotypes from the MDG, making the FEAF classification visible within the EA tool.
What Federal EA Teams Actually Build
While FEAF provides the reference framework, the practical work of Federal EA teams focuses on specific deliverables that support agency governance and OMB reporting.
As-Is and Target Architecture for Major IT Investments
The Capital Planning and Investment Control (CPIC) process requires Federal agencies to document the business and technical justification for major IT investments. Architecture artifacts: as-is application landscape, target architecture, transition plan: are core CPIC deliverables. In Sparx EA, the as-is architecture is built at the Application and Technology layers for each major IT system in the CPIC portfolio. Tagged values on Application Components record: system name, owner agency component, CPIC investment ID, system lifecycle phase (Steady State/Development/Operations and Maintenance/Disposition), annual operating cost, and FISMA categorisation (Low/Moderate/High).
The target architecture documents the planned state of each IT system following a modernisation or migration program. ArchiMate Work Packages represent the transition steps, linked to CPIC milestones.
Application Portfolio Management
Every Federal agency maintains a portfolio of IT systems: typically documented in the OMB Federal IT Dashboard. Sparx EA provides the governed modeling environment for this portfolio: each system is an Application Component, each organisational owner is a Business Actor, and the relationships between systems (dependencies, integrations, shared services) are ArchiMate Application relationships.
Tagged values on Application Components support OMB reporting requirements: Agency systems that share data with other Federal agencies (data.gov interoperability), systems subject to the 25 Point Implementation Plan for cloud-first, and systems in scope for legacy modernisation under the Technology Modernization Fund (TMF).
IT Portfolio Management Process Contributions
FEAF architecture directly supports the OMB IT Portfolio Management (ITPM) process. The architecture repository provides the authoritative source for: system inventory (what systems exist and who owns them), system relationships (which systems share data or services), duplication and consolidation opportunities (where two agencies run the same capability), and investment alignment (which IT investments support which mission capabilities).
Sparx EA’s reporting scripts generate the architecture views and data extracts needed for ITPM contributions: reducing manual effort and improving data quality in OMB submissions.
FEAF-Aligned MDG Configuration
A FEAF-aligned MDG in Sparx EA provides:
«FEAF BRM Function»: Business Function stereotype with Line of Business and Sub-Function tagged values aligned to the BRM taxonomy«FEAF SRM Component»: Application Component stereotype with Service Type and Service Component tagged values from the SRM«FEAF TRM Standard»: Technology Node stereotype with TRM Service Area and Standard/Specification tagged values«FEAF DRM Data Object»: Data Object stereotype with NIEM reference, data classification (public/controlled/classified), and DRM context tagged values«CPIC Investment»: Application Component stereotype for major IT investments, with CPIC investment ID, lifecycle phase, annual cost, and TMF status tagged values«FISMA System»: Application Component stereotype with FISMA impact level, ATO status, ATO expiry date, and ISSO responsible party tagged values
Model validation rules enforce: all CPIC investments must have a lifecycle phase tagged value; all systems with FISMA categorisation of Moderate or High must have an ATO status of Active or In Progress.
Integration with FISMA Compliance Architecture
The Federal Information Security Management Act (FISMA) requires Federal agencies to implement an information security program based on NIST SP 800-53 controls. The intersection of FEAF architecture and FISMA compliance is the System Boundary: the defined scope of each IT system for FISMA purposes.
In Sparx EA, the FISMA System Boundary is a container package that groups all Application Components and Technology Nodes within a specific ATO (Authority to Operate) scope. The «FISMA System» stereotype on Application Components records which ATO boundary they belong 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 (described in a companion article). This creates architecture-embedded compliance documentation: each FISMA-scoped system has its control implementation documented within the Sparx EA model, rather than in a separate SSP document that quickly becomes stale.
For cloud services within the FISMA boundary, FedRAMP-authorized services are modeled as Technology Nodes with FedRAMP Authorization Level (Low/Moderate/High) and Authorization Date tagged values. This makes the FedRAMP compliance status of cloud services visible within the broader FEAF architecture.
Governance and OMB Oversight
The Federal CIO Council and OMB provide governance oversight for Federal EA programs. Agency Chief Architects report to their respective Agency CIOs, and EA program health is assessed through OMB’s EA program reviews.
Sparx EA supports this governance structure through its role-based access model and its reporting capability. The Sparx EA repository is the agency’s authoritative architecture record. Access controls ensure that only authorized architects can modify architecture elements, while stakeholders across the agency can view architecture diagrams and query architecture data.
The OMB Federal IT Dashboard requires regular data submissions on IT investment performance, system inventory, and cost data. Tagged values in the Sparx EA repository store this data, and EA GraphLink connections to Power BI generate the dashboard views needed for OMB submissions and internal governance reporting.
Practical Considerations for Federal Deployment
Federal deployments of Sparx EA have specific requirements:
Security: FedRAMP-authorized deployment options (Azure Government Cloud, AWS GovCloud) are required for systems handling Controlled Unclassified Information (CUI). Sparx EA’s Pro Cloud Server can be deployed within FedRAMP-authorized cloud environments. For classified architectures, on-premises deployment within classified network enclaves is supported.
Procurement: Sparx EA is available through GSA Schedule 70 (IT Products and Services). Professional services for EA configuration, MDG development, and training are available through GSA Schedule and agency-specific IDIQ vehicles.
Accessibility: Federal systems must comply with Section 508 accessibility requirements. Sparx EA’s web-based architecture portal (via Pro Cloud Server) supports Section 508 compliant access for architecture consumers who do not need the full modeling tool.
FAQ
Q1: Is FEAF the same as TOGAF or DoDAF? No. FEAF, TOGAF, and DoDAF are distinct frameworks with different origins, target audiences, and structures. FEAF is specific to US Federal civilian agencies and is mandated by OMB. TOGAF (The Open Group Architecture Framework) is a commercial framework widely used in private sector and government globally. DoDAF (Department of Defense Architecture Framework) is specific to US defense programs. The frameworks can be complementary: some Federal agencies use TOGAF’s ADM (Architecture Development Method) as their architecture process while using FEAF’s reference models for classification: both supported in Sparx EA.
Q2: How does FEAF align with the Technology Modernization Fund (TMF)? The Technology Modernization Fund provides Federal agencies with funding for IT modernisation projects, repaid from future IT cost savings. TMF proposals require architecture documentation showing the current-state system, the proposed modernized state, and the transition plan. FEAF-aligned architecture documentation in Sparx EA: as-is application landscape, target architecture, Work Package roadmap: provides exactly the artifacts needed for TMF proposal development. Sparx Services has experience supporting TMF proposal architecture work.
Q3: Can Sparx EA support a multi-agency EA program (e.g., an inter-agency shared service)? Yes. Sparx EA Pro Cloud Server supports multi-tenancy and federated architecture repositories. For an inter-agency shared service program (such as a shared IT platform serving multiple agencies), a shared Sparx EA repository can be hosted centrally with agency-specific packages and access controls. Each agency sees and can contribute to the shared service architecture package, while maintaining separation of its own agency-specific architecture.
Q4: How does Sparx EA handle classified architecture documentation? For architectures that include classified systems or information, Sparx EA can be deployed on-premises within a classified network enclave (SIPR, JWICS as appropriate). The architecture repository is physically separated from unclassified systems, and access controls enforce the classification handling requirements. Sparx Services has experience supporting classified EA deployments through appropriate security clearance and handling arrangements.
Q5: What is the relationship between FEAF and the Federal Data Strategy? The Federal Data Strategy (OMB M-19-18) establishes principles, practices, and action steps for Federal data governance. The FEAF Data Reference Model (DRM) is the architecture framework for Federal data. In Sparx EA, the DRM package is linked to the Federal Data Strategy requirements: data inventories, data governance structures, interoperability standards (NIEM), and open data requirements (OPEN Government Data Act). This creates a unified architecture-and-governance view of Federal data assets.
Q6: How do Federal agencies handle the version management of FEAF architecture as agency systems evolve? Sparx EA’s baseline and version management capability supports Federal EA version control. Architecture baselines are created at significant governance milestones (annual CPIC cycle, major program milestones, OMB submission deadlines). Architects can compare baselines to understand how the architecture has evolved, which investments have been delivered, and which plans have changed. This version history is essential for OMB reporting: showing progress against planned architecture targets.
Q7: What training do Federal EA teams need to use Sparx EA effectively with FEAF? Federal EA teams need three areas of training: (1) Sparx EA modeling fundamentals (tool navigation, diagram creation, element management); (2) ArchiMate notation (the primary modeling language for FEAF-aligned architecture in Sparx EA); and (3) FEAF-specific configuration (how the FEAF MDG, package structure, and tagged value sets work). Sparx Services provides Federal-specific training programs that cover all three areas in the context of FEAF implementation, reducing the time to productive Federal EA practice.
Q8: What does the Deploy engagement deliver for a Federal agency starting FEAF in Sparx EA? Sparx Services’ Deploy engagement for Federal FEAF implementation delivers: a Sparx EA Pro Cloud Server deployment in an appropriate environment (AWS GovCloud or Azure Government), a FEAF 2.0-aligned MDG configuration with the five reference model stereotypes, a package structure aligned to the FEAF reference models and the agency’s organisational structure, an initial application portfolio import (from existing system inventory data), and a training program for the agency EA team. Deploy starts at $30,000.
Work With Sparx Services
Federal EA programs deserve a Sparx EA environment configured for Federal architecture from day one. Sparx Services’ Deploy engagement delivers a FEAF-configured repository: five reference models, MDG stereotypes, OMB-aligned tagged values: ready for your Federal EA team to be productive immediately.
Our Discover engagement is the right starting point if your agency is assessing its EA readiness before committing to a full FEAF implementation.
Deploy from $30,000 | Discover from $25,000. Contact us to discuss your Federal EA requirements.
