An enterprise architecture framework is a structured, reusable way to describe how an organization is put together, across its business, data, applications, and technology, so that change can be planned instead of improvised. Rather than start from a blank page every time, architects use a framework that already defines the viewpoints to capture, the models to produce, and often a method to follow.
Six frameworks dominate the field: the Zachman Framework, TOGAF, FEAF, DoDAF, MODAF, and UAF. They are not interchangeable. Some classify, some prescribe a process, and some are built for defense. This guide explains the four architecture domains, the kinds of framework, a side-by-side comparison, and each of the main frameworks in turn.
What is an enterprise architecture framework?
An enterprise architecture framework is a set of models, viewpoints, and rules for designing and managing an organization’s systems as a whole. Different frameworks emphasize different things, but all of them exist to give a large organization one coherent picture of itself instead of a pile of disconnected diagrams.
The four architecture domains
Almost every framework organizes work into the same four domains, stacked from the business goals at the top down to the infrastructure that runs everything.
| Domain | What it covers | Question it answers |
|---|---|---|
| Business | Goals, capabilities, processes, and organization structure | What does the business do, and who does it? |
| Data / Information | The data the business relies on, and how it is defined and governed | What information do we hold, and who owns it? |
| Application | The applications and how they integrate to support the business | Which systems support each capability? |
| Technology | Hardware, operating systems, middleware, and networks | What does everything run on? |
The business domain sets direction. If a retailer wants to grow market share, this is where the goal and the capabilities to reach it are defined. The application domain plans the systems that support those capabilities and how new tools fit with the ones already in place. The data domain defines the transaction, master, reference, and metadata the business runs on, and who is accountable for its accuracy and security. The technology domain provides the hardware and software foundation the other three depend on.
The kinds of enterprise architecture framework
Frameworks are easiest to understand once you sort them by what they actually do, because they do genuinely different jobs:
- Taxonomy or ontology. A classification scheme for architecture artifacts. It tells you what to document and whether the picture is complete, but not how to build anything. The Zachman Framework is the classic example.
- Process or methodology. A step-by-step method for developing and governing architecture. TOGAF, through its Architecture Development Method (ADM), is the dominant one.
- Reference-model framework. A set of prebuilt models an organization reuses rather than invents. FEAF, for the US federal government, is the leading example.
- Defense and domain-specific. Frameworks built for military and government programs, with fixed viewpoints for capability and systems-of-systems work: DoDAF, MODAF (now retired), NAF, and UAF.
The main EA frameworks compared
| Framework | Origin | Type | Best for | Status |
|---|---|---|---|---|
| Zachman | John Zachman, first published 1987 (IBM) | Taxonomy / ontology (6×6 grid) | Completeness: making sure every viewpoint is documented | Current (v3.0, 2011) |
| TOGAF | The Open Group, 1995 (from the US DoD’s TAFIM) | Methodology (the ADM process) | End-to-end architecture delivery and governance | Current (TOGAF 10, 2022) |
| FEAF / FEA | US OMB, 1999 (after the 1996 Clinger-Cohen Act) | Reference-model framework | US federal and large public-sector IT | Current (federal use) |
| DoDAF | US Department of Defense, v1.0 in 2003 | Defense viewpoint framework | US defense and systems-of-systems programs | Current (v2.02) |
| MODAF | UK Ministry of Defence, 2005 (from DoDAF) | Defense view framework | Historically UK defense programs | Withdrawn (~2020), superseded by NAF |
| UAF | Object Management Group (OMG), from UPDM | Unified profile (UML / SysML) | Cross-sector and defense integration modeling | Current |
1. Zachman Framework
The Zachman Framework is the foundational EA structure and the oldest of the six. It is an ontology, a 6×6 grid that classifies every artifact by the question it answers (What, How, Where, Who, When, Why) and the stakeholder viewpoint it serves (from planner down to user). It tells you what a complete architecture looks like; it does not prescribe a process for building one.
- Six interrogatives: What, How, Where, Who, When, and Why.
- Six viewpoints: planner (scope), owner (business concepts), designer (system logic), builder (technology), subcontractor (components), and user (operations).
- Value: an empty cell is a visible gap in your documentation, which makes it a strong completeness check.
For more detail, see our full guide to the Zachman Framework.
2. The Open Group Architecture Framework (TOGAF)
TOGAF is the most widely adopted EA framework in commercial use. The Open Group created it in 1995, originally based on TAFIM, the US Department of Defense’s Technical Architecture Framework for Information Management. Where Zachman classifies, TOGAF prescribes a method: its Architecture Development Method (ADM) walks an architect through eight phases, from architecture vision to implementation governance and change management. The current release is TOGAF 10 (2022).
- The ADM: a repeatable cycle of phases (A to H) for developing and governing architecture.
- Adaptable: used by everyone from small businesses to government and defense, and tailored to each.
- Complementary to Zachman: many teams use the Zachman grid as a completeness checklist inside TOGAF’s process.
For more detail, see our guide to TOGAF.
3. DoDAF
The Department of Defense Architecture Framework (DoDAF) is built for the business and operational needs of the US Department of Defense. First released in 2003 and now at version 2.02, it structures architecture into viewpoints so decision-makers can focus on one concern while keeping a coherent whole. Its eight viewpoints are:
- All Viewpoint: overarching context that applies to every other viewpoint.
- Capability Viewpoint: capability requirements, delivery timing, and deployed capabilities.
- Data and Information Viewpoint: data relationships and structures behind the capabilities.
- Operational Viewpoint: the scenarios, activities, and requirements the mission needs.
- Project Viewpoint: how projects map to requirements, including acquisition dependencies.
- Services Viewpoint: the performers, activities, and services that deliver the solution.
- Standards Viewpoint: the standards, policies, and constraints that apply.
- Systems Viewpoint: system composition and interconnection (retained largely for legacy support).
For more detail, see our guide to DoDAF.
4. MODAF (retired, replaced by NAF)
MODAF was the UK Ministry of Defence’s architecture framework, released in 2005 and adapted from DoDAF. It is important to be current on its status: the UK MoD has withdrawn MODAF and moved to the NATO Architecture Framework (NAF). The MoD’s guidance pages for MODAF are marked withdrawn, and its 2024 Defence Architecture Framework adopts NAFv4 as the preferred standard. Existing MODAF artifacts remain in use, but new UK defense work is done in NAF.
MODAF organized architecture into seven view categories, a structure NAF and UAF carried forward:
- Strategic Views (StV): the desired outcomes and the capabilities required.
- Operational Views (OV): the processes, information, and entities needed, in abstract terms.
- Service-Oriented Views (SOV): the services that support the operational processes.
- Systems Views (SV): the physical implementation of the operational and service views.
- Acquisition Views (AcV): the dependencies and timelines of the delivering projects.
- Technical Views (TV): the standards that apply to the solution.
- All Views (AV): the overview and glossary that tie the architecture together.
For more detail, see our guide to MODAF.
5. FEAF
The Federal Enterprise Architecture Framework (FEAF) is the framework for designing IT across the US federal government. The government first published FEAF in 1999, prompted by the 1996 Clinger-Cohen Act, and the Office of Management and Budget (OMB) developed the Federal Enterprise Architecture (FEA) reference models through the early 2000s. FEAF draws on ideas from both Zachman and TOGAF.
Its core is a set of five reference models that give federal agencies a shared vocabulary so architectures can be compared and reused:
- Performance Reference Model (PRM): a standard way to describe the value an architecture delivers.
- Business Reference Model (BRM): the business functions of the federal government, independent of the agencies that perform them.
- Service Component Reference Model (SRM): the service components that support business and performance goals.
- Data Reference Model (DRM): a standard way to describe and share data.
- Technical Reference Model (TRM): the standards and technologies that support service delivery.
6. Unified Architecture Framework (UAF)
The Unified Architecture Framework (UAF), from the Object Management Group (OMG), is the modern successor to the earlier Unified Profile for DoDAF and MODAF (UPDM). It gives commercial, industrial, and defense organizations a single, standards-based way to model architecture.
- Broad reach: meets the needs of the US DoD, the UK MoD, NATO, and commercial industry from one framework.
- Standards-based: built on UML and SysML, so architecture data moves cleanly between tools.
- Backward compatible: supports DoDAF, MODAF, and NAF products while allowing commercial extensions.
- Methodology-agnostic: works with structured or object-oriented approaches.
Other frameworks worth knowing
Beyond the main six, several specialized frameworks exist. NAF (NATO Architecture Framework, current v4) is the standard for NATO and allied defense, and now the UK’s chosen framework. UPDM was the OMG profile that unified DoDAF and MODAF and has since been folded into UAF. Open Agile Architecture (O-AA), from The Open Group, targets agile and digital transformation teams. Vendor and sector variants also exist, such as the SAP Enterprise Architecture Framework (an extension of TOGAF) and ISO 19439 for enterprise modeling, along with domain frameworks for healthcare, banking, and manufacturing.
Benefits and challenges of EA frameworks
What a framework gives you: a shared language across departments, a clearer link between business goals and IT, better planning and impact analysis for change, and less duplicated or conflicting effort across systems.
Where EA programs struggle is rarely the framework itself. The recurring failure modes are:
- No business buy-in. Without support from leadership and business units, EA stalls. The fix is to show benefits in the language leaders care about and tie EA to real goals.
- No leadership or vision. EA needs a champion and a roadmap, or it fragments into disconnected efforts.
- Wrong tool, or no tool. A poor tool choice buries the team in data instead of insight. Match the tool to the organization’s size and scale.
- Planning without action. Endless modeling with nothing delivered is a common trap. Balance documentation with results.
- Trying to model everything. Capturing every detail is counterproductive. Prioritize the components that matter and leave the rest.
- Working at the wrong level. Treating a strategic problem as an operational one, or the reverse, wastes effort. Match the response to the level of the problem.
FAQs
What is the difference between an enterprise architecture framework and a methodology?
A framework defines the structure: the viewpoints, models, and artifacts that describe an enterprise, and it tells you what to capture. A methodology defines the process: the steps for actually developing and governing the architecture. TOGAF’s ADM is a methodology. The Zachman Framework is a taxonomy or ontology, not a methodology, because it classifies artifacts rather than prescribing steps. Many organizations combine the two.
Which enterprise architecture framework should I choose?
It depends on your goal and sector. Use TOGAF when you need a repeatable process for delivering and governing architecture. Use Zachman when you need a completeness checklist for what to document. Use FEAF for US federal and public-sector IT, and DoDAF or NAF for defense programs. UAF suits cross-sector modeling on UML and SysML. Many mature teams pair Zachman for coverage with TOGAF for delivery.
Is MODAF still used?
Not for new work. The UK Ministry of Defence has withdrawn MODAF and adopted the NATO Architecture Framework (NAF); its 2024 Defence Architecture Framework uses NAFv4. Existing MODAF artifacts remain in circulation, but new UK defense architecture is done in NAF, and UAF can produce NAF products.
What are the four enterprise architecture domains?
Business, data (or information), application, and technology. The business domain covers goals, capabilities, and processes; the data domain covers the information the business relies on; the application domain covers the systems that support it; and the technology domain covers the infrastructure everything runs on.
Conclusion
Enterprise architecture frameworks give a structure for describing an organization’s systems as one coherent whole. The main six, Zachman, TOGAF, DoDAF, MODAF, FEAF, and UAF, each suit a different context, from federal government to defense to general enterprise IT. The right choice comes down to your industry, the regulations you answer to, and how prescriptive a method you want. In practice, the strongest programs combine a classification framework for coverage with a methodology for delivery, rather than betting everything on one.
Reference