Conclusions and candidates for SAF

The comparison found no reason to change SAF's 13 objects or canonical relationships immediately. The core fulfills its original purpose: it provides a small vocabulary that a company can understand before establishing a mature EA practice. None of the items below is an accepted SAF 0.7.0 rule.

Observations

Intentional simplifications

• SAF combines actor, role, organization, and stakeholder in one actor, leaving detail to attributes and views.
• SAF materializes integration and deployment as managed objects, although formal languages often express them as compositions of elements and relationships.
• SAF uses one information object before the enterprise profile and only then distinguishes business object, data object, and message.
• SAF requires no specialized notation, complete architecture method, or fixed view set.
• Profiles reduce domain coverage, while maturity levels assess model quality; this is simpler than an overall EA-function maturity assessment.

These choices lower the barrier to entry. They should not be treated as gaps merely because external approaches have more types.

Actual gaps

The comparison identified tasks that the current core alone cannot address sustainably:

• it does not record for which decision, stakeholder, and concern a view was created;
• goals, outcomes, requirements, and constraints remain outside canonical traceability;
• there is no common way to connect the current model with a target state, gaps, and a transition sequence;
• principles, policies, and standards are not connected to objects, decisions, and exceptions;
• fact quality is described, but mapping confidence, decision provenance, and change rationale are insufficiently formalized;
• there is no standard exchange profile for an external metamodel or notation.

A gap indicates a need, not automatically a new core object. Some tasks may be addressed through metadata, a view type, or a separate extension.

Non-normative candidates

ID	Candidate	Problem addressed	Basis in the comparison	Where useful	Cost and risk
C-01	Concern, stakeholder, and viewpoint as view metadata	The purpose and audience of a diagram are unclear	TOGAF stakeholder concerns, DoDAF Fit-for-Purpose, ArchiMate viewpoints	From Connected maturity, especially enterprise	Low/medium; can be added without changing the 13 types.
C-02	Goal → outcome → requirement/constraint extension	No traceability from business intent to capability and system	TOGAF requirements/vision, ArchiMate Motivation, Gartner outcome-driven EA	Stable business and enterprise	High; risk of expanding the business layer and mixing strategy with architecture.
C-03	Principle, policy, standard, and exception as a governance module	Cannot show which rule guides a decision or where deviation is allowed	TOGAF governance, DoDAF Standards Viewpoint, Gartner adaptive governance	Governed maturity	Medium/high; requires lifecycle and authority.
C-04	Explicit current/target states, plateau, and gap	Cannot compare states of one model over time	TOGAF baseline/target/gap, ArchiMate Plateau/Gap	Connected and governed models	Medium; objects must not be duplicated and identifiers must be preserved.
C-05	Initiative/work package and roadmap as a transition module	No connection from a gap to funded delivery and dependencies	TOGAF migration planning, DoDAF Project Viewpoint, ArchiMate Work Package/Deliverable	Stable business and enterprise	High; SAF can easily turn into a portfolio-management system.
C-06	Measure, risk, and architecture-decision criterion	A “governed” model does not prove that an outcome was achieved	TOGAF governance, DoDAF decision support, Gartner outcomes/value	Governed maturity	Medium; units, period, and source are required.
C-07	Stronger provenance, confidence, and decision record	Imported-fact reliability and change rationale are difficult to assess	DM2 semantic precision/exchange and governance practices across all approaches	Any profile when catalogs are integrated	Low/medium; likely metadata rather than new objects.
C-08	Versioned export and view profiles	A mapping table does not provide verifiable exchange	TOGAF enterprise-metamodel tailoring, DM2/PES, ArchiMate Exchange Format	Enterprise, sometimes stable business	High; requires schemas, validation rules, and reversibility tests.

Preliminary priority

The lowest-risk next step is to explore C-01 and C-07 as metadata without adding domain types. They improve explainability and quality of the existing model.

C-04 should be tested with the end-to-end CRM example: preserve object identifiers, show current and target states, and then describe the gap without duplicating the catalog. C-02, C-03, C-05, and C-06 need separate boundary design because they could turn a simple framework into a heavy strategy and portfolio management system.

Candidate acceptance criteria

A candidate may become part of SAF only through a separate decision and when:

1. a user question is identified that cannot be addressed conveniently with current objects, relationships, or attributes;
2. usage is tested in at least two profiles and at all three maturity levels;
3. boundaries, identity, permitted relationships, and migration between model states are defined;
4. the proposal explains why metadata or a view is insufficient;
5. a Russian normative definition, documentation tests, and a complete translation are prepared;
6. the change is not described as compatibility with an external standard without a separate conformance program.

Result

TOGAF best complements SAF with method and governance, DoDAF with data and decision-view discipline, ArchiMate with a formal visualization language, and Gartner with an EA operating model and value orientation. SAF remains the shared minimum foundation. The next step is not to expand the core automatically, but to test candidates in concrete scenarios.

The evidence and limitations behind these conclusions are listed in the research source register.