FEAF – Federal Enterprise Architecture Framework
FEAF provides a set of reference models to describe performance, business functions, services, data, and technology in a consistent way. Nexinc adapts FEAF concepts for both public and private organisations to create clear, segmented architecture that decision makers can actually use.
FEAF is built around a family of reference models that provide a common language for describing how the organisation works, the services it provides, the information it manages, and the technology it runs on. Nexinc uses FEAF to:
FEAF plays a complementary role alongside TOGAF, BIZBOK and LeanIX:
For non-government organisations we typically use a “FEAF-inspired” set of reference models – the structure without the bureaucracy.
We focus on the FEAF reference models that help answer concrete questions: what value do we deliver, what business functions perform it, which services & systems support it, and what technology and data sit underneath.
Align strategic outcomes and KPIs with capabilities and services. Used to make sure EA work is driven by measurable results.
Functional view of what the organisation does. We map this to BIZBOK capabilities to get both structure and traceability.
Catalogue of services delivered to customers, partners and internal consumers. Helps avoid duplicate service delivery.
High-level information domains and data subject areas. Foundation for master data and integration design.
Technology service areas and standards. We align this with your cloud platforms and runtime products.
Information, security and privacy concerns layered over the other models to support risk and compliance conversations.
The power of FEAF comes from alignment: the same strategy and capability shows up consistently in performance, business, service, data and technology views. Below is a “Nexinc blue” sketch of that alignment.
FEAF Alignment Stack
From strategic outcome to technology component.
Top: Why & What
PRM – Strategic Outcome
Define the outcome and KPI (e.g. “Reduce time-to-market by 30%”). Linked to a BRM/BIZBOK capability cluster.
BRM – Function
Describe which business functions and capabilities perform the work that drives the outcome.
Middle: Services & Data
SRM – Service View
Map concrete services (APIs, portals, internal services) that realise the functions. Basis for service catalogue and reuse.
DRM – Data Domains
Identify the key information domains, ownership, and master data sources those services rely on.
Bottom: Systems & Technology
Application & TRM View
Which applications, platforms and technologies deliver the services and data – with lifecycle and risk attributes.
Security / IRM Overlay
Apply security, privacy and compliance requirements to the stack so risk conversations are fact-based.
In practice we implement these relationships in the chosen EA tool (LeanIX or similar) so every outcome, capability and system can be traced in both directions.
We don’t “install FEAF” as a big-bang exercise. We selectively apply the reference models where they help create clarity and better decisions.
Step 1 – Scoping
Decide which models to use (PRM, BRM, SRM, etc.) and how deep to go, based on your questions and constraints.
Step 2 – Modelling
Populate a pragmatic set of business functions, services, data domains and technology categories.
Step 3 – Mapping
Connect applications, projects and KPIs to the FEAF models, usually via LeanIX or another EA tool.
Step 4 – Use
Use the FEAF-based views in portfolio reviews, strategy workshops, and risk committees so the model earns its place.
The goal is not “FEAF compliance” – it is a common language that simplifies complex discussions and accelerates agreement.
Considering FEAF but worried it will become a bureaucracy? We typically start with one segment (e.g. service & data) and prove value in a single portfolio before expanding.
Discuss a FEAF-Lite Approach