SAF and DoDAF
This comparison uses the DoD Architecture Framework 2.02 and the DoDAF Meta-Model (DM2). The official DoD CIO site identifies version 2.02 as current and ties DoDAF conformance to architecture data defined through DM2 concepts, associations, and attributes, with exchange through the Physical Exchange Specification (DoDAF 2.02). SAF makes no such conformance claim.
Purpose and audience
SAF provides a shared description of a company at different maturity levels. DoDAF was created for architecture descriptions that support decisions and key processes of the United States Department of Defense. The official DM2 description lists capability development, planning and budgeting, acquisition, systems engineering, operational planning, and capability portfolio management among those processes (DM2).
DoDAF addresses architects, decision-process owners, systems engineers, program managers, and a broad range of mission stakeholders. Its scale, semantic precision, and mandatory context are substantially greater than SAF's minimal startup profile.
Architecture domains
DoDAF organizes content through eight viewpoints: All, Capability, Data and Information, Operational, Project, Services, Standards, and Systems. The Systems Viewpoint is retained for legacy descriptions, while the choice of data and presentations should follow decision-maker needs. The official page emphasizes the Fit-for-Purpose principle and gives priority to a consistent data model over producing every possible picture (Viewpoints and Models).
SAF layers intersect several viewpoints:
- business objects intersect Capability, Operational, Services, and Data and Information;
- applications and interactions intersect Services and Systems;
- infrastructure and hosting intersect Systems, Standards, and Location data;
- change over time and initiatives intersect Project and Capability, which are absent from the SAF core.
SAF concepts and mappings
| SAF object | Closest DoDAF/DM2 content | Assessment |
|---|---|---|
| Actor | Performer, Person Type, Organization Type, and Role | Composite, high: SAF deliberately combines several performer and owner types. |
| Channel | Interface, Service access, Resource Flow, and interaction means | Composite, medium: there is no single universal channel counterpart. |
| Service | Service and the outcome of supported activity | Partial, high: a DoDAF Service more often describes access to a capability, whereas SAF describes an outcome for an actor. |
| Process | Activity and sequences of Operational Activities | Partial, high. |
| Capability | Capability | Direct, high. |
| Information object | Information, Data, Resource, and their representations in the Data and Information Viewpoint | Composite, high. |
| System | System as a Performer/Resource and its composition | Partial, high: boundaries depend on the purpose of the architecture description. |
| Component | System part, Performer, or decomposed Resource | Partial, medium. |
| Interface | Interface and Resource Flow endpoints | Partial, medium. |
| Integration | Resource Flow, Exchange, interacting Performers/Services, and exchange rules | Composite, high: SAF materializes the interaction as a separate object. |
| Deployment | A Performer/Resource at a Location and solution configuration over time | Composite, medium. |
| Compute resource | System, Materiel, Facility, or another Resource | Composite, medium. |
| Network segment | Communication path/network, Resource Flow, and Location | Composite, medium. |
DM2 has conceptual, logical, and physical exchange levels. The conceptual model is intended for executives, the logical model refines attributes and relationships, and the PES adds implementation attributes for exchange (DM2 level description). A deterministic machine crosswalk is therefore a separate project, not a consequence of a terminology table.
Relationships
SAF expresses relationships as simple domain statements. DM2 aims for stricter semantics and federation of architecture data. The nearest groups include:
- “process requires capability” — relationships among Capability, Activities, and Performers;
- “system supports capability” — traceability from Capability to Activities, Services, and Systems;
- “integration transfers object” — a Resource Flow/Exchange between Performers with a transferred Resource or Information item;
- “deployment is hosted on resource” — configuration of Performer/Resource and Location;
- “actor owns object” — authority, responsibility, and organizational relationships that depend on the selected data set.
A SAF relationship cannot be declared a DM2 association without checking its domain, range, and required attributes. Conversely, many DM2 relationships are deliberately absent from SAF's compact core.
Views and artifacts
DoDAF distinguishes architecture data, viewpoints, DoDAF-described Models, and specialized Fit-for-Purpose Views. Official guidance explicitly states that not every model must be created and that the presentation should answer the decision-maker's question (Viewpoints and Models).
This aligns well with SAF's “one model, many views” principle. The difference is that SAF does not yet define a formal concern/viewpoint catalog or minimum data sets for specific decisions. DoDAF can demonstrate how to separate a semantic repository from tabular, graphical, or textual presentation.
Working method
DoDAF offers an architecture process that starts with purpose, scope, stakeholders, and required data, while allowing another method to be tailored. The main criterion is decision usefulness and data consistency, not mechanical completion of a full product set.
SAF can use this principle without copying the defense process: frame the decision, select the smallest slice of objects and relationships, and then build the view. Critical cross-organizational models need a separate exchange agreement, which SAF does not currently standardize.
Governance
DoDAF is closely tied to key-process owners, exchange requirements, DM2 configuration management, and reuse of architecture data. SAF is limited to model quality and responsibility for its objects. DoDAF therefore suggests two possible directions for SAF: link each view explicitly to a decision and formalize exchange semantics.
The DoD conformance regime should not be transferred to an ordinary company. The relevant principle for SAF is a verifiable data contract, not departmental procedures or a mandatory reporting set.
Maturity and tailoring
Fit-for-Purpose is not equivalent to the Startup, Stable business, and Enterprise profiles or to SAF maturity levels. DoDAF tailors content to the purpose of an architecture description; SAF varies type coverage and model-governance quality.
Together these axes provide a useful check: even an enterprise should not create a view without a question, while even a startup may need a rigorous small data slice for a critical decision.
Using DoDAF with SAF
- Startup: use only the “data for a decision” principle; formal DoDAF viewpoints are usually excessive.
- Stable business: selectively apply capability, operational, services, and data views to complex integrations and change programs.
- Enterprise or regulated environment: define an export profile from SAF to the required DM2 subset, with quality rules, provenance, and stable identifiers.
SAF can serve as an approachable input catalog for participants who do not work directly with DoDAF, but conversion to conformant data requires a separate, verifiable mapping.
Mapping limitations
DoDAF addresses a defense domain and uses a much richer ontology. Similar words such as service, system, or capability do not guarantee a complete DM2 match. This page does not test required data for a particular DoD process, PES schemas, or requirements for classified environments. No table in this section demonstrates DoDAF conformance.
Sources
- DoDAF 2.02 official site.
- DM2 purpose and levels.
- DoDAF Viewpoints and Models.
- DoDAF Data and Information Viewpoint.
- DoDAF/DM2 2.02 Version Description Document.
- General source rules are listed in the research source register.