SAF и TOGAF
Сопоставление выполнено с TOGAF® Standard, 10th Edition с Technical Corrigendum 1, указанным в официальном каталоге The Open Group. SAF не объявляется реализацией TOGAF и не наследует его требования.
Назначение и аудитория
SAF даёт небольшой общий словарь и путь постепенного усложнения модели компании. TOGAF предназначен прежде всего для организации архитектурной практики: он помогает определить, как разрабатывать архитектуру, принимать решения, управлять результатами и адаптировать работу к контексту предприятия. The Open Group описывает 10-ю редакцию как сочетание фундаментального содержания и Series Guides, позволяющих конфигурировать практику под разные случаи (обзор TOGAF).
Поэтому основная аудитория SAF шире на ранних стадиях: технические лидеры, владельцы продуктов и аналитики могут начать с каталога без выделенной EA-функции. TOGAF в большей степени адресован архитекторам, руководителям EA и органам архитектурного управления, хотя допускает применение организациями разного размера.
Области архитектуры
Оба подхода покрывают бизнес, приложения, данные/информацию и технологии, но проводят границы по-разному:
- бизнес-слой SAF содержит участника, канал, услугу, процесс, способность и информационный объект;
- TOGAF организует архитектурную работу вокруг Business, Data, Application и Technology Architecture, а также связывает их с видением, требованиями и реализацией;
- инфраструктурный слой SAF является частью самой предметной модели, тогда как TOGAF помещает подобное содержание в Technology Architecture и настраиваемую контентную модель;
- SAF намеренно не включает цель, требование, принцип, проект и дорожную карту в ядро; TOGAF использует такие результаты в архитектурном цикле.
Официальное объяснение совместного применения TOGAF и ArchiMate также перечисляет бизнес-, информационную/данную, прикладную и технологическую области и связывает их с фазами ADM (The Open Group).
Понятия и соответствия SAF
| Объект SAF | Ближайшее содержание TOGAF | Оценка |
|---|---|---|
| Участник | Actor, Role, Organization Unit, Stakeholder | Составное, высокая: SAF объединяет несколько организационных ракурсов. |
| Канал | Канал взаимодействия выражается через способ предоставления сервиса, интерфейс, location или локальное расширение | Составное, средняя. |
| Услуга | Business Service | Прямое, высокая, если граница результата согласована. |
| Процесс | Process и при необходимости Function | Прямое/частичное, высокая: SAF отделяет процесс от способности, но не вводит business function. |
| Способность | Business Capability | Прямое, высокая. |
| Информационный объект | Data Entity и бизнес-информационное содержание | Составное, высокая: специализации SAF требуют правила выбора логического и физического уровня. |
| Система | Набор Logical/Physical Application Components и предоставляемых сервисов | Составное, средняя: единая граница SAF не обязана совпадать с building block. |
| Компонент | Logical или Physical Application Component | Частичное, высокая. |
| Интерфейс | Information System Service, контракт и точка доступа к Application Component | Составное, средняя. |
| Интеграция | Связи взаимодействия, интерфейсные матрицы и потоки данных | Составное, высокая: отдельный устойчивый объект SAF обычно становится архитектурным артефактом или расширением. |
| Развёртывание | Связь Physical Application Component с Physical Technology Component и окружением | Составное, средняя. |
| Вычислительный ресурс | Physical Technology Component и Technology Service | Частичное, высокая. |
| Сетевой сегмент | Logical/Physical Technology Component, Location и коммуникационная топология | Составное, средняя. |
Совпадение терминов не делает идентификаторы взаимозаменяемыми. При обмене данными нужен явный профиль соответствия, учитывающий настроенную enterprise metamodel конкретной TOGAF-практики.
Отношения
SAF задаёт небольшой нормативный набор предметных отношений: услуга реализуется процессом, система поддерживает способность, компонент предоставляет интерфейс, интеграция передаёт информационный объект, развёртывание размещается на ресурсе и так далее.
TOGAF в большей степени задаёт трассируемость архитектурного содержания через метамодель, каталоги, матрицы и диаграммы. Близкие связи обычно находятся, но одна связь SAF может раскладываться на несколько связей между building blocks, сервисами и элементами требований. Особенно это заметно для интеграции и развёртывания, которые SAF делает самостоятельными управляемыми объектами.
Практическое правило совместного использования: SAF остаётся мастер-моделью операционного каталога, а TOGAF-репозиторий хранит ссылку на тот же стабильный идентификатор и добавляет контекст архитектурной работы. Автоматически выводить эквивалентность только по названию нельзя.
Представления и артефакты
SAF не предписывает нотацию: страница, таблица или схема являются проекцией одной канонической модели. TOGAF предлагает значительно более богатую систему результатов — deliverables, artifacts и building blocks; артефакты могут быть каталогами, матрицами и диаграммами. Это полезно для выбора представления под stakeholder concern, но не означает, что каждый TOGAF-артефакт нужно добавить в SAF.
Для совместной практики достаточно:
- использовать SAF-каталог как исходные факты о текущем состоянии;
- формировать из него TOGAF-артефакты для конкретной архитектурной задачи;
- возвращать принятые изменения в SAF с сохранением идентификаторов;
- не переносить в ядро SAF временные deliverables только потому, что они нужны одной итерации ADM.
Метод работы
Главное дополнение TOGAF к SAF — Architecture Development Method (ADM): повторяемый цикл от подготовки и видения через доменные архитектуры, варианты реализации, план миграции, управление внедрением и изменениями. SAF описывает эволюционные переходы профиля и зрелости, но не определяет полный проектный цикл разработки архитектуры.
Вместе они могут использоваться так: ADM формулирует вопрос, заинтересованные стороны, базовую и целевую архитектуру; SAF предоставляет минимальный словарь фактов; специализированные артефакты показывают разрывы и варианты; после решения SAF-каталог обновляется как долговечная модель.
Управление
SAF на управляемом уровне требует владельцев, статусы, источники, период действия и проверку связей. TOGAF рассматривает архитектурную способность шире: роли и органы управления, принципы, repository, соответствие решений, управление требованиями и изменениями. Именно здесь TOGAF закрывает наиболее заметный организационный пробел SAF.
При этом TOGAF-механизмы не следует включать в минимальное ядро стартап-профиля. Их можно вводить как рабочую практику по мере появления нескольких команд, значимых инвестиций и необходимости согласовывать изменения между областями.
Зрелость и адаптация
Уровни SAF «Каталог → Связанная модель → Управляемая модель» измеряют качество конкретной модели, а не зрелость всей EA-функции. TOGAF допускает tailoring метода и контента; Series Guides включают рекомендации для разных способов работы, а каталог руководств содержит материалы по архитектурной способности и maturity models (TOGAF Series Guides).
Следовательно, прямое соответствие уровней некорректно. Организация может дисциплинированно применять ADM, но иметь неполный SAF-каталог, либо поддерживать качественную связанную модель без формализованной TOGAF-практики.
Совместное применение с SAF
- Стартап: применять отдельные вопросы ADM — цель, заинтересованные стороны, ограничения и решение — без полного набора артефактов.
- Устойчивый бизнес: связать SAF-каталог с архитектурными инициативами, базовой/целевой архитектурой, принципами и review решений.
- Предприятие: использовать TOGAF для операционной модели EA, управления и портфеля переходов, а SAF — как упрощённое общее ядро объектов и связей для широкого круга участников.
Особенно полезно сочетание на переходе к управляемому уровню, где одних типов объектов недостаточно и требуется устойчивый процесс принятия решений.
Ограничения сопоставления
TOGAF является настраиваемым каркасом, поэтому две организации могут использовать разные расширения контентной метамодели и разные наборы артефактов. Приведённые соответствия описывают устойчивое смысловое ядро, а не универсальную схему импорта. Полный текст стандарта распространяется на лицензионных условиях; здесь используются краткие пересказы официально доступных сведений, без копирования таблиц или диаграмм.