Conclusions from the IT management comparison

The study found no reason to change SAF's 13 objects or canonical relationships immediately. It showed that architectural and operational models must be connected but not merged. None of the candidates below is an adopted SAF 0.7.0 rule.

Main observations

• Service is the primary persistent bridge between SAF and IT management, but a service offering, technical service, and digital product have different boundaries.
• One real-world subject may simultaneously be a SAF object, a CI, and an asset: three records with different management purposes.
• An event, request, incident, problem, change, release, and pipeline run are transactional records, not new architectural core types.
• A practice, value stream, and governance objective are usually expressed through a composition of Processes, Capabilities, Actors, information, and technology.
• An SLO, error budget, DORA measure, audit, and control evidence are needed for management, but do not require raw measurements to be stored in SAF.
• SAF profiles provide proportionate integration depth, but SAF maturity levels are not equivalent to the maturity or capability levels of external approaches.

Intentional SAF boundaries

The following distinctions should be retained:

• Product remains a management grouping of Services, Systems, and investments, rather than a fourteenth core type.
• Service offering specializes the terms of a Service without duplicating its business meaning.
• Configuration item is a configuration-control role and cannot be reduced to a Component.
• Asset adds cost, contract, risk, and lifecycle concerns but does not replace the architectural record.
• SAF Deployment describes an instance of a Component; a deployment activity and record describe work and evidence.
• Operational record refers to architecture instead of becoming part of the architecture catalog.

These boundaries keep SAF simple while allowing different ITSM/ESM, CMDB, asset, and delivery tools to connect to it.

Identified gaps

The current core does not define a common way to:

• represent variants of one Service offering without creating duplicates;
• distinguish a consumer, customer, user, provider, and owner;
• link a Service to a formal SLA/SLO/SLI and measurement source;
• retain verifiable SAF–CI–asset correspondence across repositories;
• refer from operational records to architecture consistently;
• trace a change, release, or deployment record to a new Deployment state;
• connect an architecture decision to a reliability and observability signal;
• define a minimum integration profile for different SAF profiles and maturity levels.

A gap does not imply that a new base object is required. Most needs can be addressed by an extension, metadata, or an exchange contract.

Non-normative candidates

ID	Candidate	Problem addressed	Preferred form	Risk
SM-C01	Service offering	Variants of terms, Channels, support, and pricing for one Service	External extension or versioned Service projection	Medium: easy to duplicate a Service.
SM-C02	Service roles and service relationship	Distinguishes consumer, customer, user, provider, sponsor, and owner	Role reference data and typed Actor relationships	Medium: the organizational model may expand.
SM-C03	Service-level profile	Links SLA, SLO, SLI, period, and measurement source to a Service	Management artifact referring to service_id	Medium: a target must not be mixed with a measurement series.
SM-C04	SAF–CI–asset mapping	Preserves identity and verifiability across repositories	Separate mapping record with validity period and confidence	Low/medium: does not change the 13 types.
SM-C05	Operational-record references	Consistently links an event, request, incident, or problem to a Service and CI	External-reference profile	Low: requires identifier discipline.
SM-C06	Change/release/deployment lineage	Shows which work created a new Deployment state	Chain of external records to deployment_id and version	Medium: sources may disagree.
SM-C07	Reliability and observability references	Connects an SLO, telemetry, incident, and architecture decision	Links to measure definitions and aggregated states	Medium: risk of moving telemetry into SAF.
SM-C08	IT management integration profile	Defines minimum relationships by company profile and maturity	Versioned extension profile with validation rules	High: requires independent exchange-schema design.

Preliminary priority

SM-C04, SM-C05, and SM-C06 should be tested first using the end-to-end CRM example. They improve traceability without expanding the domain core. SM-C03 and SM-C07 can then be explored as links to management artifacts. SM-C01, SM-C02, and especially SM-C08 require a separate decision on extension boundaries.

The architecture-study candidates C-01–C-08 and IT-management candidates SM-C01–SM-C08 remain independent. Their overlap—provenance, confidence, states, and governed views—should only be considered jointly after scenario validation.

Candidate acceptance conditions

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

1. there is a user question that cannot be addressed conveniently with an existing object, relationship, attribute, or external reference;
2. identity boundaries and the authoritative source are defined;
3. Startup, Stable Business, and Enterprise profiles are tested at no fewer than two maturity levels;
4. migration without changing identifiers of existing objects is demonstrated;
5. validation rules and behavior for a deleted, conflicting, or stale record are defined;
6. a Russian normative statement, tests, and a complete translation are prepared;
7. the change is not presented as conformity with an external standard.

Result

SAF provides shared architectural context. ITSM and ITIL organize the service perspective; RITM provides an integrated IT management model; ISO/IEC 20000 and FitSM provide management systems with different degrees of formality; COBIT addresses governance; IT4IT supplies a digital-product management reference architecture; SRE focuses on reliability; and DevOps addresses change flow and feedback. The practical next step is not to enlarge the core, but to test a governed bridge for identity and operational references.

The evidence and limitations are recorded in the source register.