Выводы сопоставления с управлением ИТ

Исследование не обнаружило основания немедленно менять 13 объектов или канонические отношения SAF. Оно показало, что архитектурная и операционная модели должны быть связаны, но не слиты. Ни один кандидат ниже не является принятой нормой SAF 0.7.0.

Основные наблюдения

• Услуга является главным устойчивым мостом между SAF и управлением ИТ, но service offering, техническая услуга и digital product имеют другие границы.
• Один реальный предмет может одновременно быть объектом SAF, CI и активом; это три записи с разными целями управления.
• Event, request, incident, problem, change, release и pipeline run — транзакционные записи, а не новые типы архитектурного ядра.
• Практика, value stream и governance objective обычно выражаются составом процессов, способностей, участников, информации и технологий.
• SLO, error budget, показатели DORA, аудит и control evidence нужны для управления, но не требуют хранить сырые измерения в SAF.
• Профили SAF хорошо задают соразмерную глубину интеграции, но уровни зрелости SAF не эквивалентны maturity/capability внешних подходов.

Намеренные границы SAF

Следующие различия следует сохранять:

• Product остаётся управленческой группировкой услуг, систем и инвестиций, а не четырнадцатым типом ядра.
• Service offering специализирует условия услуги и не дублирует её бизнес-смысл.
• Configuration item является ролью конфигурационного контроля и не сводится к компоненту.
• Asset добавляет стоимость, договор, риск и жизненный цикл, но не заменяет архитектурную запись.
• Развёртывание SAF описывает экземпляр компонента; deployment activity и record описывают работу и свидетельство.
• Операционная запись ссылается на архитектуру, а не становится частью архитектурного каталога.

Эти границы удерживают SAF простым и позволяют подключать разные ITSM/ESM, CMDB, asset и delivery-инструменты.

Обнаруженные пробелы

Текущее ядро не задаёт общий способ:

• представить варианты предложения одной услуги без создания дубликатов;
• различить потребителя, заказчика, пользователя, поставщика и владельца;
• связать услугу с формальным SLA/SLO/SLI и источником измерения;
• хранить проверяемое соответствие SAF–CI–asset между репозиториями;
• ссылаться из operational records на архитектуру единообразно;
• проследить change/release/deployment record до нового состояния развёртывания;
• связать архитектурное решение с сигналом надёжности и observability;
• определить минимальный интеграционный профиль для разных профилей и зрелости SAF.

Пробел не означает, что требуется новый базовый объект. Большинство задач можно решить расширением, метаданными или контрактом обмена.

Ненормативные кандидаты

ID	Кандидат	Что решает	Предпочтительная форма	Риск
SM-C01	Service offering	Варианты условий, каналов, поддержки и тарификации одной услуги	Внешнее расширение или версионируемая проекция услуги	Средний: легко дублировать услугу.
SM-C02	Сервисные роли и service relationship	Различает consumer, customer, user, provider, sponsor и owner	Ролевой справочник и типизированные отношения участника	Средний: возможен рост организационной модели.
SM-C03	Service level profile	Связывает SLA, SLO, SLI, период и источник измерения с услугой	Управленческий артефакт, ссылающийся на service_id	Средний: нельзя смешивать цель и ряд измерений.
SM-C04	Mapping SAF–CI–asset	Сохраняет идентичность и проверяемость между репозиториями	Отдельная запись mapping с периодом и confidence	Низкий/средний: не меняет 13 типов.
SM-C05	Ссылки operational records	Единообразно связывает event/request/incident/problem с услугой и CI	Профиль внешних ссылок	Низкий: требует дисциплины идентификаторов.
SM-C06	Change/release/deployment lineage	Показывает, какая работа создала новое состояние развёртывания	Цепочка внешних записей до deployment_id и версии	Средний: источники могут расходиться.
SM-C07	Reliability и observability references	Соединяет SLO, telemetry, инцидент и архитектурное решение	Ссылки на определения показателей и агрегированные состояния	Средний: риск переноса телеметрии в SAF.
SM-C08	Профиль интеграции управления ИТ	Задаёт минимальные связи по профилю и зрелости компании	Версионируемый extension profile с правилами validation	Высокий: требует независимого проектирования схемы обмена.

Предварительный приоритет

Первым следует проверить SM-C04, SM-C05 и SM-C06 на сквозном CRM-примере. Они улучшают трассировку, не расширяя предметное ядро. Затем можно исследовать SM-C03 и SM-C07 как ссылки на управленческие артефакты. SM-C01, SM-C02 и особенно SM-C08 требуют отдельного решения о границах расширения.

Кандидаты архитектурного исследования C-01–C-08 и кандидаты управления ИТ SM-C01–SM-C08 остаются независимыми. Их пересечение — provenance, confidence, состояния и управляемые представления — следует рассматривать совместно только после проверки сценариев.

Условия принятия кандидата

Кандидат может стать частью SAF только после отдельного решения, если:

1. есть пользовательский вопрос, который нельзя удобно решить текущим объектом, отношением, атрибутом или внешней ссылкой;
2. определены границы идентичности и авторитетный источник;
3. проверены стартап, устойчивый бизнес и предприятие как минимум на двух уровнях зрелости;
4. показана миграция без изменения идентификаторов существующих объектов;
5. определены validation rules и поведение при удалённой, конфликтующей или устаревшей записи;
6. подготовлены русская нормативная формулировка, тесты и полный перевод;
7. изменение не объявляется соответствием внешнему стандарту.

Итог

SAF даёт общий архитектурный контекст. ITSM и ITIL организуют сервисную перспективу, РИТМ — целостную модель управления ИТ, ISO/IEC 20000 и FitSM — системы менеджмента разной формальности, COBIT — governance, IT4IT — референсную архитектуру управления digital product, SRE — надёжность, DevOps — поток изменений и обратную связь. Практический следующий шаг — не увеличивать ядро, а испытать управляемый мост идентичности и операционных ссылок.

Основания и ограничения приведены в реестре источников.