FEAF and DoDAF are both US government EA frameworks, but one targets civilian federal agencies and the other targets defense/military systems. What distinguishes their scope and typical deliverables, and why wouldn't a private-sector company typically adopt either one wholesale?

## What each is built around **FEAF** structures an agency's architecture around a small number of standard reference models - covering things like business functions, service components, data classification, and technology standards - that let federal budget oversight bodies compare architecture and spending across many different agencies using consistent categories, because oversight needs to answer questions like 'how much is the government spending, across all agencies, on a given category of IT capability,' and that's only answerable if every agency describes itself the same way. **DoDAF**, by contrast, is built around viewpoints tuned to military operations. It separates: - **operational concerns** - who does what, in what sequence, exchanging what information, in a military mission; - from **systems/services concerns** - which platforms and systems implement those operational needs; - and **standards concerns** - which technical protocols must be followed for interoperability. Those viewpoints exist because a modern defense capability - a joint air-and-missile-defense mission, for instance - is delivered by many independently procured systems built by different contractors for different services that must nonetheless interoperate in real time, often with allied forces using different equipment. ## Why each exists Why it exists: - **FEAF exists** because federal spending oversight requires agencies to justify major IT investments and demonstrate they aren't duplicating capability across agencies, and without a common architecture framework, comparing one agency's claims-processing capability cost against a similar capability at another agency would be impossible - each agency would describe itself in its own terms. - **DoDAF exists** because defense acquisition is famously siloed: individual programs (a specific aircraft, a specific radar system) are run by separate program offices, often years apart, and without a shared architectural description discipline that explicitly models operational information exchange requirements, integration failures - a fighter jet's system that can't share targeting data with a ship's system - get discovered late, expensively, sometimes in the field. DoDAF's viewpoint separation forces programs to document operational information exchanges explicitly and early, so interoperability gaps are visible during design rather than during a live exercise. ## What adoption buys, and what it costs Trade-offs on each side: | Adopting | What it buys | The price | |---|---|---| | **FEAF's reference-model structure** | buys an agency comparability with peer agencies and defensible budget justifications | at the cost of forcing local architecture work into categories designed for cross-agency rollup rather than categories that best fit that specific agency's actual operations - a very mission-specific agency may find the standard reference models a poor fit for how it actually thinks about its work, requiring awkward mapping exercises | | **DoDAF** | buys rigorous interoperability analysis and a shared vocabulary across services and coalition partners | at a very high documentation cost - the resulting products are numerous and detailed, appropriate for programs where an interoperability failure could be catastrophic (aircraft losing a targeting feed mid-mission) but wildly disproportionate for, say, a back-office payroll system, even one owned by a defense agency | ## Where a commercial company stops short Why a private company wouldn't adopt either wholesale: both frameworks bake in structural assumptions that only make sense given a specific governance context. - **FEAF's reference models** are shaped by the specific federal budget-oversight process - a private company has no equivalent external body mandating cross-company IT spend comparability, so importing FEAF's categories just adds translation overhead without the payoff FEAF was built for. - **DoDAF's viewpoint structure** is shaped by the extreme, safety-and-mission-critical interoperability problem of independently procured military systems that must work together in combat - most commercial companies don't have anywhere near that degree of siloed, safety-critical, multi-vendor system interoperability risk, so the enormous documentation discipline DoDAF demands would be pure overhead relative to the risk it's designed to manage. In practice, private-sector architects sometimes borrow specific ideas from these frameworks (DoDAF's operational-vs-systems viewpoint separation is genuinely useful for describing any complex system-of-systems, and some large enterprises with similarly siloed legacy-system landscapes have adapted it informally) without adopting the full framework and its government-specific reference models and reporting cadence. ## How it goes wrong on each side Failure mode on each side: - **DoDAF** - the recurring real-world failure is a systems-integrator or contractor forcing a full DoDAF deliverable set onto a program that doesn't need it (a low-risk, single-vendor system) purely because 'the customer is DoD, so we always do DoDAF,' burning budget on documentation that adds no interoperability-analysis value at that program's actual risk level. - **FEAF** - conversely, the failure on the FEAF side is agencies producing reference-model-conformant architecture documents purely to pass an oversight checkpoint without those documents reflecting the agency's actual target-state thinking, since the reference model's categories don't match how the agency's own staff think about their mission.