Перейти к основному содержимому
Версия: 0.7.0

SAF и DoDAF

Сопоставление выполнено с DoD Architecture Framework 2.02 и DoDAF Meta-Model (DM2). На официальном сайте DoD CIO редакция 2.02 названа текущей; соответствие DoDAF связывается с определением архитектурных данных через понятия, ассоциации и атрибуты DM2 и возможностью их передачи по Physical Exchange Specification (DoDAF 2.02). SAF не заявляет такого соответствия.

Назначение и аудитория

SAF предназначен для общего описания компании на разных уровнях зрелости. DoDAF создан для архитектурных описаний, поддерживающих решения и ключевые процессы Министерства обороны США. Официальное описание DM2 перечисляет среди них развитие способностей, планирование и бюджетирование, закупки, системную инженерию, операционное планирование и управление портфелем способностей (DM2).

DoDAF адресует архитекторов, владельцев процессов принятия решений, системных инженеров, руководителей программ и широкий круг заинтересованных сторон миссии. Его масштаб, точность семантики и контекст обязательности существенно выше минимального стартап-профиля SAF.

Области архитектуры

DoDAF организует содержание через восемь viewpoints: All, Capability, Data and Information, Operational, Project, Services, Standards и Systems. Systems Viewpoint сохранён для legacy-описаний, а выбор данных и представлений должен исходить из потребностей принимающего решение. Официальная страница подчёркивает принцип Fit-for-Purpose и приоритет согласованной модели данных над обязательным созданием всех картинок (Viewpoints and Models).

Слои SAF пересекают несколько viewpoints:

  • бизнес-объекты — Capability, Operational, Services и Data and Information;
  • приложения и взаимодействия — Services и Systems;
  • инфраструктура и размещение — Systems, Standards и данные о Location;
  • изменение во времени и инициативах — Project и Capability, которых нет в ядре SAF.

Понятия и соответствия SAF

Объект SAFБлижайшее содержание DoDAF/DM2Оценка
УчастникPerformer, Person Type, Organization Type и RoleСоставное, высокая: SAF намеренно объединяет несколько типов исполнителей и владельцев.
КаналInterface, Service access, Resource Flow и средство взаимодействияСоставное, средняя: единого универсального аналога канала нет.
УслугаService и результат поддерживаемой деятельностиЧастичное, высокая: DoDAF Service чаще описывает способ предоставления доступа к capability, а SAF — результат для участника.
ПроцессActivity и последовательности Operational ActivitiesЧастичное, высокая.
СпособностьCapabilityПрямое, высокая.
Информационный объектInformation, Data, Resource и их представления в Data and Information ViewpointСоставное, высокая.
СистемаSystem как Performer/Resource и его составЧастичное, высокая: границы определяются задачей архитектурного описания.
КомпонентSystem part, Performer или Resource с декомпозициейЧастичное, средняя.
ИнтерфейсInterface и точки Resource FlowЧастичное, средняя.
ИнтеграцияResource Flow, Exchange, взаимодействующие Performers/Services и правила обменаСоставное, высокая: SAF материализует взаимодействие отдельным объектом.
РазвёртываниеPerformer/Resource в Location и конфигурация решения во времениСоставное, средняя.
Вычислительный ресурсSystem, Materiel, Facility или иной ResourceСоставное, средняя.
Сетевой сегментCommunication path/network, Resource Flow и LocationСоставное, средняя.

DM2 имеет концептуальный, логический и физический обменный уровни. Концептуальная модель рассчитана на руководителей, логическая уточняет атрибуты и отношения, а PES добавляет реализационные атрибуты для обмена (описание уровней DM2). Это делает однозначное машинное сопоставление отдельным проектом, а не следствием таблицы терминов.

Отношения

SAF задаёт отношения в форме простых утверждений предметной области. DM2 стремится к более строгой семантике архитектурных данных и их федерации. Ближайшие группы:

  • «процесс требует способность» — связь Capability с Activities и Performers;
  • «система поддерживает способность» — трассировка Capability к Activities, Services и Systems;
  • «интеграция передаёт объект» — Resource Flow/Exchange между Performers с передаваемым Resource или Information;
  • «развёртывание размещено на ресурсе» — конфигурация Performer/Resource и Location;
  • «участник владеет объектом» — authority, responsibility и организационные отношения, зависящие от выбранного набора данных.

Связь SAF нельзя объявлять DM2-ассоциацией без проверки её домена, диапазона и обязательных атрибутов. И наоборот, многие DM2-отношения намеренно отсутствуют в компактном ядре SAF.

Представления и артефакты

DoDAF различает архитектурные данные, viewpoints, DoDAF-described Models и специальные Fit-for-Purpose Views. Официальное руководство прямо говорит, что создавать все модели не требуется и что представление выбирается под вопрос принимающего решение (Viewpoints and Models).

Это хорошо согласуется с принципом SAF «одна модель — много представлений». Разница в том, что SAF пока не определяет формальный каталог concerns/viewpoints и минимальные наборы данных для конкретных решений. DoDAF может служить образцом того, как отделить семантическое хранилище от табличной, графической или текстовой подачи.

Метод работы

DoDAF предлагает архитектурный процесс, начинающийся с назначения, области, заинтересованных сторон и требуемых данных, но допускает адаптацию другого метода. Основной критерий — полезность для решения и согласованность данных, а не механическое заполнение полного комплекта продуктов.

SAF может использовать этот принцип без копирования оборонного процесса: сначала формулируется решение, затем выбирается минимальный срез объектов и связей, после чего строится представление. Для критических межорганизационных моделей требуется отдельное соглашение об обмене, которое SAF сейчас не стандартизует.

Управление

DoDAF тесно связан с владельцами ключевых процессов, требованиями обмена, конфигурационным управлением DM2 и повторным использованием архитектурных данных. SAF ограничивается качеством модели и ответственностью за её объекты. Поэтому DoDAF показывает два возможных направления развития SAF: явная привязка каждого представления к решению и формализация семантики обмена.

Переносить режим DoD-conformance в обычную компанию не следует. Для SAF важен принцип проверяемого контракта данных, а не ведомственные процедуры или обязательный набор отчётности.

Зрелость и адаптация

Fit-for-Purpose не является аналогом профилей «Стартап / Устойчивый бизнес / Предприятие» и уровней зрелости SAF. DoDAF адаптирует содержание к назначению архитектурного описания; SAF меняет охват типов и качество управления моделью.

Вместе эти оси дают полезную проверку: даже предприятие не должно создавать представление без вопроса, а даже стартапу может понадобиться строгий небольшой срез данных для критического решения.

Совместное применение с SAF

  • Стартап: использовать только принцип «данные для решения»; формальные DoDAF-viewpoints обычно избыточны.
  • Устойчивый бизнес: применять выборочные capability, operational, services и data views для сложных интеграций и программ изменений.
  • Предприятие или регулируемая среда: определить профиль экспорта SAF в требуемое подмножество DM2, правила качества, provenance и стабильные идентификаторы.

SAF может быть удобным входным каталогом для участников, не работающих непосредственно с DoDAF, но преобразование в conformant-данные требует отдельного проверяемого маппинга.

Ограничения сопоставления

DoDAF использует оборонную предметную область и значительно более богатую онтологию. Русские слова «услуга», «система» или «способность» не гарантируют полного совпадения с DM2. Здесь не проверяются обязательные данные конкретного DoD-процесса, PES-схемы или требования закрытых сред. Ни одна таблица этого раздела не подтверждает DoDAF-conformance.

Источники