SAF and IT management

This section compares SAF's durable architecture model with practices, standards, and engineering approaches that govern actual IT delivery. The research is non-normative: it adds no types to the SAF core and does not turn the architecture repository into an ITSM system, CMDB, or asset register.

The public-source baseline is fixed as of August 3, 2026. For evolving material without a stable version number, this date is used as the snapshot.

Why the comparison is needed

SAF answers “what exists,” “how is it connected,” and “which business outcome does it support?” IT management adds other questions:

• which service is actually delivered and under what conditions;
• who is the consumer, provider, owner, and operator;
• which configuration items and assets enable the service;
• what happened in operations and which change is required;
• how quality, reliability, speed, and value are measured;
• which records are the source of operational truth.

Without an explicit boundary, the same words begin to mean different things. A SAF component is a logical part of a system, a CI is a unit of configuration control, and an asset is a subject of financial or lifecycle management. One physical server may have three records, but those records do not need to share an identifier or lifecycle.

Nature of the approaches

Approach	Nature	What it adds to SAF
ITSM	Practice domain	A shared service perspective and vocabulary of management objects.
RITM	Evolving IT management model	Links architecture with assets, reliability, operational processes, products, and services in a Russian context.
ITIL Version 5	Guidance for managing digital products and services	Value creation, lifecycle, practices, and continual improvement.
ISO/IEC 20000-1	Service management system requirements	A verifiable management system and organizational accountability.
FitSM	Lightweight family of standards	A minimum practical ITSM scope and role model.
COBIT	Governance and management of enterprise I&T	Objectives, governance-system components, control, and performance evaluation.
IT4IT	Reference architecture for digital-product management	End-to-end value streams, functional components, and management data.
SRE	Engineering practice and body of knowledge	SLIs/SLOs, error budgets, engineering-based reliability management, and toil.
DevOps	Movement and set of cultural and technical practices	Shared responsibility, fast change flow, automation, and feedback.

These approaches cannot be compared as nine competing metamodels. ITSM and DevOps have no single normative owner, ISO/IEC 20000 specifies requirements, IT4IT describes a target management architecture, and SRE focuses on operational reliability.

The mapping tables on the approach pages run in the opposite direction from the full crosswalk: each row starts from an approach concept and points to the nearest SAF object, not the reverse. This changes how the "Composite" code reads here — it means one approach concept maps to several SAF objects.

Analytical questions

The same questions are used for each approach:

1. What is its nature and stated scope?
2. What is its primary unit of management?
3. Which concepts are closest to the 13 SAF objects?
4. Which relationships exist among service, product, system, configuration, and work?
5. How are lifecycle, roles, governance, and measurement organized?
6. Which information should remain outside SAF?
7. What can be connected without losing identity or meaning?

Repository rule

Rather than designating one catalog as “authoritative for everything,” assign a source of truth by information class:

Repository	Authoritative information	Relationship with SAF
SAF / architecture repository	Business meaning, logical structure, target relationships, and stable identifiers	Source of the architecture projection.
Service catalog	Offering, consumers, terms, channels, owner, and service level	References or specializes a SAF service.
CMDB / CMS	Managed actual configuration and CI dependencies	Maps a CI to a SAF system, component, deployment, or resource.
Asset register	Cost, contract, license, ownership, and asset lifecycle	Connects an asset to the same subject without replacing architecture identity.
ITSM/ESM system	Requests, events, incidents, problems, changes, and knowledge	Operational records reference services and affected objects.
Observability and delivery tooling	Metrics, traces, builds, releases, and actual deployments	Confirms state but does not define business meaning.

Reading path

After the approach pages, read the entity boundaries and canonical bridges, then the complete crosswalk and the profile and maturity matrix. The conclusions separate observations from non-normative candidates. Versions and access limitations are listed in the source register.