SAF and ArchiMate

This comparison uses ArchiMate® 3.2. The Open Group identifies this as the current edition and dates its release to October 2022 (official download and licensing page). SAF does not use the official ArchiMate notation and does not claim conformance with its metamodel.

Purpose and audience

SAF defines a minimal vocabulary of company facts, usage profiles, and relationship-quality requirements. ArchiMate defines a language for expressing architecture consistently and presenting it to different stakeholders. The Open Group describes it as a visual modeling language that complements TOGAF in representing, communicating, and analyzing architecture (using the standards together).

SAF can be used without knowledge of a specialized notation. ArchiMate is primarily useful to architects, analysts, and repository owners who need consistent diagram semantics, permitted-relationship rules, and repeatable viewpoints.

Architecture domains

ArchiMate covers Motivation, Strategy, Core, and Implementation & Migration. Core is divided into Business, Application, and Technology layers, and the language also supports physical elements. The Open Group certification material separately identifies motivation, strategy, business, application, technology, implementation and migration, relationships, and viewpoints (ArchiMate 3 Practitioner competencies).

The three SAF layers are close to Business, Application, and Technology, but SAF deliberately excludes motivation, strategic resources and courses of action, projects, work packages, plateaus, and gaps. ArchiMate keeps these areas in one language and supports traceability from reasons for change through implementation.

SAF concepts and mappings

SAF object	Closest ArchiMate concept	Assessment
Actor	Business Actor and Business Role; Stakeholder for an external interested party	Composite, high: SAF does not separate the bearer of responsibility from the role.
Channel	Business Interface; sometimes Path or Technology Interface for a technical channel	Partial, high.
Service	Business Service	Direct, high.
Process	Business Process	Direct, high.
Capability	Capability	Direct, high.
Information object	Business Object, Data Object, Representation, and Meaning	Composite, high; SAF specializations decompose naturally.
System	Application Collaboration, Grouping, or an agreed composition of Application Components	Composite, medium: there is no universal System element in the application layer.
Component	Application Component	Direct, high, when the component boundary represents independent application structure.
Interface	Application Interface	Direct, high.
Integration	Flow/Serving/Triggering relationships, Application Service, and endpoint interfaces	Composite, high: Integration is not an independent base element of the language.
Deployment	An Artifact realizing an Application Component and its assignment/deployment to a Node	Composite, high.
Compute resource	Node, Device, and System Software	Composite, high.
Network segment	Communication Network or Path	Direct/partial, high: the choice depends on whether the model represents a network or a communication route.

ArchiMate has a separate Model Exchange File Format for exchanging elements, relationships, and view structure (official format page). It is a potential SAF export target, but requires a formal transformation profile and does not follow automatically from the table above.

Relationships

ArchiMate defines formal relationship categories: structural, dependency, dynamic, and specialization. SAF uses domain verbs that are easier for non-specialists, but often correspond to a semantic composition of several language relationships.

Examples:

• “process realizes service” is close to Realization from Business Process to Business Service;
• “system supports capability” usually decomposes through application services, serving, and realization rather than a single universal arrow;
• “component exposes interface” may use Composition or Assignment, depending on the chosen interpretation and access point;
• “integration transfers information object” requires endpoint elements, a Flow, and the object transferred by that flow;
• “deployment is hosted on resource” is expressed through an Artifact/Application Component, Node, and Assignment/Realization chain.

An ArchiMate view derived from SAF needs a fixed relationship profile. A canonical SAF verb cannot be drawn as an arbitrary ArchiMate arrow.

Views and artifacts

An ArchiMate view selects model elements and relationships for a particular purpose, while a viewpoint defines the rules for that selection and presentation. This directly supports SAF's “one model, different views” principle. The language adds concepts SAF does not yet standardize: explicit stakeholder concerns, view purpose, and an allowed concept set.

An ArchiMate diagram should not become the only store of facts. SAF identifiers should be retained on model elements, and readability-driven omissions should remain view choices that do not change the canonical catalog.

Working method

ArchiMate does not replace a complete architecture-development method. Its primary question is “how should the content be expressed and connected?” The Open Group explicitly positions TOGAF as method and governance, and ArchiMate as a means to visualize and analyze the outcome (complementary roles).

SAF is likewise not a complete project method. Using the two together provides a storage vocabulary and a presentation language, but an organization still needs a process for framing questions, making decisions, and maintaining change.

Governance

ArchiMate validates model structure through its metamodel and permitted relationships, but does not define the whole operating model of an EA function. SAF adds owners, statuses, sources, and fact lifecycles; organizational roles, reviews, and authority must be defined separately.

A practical responsibility boundary is:

• SAF governs the identity and quality of architecture facts;
• the ArchiMate profile governs how those facts are expressed;
• the architecture practice governs decisions and exceptions.

Maturity and tailoring

ArchiMate supports viewpoints and specialization, so an organization can start with a small language subset and expand it. This resembles SAF profiles pragmatically but is not a direct mapping: a SAF profile selects domain-object coverage, while an ArchiMate profile selects permitted elements, relationships, and visualization rules.

At Catalog maturity, formal notation may be optional. At Connected-model maturity, relationship rules provide clear value. At Governed-model maturity, identifiers, validation rules, viewpoints, and controlled specializations become particularly important.

Using ArchiMate with SAF

• Startup: use a limited set of Business Service, Process, Application Component, Flow, and Node elements only for complex decisions.
• Stable business: define a corporate viewpoint and a transformation profile for all 13 SAF types.
• Enterprise: preserve SAF identifiers in the ArchiMate repository and add Motivation and Implementation & Migration for goals and transitions outside the SAF core.

ArchiMate's most natural role beside SAF is a standard visual projection, not a replacement for the catalog or a requirement that every team adopt the whole language.

Mapping limitations

Element meaning depends on abstraction level and the rules of a particular model. A “system,” for example, may be an Application Component, Application Collaboration, or Grouping; the choice cannot be made without the object's boundary and purpose. The official specification is available under license, so this page does not reproduce its metamodels, relationship-permission tables, or notation.

Sources

• ArchiMate Certification — The Open Group.
• ArchiMate 3.2 version and licensing.
• How ArchiMate and TOGAF complement each other.
• ArchiMate 3 Practitioner language areas and competencies.
• ArchiMate Model Exchange File Format.
• General source rules are listed in the research source register.