Архитектурная рамка Министерства обороны США для оборонных и сложных систем. Задаёт восемь точек зрения — All, Capability, Data and Information, Operational, Project, Services, Standards, Systems — и 52 модели внутри них; отдельным слоем стоит метамодель DM2, в реестр не переносившаяся.
Комплект архитектурных схем готов, а руководитель не видит, зачем он: какую способность обеспечивает сеть центров, какие операции без неё не состоятся, какие системы и проекты для этого нужны. DoDAF требует ответить на «зачем» до того, как нарисована первая модель.
В большой организации архитектуру делают разные команды: одни описывают операции, другие — системы, третьи — программы закупок. Без общих данных их представления не стыкуются: «центр» на операционной схеме и «центр» на схеме систем оказываются разными сущностями, а матрицу прослеживаемости между ними рисуют вручную и забывают обновить. DoDAF отвечает на это двумя правилами. Первое: архитектура — это данные, а представления — их проекции; один элемент переиспользуется во всех моделях. Второе: набор моделей выбирают под решение, которое архитектура должна поддержать, а не по каталогу.
В раздатке — шесть точек зрения из восьми в разборе: общий контекст, способности, операции, данные, проекты, системы; сервисы и стандарты добавляются, когда решение их касается. Дальше 48 моделей из 52, что есть на странице реестра, сгруппированные по точкам зрения, 12 понятий с бытовыми аналогиями, учебный пример сети центров реагирования и план первой недели. Пример не описывает реальную оборонную систему. Рамка родом из Министерства обороны США, и её словарь оборонный: закупки, программы, миссии. Структура при этом общая, и через MODAF, NAF и UAF та же сетка точек зрения разошлась далеко за пределы ведомства.
Цепочка, на которой держится описание, читается сверху вниз. Способность (Capability Viewpoint) — что предприятие должно уметь. Операции (Operational Viewpoint) — кто с кем должен обмениваться ресурсами, чтобы способность состоялась; центральное понятие здесь — нидлайн (needline), логическая потребность в обмене. Системы и сервисы (Systems, Services Viewpoints) — чем эти обмены реализованы. Проекты (Project Viewpoint) — когда что появится. Сверху всё это накрывает общий контекст (All Viewpoint): зачем описание делали и что в него вошло.
Стандарт не требует всех 52 моделей. Он требует назвать решение, которое архитектура должна поддержать, и взять только те представления, которые к нему ведут.
Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.
DoDAF
Выберите элемент схемы — откроются объяснение и пример.
Титульная сводка архитектурного описания: зачем его делали, что в него вошло, кто заказчик и какие допущения приняты. Отвечает на вопрос «стоит ли мне вообще читать этот комплект» — стандарт прямо говорит, что AV-1 должен дать читателю возможность «select a single Architectural Description from among many to read in more detail».
Фиксируем границы сети центров и цель архитектурной работы.
Выборочный авторский навигатор по подходу. Схема упрощена для объяснения; полный состав записей и источники — в каталоге ниже.
Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.
Уточняем, какой вопрос инвестирования или изменения должна поддержать архитектура.
Выбор представлений связан с задачей руководителя.
Согласуем способности, деятельность, ресурсы и информацию в общей модели.
Одни элементы переиспользуются в разных представлениях.
Сопоставляем варианты развития с зависимостями проектов и ограничениями.
Решение можно объяснить через архитектурные связи.
Разбираем архитектуру предприятия на примере логистической сети. Выбирайте представления в сетке UAF, прослеживайте связи операций, сервисов, людей и ресурсов и находите нужные элементы в каталоге.
Архитектурная рамка НАТО для обороны и коалиционной совместимости. Точки зрения разложены по сетке: ряды — предметы интереса (Concepts, Service, Logical, Physical Resource, Architecture Foundation), столбцы — аспекты интереса (Taxonomy, Structure, Connectivity, Behaviour, Information, Constraints, Roadmap), причём Behaviour раскрывается тремя столбцами (Processes, States, Sequences), так что сетка выходит 5×9. Глава 3 описывает 47 точек зрения: 44 ячейки сетки (C6 в спецификации отсутствует) и три межячеечных представления — C1-S1, L2-L3 и L4-P4.
Архитектурная рамка Министерства обороны Великобритании: от стратегического замысла и способностей до закупок и технических стандартов. Семь точек зрения и 47 представлений. Словарь элементов AV-2 ссылается на источник каждого элемента — онтологию MODAF, модель IDEAS или локальный источник, — а сама онтология MODAF задумана как расширение модели IDEAS 3. Используемый экземпляр — снимок сайта MOD, а не спецификация с предисловием: страницы сняты 2–3 июня 2010 года, PDF собран 4 июня 2010 года.
Полнота каталога не означает обязательность всех представлений в каждой работе. Определите нужные данные и вопросы к ним.
Перед проработкой согласуйте вопрос: Что входит в описание? Ответ должен быть понятен участникам рассматриваемой работы.
Пройдите весь пример от исходной ситуации до результата: Решение можно объяснить через архитектурные связи.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Есть сопоставление с 8 осями из 17
| Ось реестра | В DoDAF | Сопоставление | Пояснение |
|---|---|---|---|
| Управление архитектурой, нормы и соответствие | All Viewpointточка зрения | Охват тот же, что у оси. | Контекст и словарь архитектурного описания (AV-1, AV-2) — управление архитектурой и метаданные. |
| Стратегия и способности | Capability Viewpointточка зрения | Охват тот же, что у оси. | Требования к способностям, сроки их предоставления и развёртывание. |
| Информация и данные | Data and Information Viewpointточка зрения | Охват тот же, что у оси. | Структуры данных и обмены. |
| Изменения, проекты и переход | Project Viewpointточка зрения | Охват тот же, что у оси. | Проекты, программы и их зависимости. |
| Приложения и информационные системы | Services Viewpointточка зрения | Охват тот же, что у оси. | Сервисы, их функции и взаимодействия. |
| Деятельность: функции и процессы + Организация и ответственность | Operational Viewpointточка зрения | Шире оси: этот домен объединяет больше, чем одна общая ось. | Операционные активности и участники: деятельность и организация вместе. |
| Приложения и информационные системы + Технологическая ИТ-инфраструктура | Systems Viewpointточка зрения | Шире оси: этот домен объединяет больше, чем одна общая ось. | Системы, их состав и соединения: и прикладной, и технологический слой. |
| Управление архитектурой, нормы и соответствие | Standards Viewpointточка зрения | С осью пересекается частично. | Применимые политики и стандарты — нормативная рамка архитектуры, а не предметная область. |
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Запишите, какое решение должна поддержать архитектура — например, менять ли систему связи центров, — кто заказчик, что входит в охват, какие допущения приняты. Это AV-1 (Overview and Summary Information). Тут же заведите словарь AV-2 (Integrated Dictionary): каждый термин, который появится в моделях, с определением. Он будет пополняться всю неделю.
Выпишите, что должна уметь сеть центров: приём обращения, оценка ситуации, координация исполнения. Два уровня вложенности, существительными. Это таксономия способностей CV-2 (Capability Taxonomy). Если есть целевой срок и стратегический контекст, добавьте CV-1 (Vision).
Разберите деятельности, которыми обеспечивается каждая способность, — дерево OV-5a (Operational Activity Decomposition Tree). Затем определите, кто с кем должен обмениваться ресурсами, чтобы деятельности состоялись: центры, ответственные организации, что именно передаётся. Это нидлайны на OV-2 (Operational Resource Flow Description). Свяжите способности с деятельностями матрицей CV-6.
Возьмите то, что передаётся по нидлайнам — обращение, событие, назначение исполнителя, — и опишите как понятия с отношениями: концептуальная модель данных DIV-1 (Conceptual Data Model). Сверьте имена со словарём AV-2: одно понятие — одно имя во всех моделях.
Покажите, чем нидлайны реализованы сегодня: системы центров и потоки между ними — SV-1 (Systems Interface Description). Проследите деятельности до функций систем матрицей SV-5a. Если решение затрагивает сроки, добавьте временную шкалу проектов PV-2 (Project Timelines). Теперь решение из AV-1 можно объяснить цепочкой связей.
Если начать с систем и их интерфейсов, архитектура опишет то, что есть, а не то, что нужно. Стандарт строит SV-1 как реализацию логической структуры OV-2: сначала нидлайны — кто с кем должен обмениваться, — потом системы и потоки, которыми это обеспечено. Один нидлайн может превратиться в несколько системных потоков, и это нормально; обратный порядок такой связи не даёт.
OV-5b в одном редакторе, SV-4 в другом, матрица SV-5a — в таблице, собранной руками. Через месяц одна из моделей изменится, и матрица начнёт врать. Смысл DoDAF в том, что представления — проекции одних данных: элемент деятельности в OV-5b и в SV-5a — один и тот же. Если инструмент этого не обеспечивает, хотя бы ведите единый словарь AV-2 и сверяйте с ним имена.
Ради структуры, а не словаря. Восемь точек зрения и цепочка «способность → операции → системы → проекты» подходят любой организации, где решение о системе должно объясняться через то, что организация обязана уметь. Термины придётся переводить: миссия — в услугу или направление, программа закупок — в портфель проектов. Если оборонный словарь мешает, посмотрите на UAF или NAF: там та же сетка в более нейтральных словах.
TOGAF — метод: порядок работы над архитектурой и её документы. ArchiMate — язык, которым записывают результат. DoDAF — рамка описания: какие точки зрения и модели нужны и как их данные связаны; порядка работ и графической нотации в ней нет. На практике модели DoDAF можно рисовать элементами ArchiMate и производить в ходе цикла TOGAF.
Рамка нотацию не задаёт. Для деревьев и таксономий достаточно списка с отступами, для матриц — таблицы, для потоков и последовательностей — BPMN, UML или ArchiMate, смотря что принято в команде. Важнее нотации общие данные: элемент на OV-5b и на SV-5a должен быть одним и тем же объектом, иначе матрицы прослеживаемости придётся править руками.
21 страница: что это и чем не является, устройство подхода, 48 карточек словаря, 12 понятий с аналогиями, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом.
Понятия этого подхода с объяснениями, примерами и типичными ошибками.
Документ описывает стратегический контекст и целевое состояние для группы способностей предприятия.
Это вид модели, который показывает временную последовательность работ по программам и проектам.
Схема показывает, как система действует при выполнении миссии или в заданном сценарии.
Модель операционных деятельностей.
Табличная схема, описывающая, какие данные или ресурсы передаются между системами и в каком виде.
Это схема, показывающая, как события и данные движутся между участниками (узлами, системами или сервисами) во времени.
Подходы, которые описывают предприятие целиком — от стратегии и процессов до данных и ИТ-инфраструктуры: язык, рамка или метод со своей моделью.
Онтология предприятия и метод инженерии предприятия
Эталонная рамка корпоративной архитектуры
Онтология корпоративной архитектуры
Архитектура интегрированного производства
Эталонная архитектура предприятия и методология мастер-планирования
Свод знаний по бизнес-архитектуре
Действующая редакция — v2.02, август 2010 года: сам документ говорит «This is the current release of DoDAF as of August 2010». Более ранние редакции V1.0, V1.5 и 2.01 в нём названы, но годов выпуска у самой рамки нет; даты источник даёт только метамодели — «Version 2.0 was baselined May 2009 and version 2.01, with 68 fixes and improvements, was baselined Feb 2010».
Предшественник назван прямо: «DoDAF V2.0 is a marked change from earlier versions of Command, Control, Communications, Computers, and Intelligence Surveillance Reconnaissance Architecture Framework (C4ISR AF) or DoDAF». Описания самих моделей адаптированы из MODAF: «For the DoDAF-described Model descriptions, a major source of material was adapted from MODAF». Связи в обратную сторону взяты из реестра, а не из этого документа: NAFv3 заменил MODAF v1.2.00, FEAF v2 отображает 29 из своих 50 артефактов на модели DoDAF, а UAF сводит DoDAF и MODAF в единую сетку.
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийБаза знаний и викиРеестр процессов
