Выводы и кандидаты для SAF
Сопоставление не обнаружило причины немедленно менять 13 объектов или канонические отношения SAF. Ядро выполняет свою исходную задачу: даёт небольшой словарь, понятный компании до появления зрелой EA-практики. Ни один пункт ниже не является принятой нормой 0.7.0.
Наблюдения
Намеренные упрощения
- SAF объединяет actor, role, organization и stakeholder в одном участнике, оставляя детализацию атрибутам и представлениям.
- SAF материализует интеграцию и развёртывание как управляемые объекты, хотя формальные языки часто выражают их композициями элементов и отношений.
- SAF использует один информационный объект до профиля «Предприятие» и только затем различает бизнес-объект, объект данных и сообщение.
- SAF не требует специальной нотации, полного архитектурного метода или фиксированного комплекта представлений.
- Профили сокращают предметный охват, а уровни зрелости оценивают качество модели — это проще, чем общая оценка зрелости EA-функции.
Эти решения уменьшают порог входа. Их не следует считать пробелами только потому, что внешние подходы имеют больше типов.
Реальные пробелы
Сравнение выявило задачи, которые невозможно устойчиво решить только текущим ядром:
- не зафиксировано, для какого решения, заинтересованной стороны и concern создано представление;
- цели, результаты, требования и ограничения существуют только вне канонической трассировки;
- нет общего способа связать текущую модель с целевым состоянием, разрывами и последовательностью переходов;
- принципы, политики и стандарты не связаны с объектами, решениями и исключениями;
- качество факта описано, но уверенность сопоставления, provenance решения и обоснование изменения недостаточно формализованы;
- нет стандартного профиля обмена с внешней метамоделью или нотацией.
Пробел означает потребность, а не автоматически новый базовый объект. Часть задач может быть закрыта метаданными, типом представления или отдельным расширением.
Ненормативные кандидаты
| ID | Кандидат | Какую проблему решает | Основание в сравнении | Где полезен | Стоимость и риск |
|---|---|---|---|---|---|
| C-01 | Concern, stakeholder и viewpoint как метаданные представления | Непонятно, зачем и для кого построена схема | TOGAF stakeholder concerns, DoDAF Fit-for-Purpose, ArchiMate viewpoints | Со связанного уровня, особенно предприятие | Низкая/средняя; можно добавить без изменения 13 типов. |
| C-02 | Расширение «цель → outcome → требование/ограничение» | Нет трассировки от бизнес-намерения к способности и системе | TOGAF requirements/vision, ArchiMate Motivation, Gartner outcome-driven EA | Устойчивый бизнес и предприятие | Высокая; риск раздувания бизнес-слоя и смешения стратегии с архитектурой. |
| C-03 | Принцип, политика, стандарт и исключение как управленческий модуль | Нельзя показать, какое правило направляет решение и где разрешено отклонение | TOGAF governance, DoDAF Standards Viewpoint, Gartner adaptive governance | Управляемый уровень | Средняя/высокая; требует жизненного цикла и полномочий. |
| C-04 | Явные состояния current/target, plateau и gap | Нельзя сравнить состояния одной модели во времени | TOGAF baseline/target/gap, ArchiMate Plateau/Gap | Связанная и управляемая модели | Средняя; важно не дублировать объекты и сохранить идентификаторы. |
| C-05 | Инициатива/work package и дорожная карта как модуль переходов | Нет связи разрыва с финансируемой поставкой и зависимостями | TOGAF migration planning, DoDAF Project Viewpoint, ArchiMate Work Package/Deliverable | Устойчивый бизнес и предприятие | Высокая; легко превратить SAF в систему управления портфелем. |
| C-06 | Показатель, риск и критерий архитектурного решения | «Управляемая» модель не доказывает достижение результата | TOGAF governance, DoDAF decision support, Gartner outcomes/value | Управляемый уровень | Средняя; нужны единицы измерения, период и источник. |
| C-07 | Усиленные provenance, confidence и decision record | Сложно оценить надёжность импортированного факта и причину изменения | DM2 semantic precision/exchange, управленческие практики всех подходов | Любой профиль при интеграции каталогов | Низкая/средняя; вероятно, метаданные, а не новые объекты. |
| C-08 | Версионируемые профили экспорта и представлений | Таблица соответствий не обеспечивает проверяемый обмен | TOGAF enterprise metamodel tailoring, DM2/PES, ArchiMate Exchange Format | Предприятие, иногда устойчивый бизнес | Высокая; требует схем, validation rules и тестов обратимости. |
Предварительный приоритет
Наименее рискованный следующий шаг — исследовать C-01 и C-07 как метаданные, не добавляя новые предметные типы. Они улучшают объяснимость и качество уже существующей модели.
C-04 логично проверить на сквозном примере CRM: сохранить идентификаторы объектов, показать current и target, затем описать gap без создания копий каталога. C-02, C-03, C-05 и C-06 требуют отдельного проектирования границ, потому что могут превратить простой каркас в тяжёлую систему управления стратегией и портфелем.
Условия принятия кандидата
Кандидат может стать частью SAF только после отдельного решения, если:
- сформулирован пользовательский вопрос, который нельзя удобно решить текущими объектами, связями или атрибутами;
- проверено применение как минимум в двух профилях и на трёх уровнях зрелости;
- определены границы, идентичность, допустимые связи и миграция между состояниями модели;
- показано, почему метаданных или представления недостаточно;
- подготовлены русская нормативная формулировка, тесты документации и полный перевод;
- изменение не объявляется совместимостью с внешним стандартом без отдельной программы соответствия.
Итог
TOGAF лучше всего дополняет SAF методом и управлением, DoDAF — дисциплиной данных и представлений для решений, ArchiMate — формальным языком визуализации, Gartner — операционной моделью EA и ориентацией на ценность. SAF остаётся общим минимальным основанием. Следующий шаг — не расширять ядро автоматически, а проверить кандидатов на конкретных сценариях.
Источники и ограничения, на которых основаны выводы, приведены в реестре исследования.