Корпоративные архитектуры

NAF: согласовать архитектуру совместной деятельности

Архитектурная рамка НАТО для оборонных систем и совместимости сил коалиции. Точки зрения разложены по сетке: ряды — предметы интереса (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.

Тип: Архитектурная рамка
Редакция: v4.1 (2026.03)
Первоисточник: www.nato.int

Служебные сведения

Связей в реестре: 12

NAF — Кольцо участников альянса вокруг общего ядра

165артефактов

Зачем это нужно

Почему одинаковые поля в двух системах не значат, что организации совместимы

Штаб, спасатели и логисты обмениваются сводками в одном формате, а на месте выясняется: «доставлено» у одних значит «выгружено на склад», у других — «передано получателю». Формат совпал, смысл — нет.

NAF существует ради этой ситуации: несколько организаций со своими системами, регламентами и словами должны действовать вместе, и никто из них не начальник другому. Ответ рамки — сетка. Пять рядов говорят, о чём идёт речь: способности и замысел (Concepts), сервисы (Service), логические узлы и деятельность (Logical), физические ресурсы (Physical Resource) и сама архитектура как продукт (Architecture Foundation). Девять столбцов говорят, что именно об этом сказано: таксономия, структура, связи, процессы, состояния, последовательности, информация, ограничения, дорожная карта. Ячейка — точка зрения со своим вопросом. Описание, собранное по сетке, позволяет проверить, что потребность в обмене (линия потребности в L2) подкреплена реальным обменом (L3), сервисом (S1) и техникой с протоколом (P3).

Сетка большая — 47 точек зрения, в реестре 165 карточек и 129 понятий, — и целиком её не заполняет никто. Её ценность в парности рядов. Логический ряд говорит, что должно происходить, независимо от техники; ресурсный — чем это будет сделано; ряд концепций — зачем. Разрыв между рядами и есть найденная проблема: сервис обещан в S1, а конфигурации ресурсов, которая его предоставит, в P2 нет. У гражданской компании те же задачи: холдинг сводит две купленные компании, оператор работает с партнёрами, региональная служба координирует ведомства. Четвёртая версия к тому же согласовала термины с ISO 42010, TOGAF 9.1 и ISO 15288, так что описание по NAF читается людьми из мира TOGAF и ArchiMate.

Сетка NAF нужна не ради 47 картинок, а ради одной проверки: обещанный сервис, логическая потребность и физический ресурс должны сойтись на одном сценарии.

Кому это полезно

Аналитику — чтобы описывать взаимодействие организаций в логическом ряду (узлы, линии потребности, активности), не привязываясь к чьей-то системе.
Архитектору — чтобы прослеживать путь от способности до ресурса и протокола и находить разрывы между рядами сетки до того, как они проявятся на месте.
Руководителю — чтобы видеть в ряду концепций, какие способности нужны, к какому сроку они требуются (C2) и когда их по оценке доставят проекты (Cr).

Чем это не является

Это не язык моделирования: NAF говорит, какие точки зрения нужны и что в каждой должно быть, но не какими фигурами это рисовать. Для картинок берут UAF (на UML и SysML) или ArchiMate — сама спецификация отсылает к руководствам по обоим.
Это не только для военных: Учебный пример реестра — гражданский: помощь после паводка. Сетка про координацию организаций, а не про вооружение; словарь — способность, узел, ресурс, сервис — нейтральный. Военной остаётся история, а не устройство.
Это не 47 обязательных документов: В точке зрения A2 вы сами перечисляете, какие представления входят в ваше описание, для каких заинтересованных сторон и какие их интересы закрывают. Первый проход по плану из этой раздатки обходится десятком ячеек.

Сетка NAF: от концепций к ресурсам

Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.

Предмет / аспект	Таксономия	Структура	Связи	Процессы	Состояния	Последовательности	Информация	Ограничения	Развитие
Concepts · Концепции
Services · Сервисы
Logical · Логическое
Physical · Ресурсы
Architecture · Основа

Выберите элемент схемы — откроются объяснение и пример.

Таксономия способностей

Что должна обеспечивать совместная деятельность?

Перечень способностей предприятия, разложенный в иерархию «вид — подвид», причём принципиально без привязки к тому, чем эти способности будут реализованы. Ячейка стоит в столбце Taxonomy, то есть делает для ряда Concepts ровно то же, что L1 для логического ряда, P1 для ресурсного и S1 для сервисного: задаёт словарь, на который потом ссылаются все остальные ячейки ряда.

В нашем примере

Нужны оценка обстановки, доставка помощи и координация ресурсов.

Связанные карточки

Таксономия способностей ↗

Навигатор основных представлений NAF по пяти рядам и девяти колонкам. Названия конкретных ячеек могут уточнять общий аспект; межрядные сопоставления доступны отдельно в каталоге. Пустая ячейка не означает запрет на моделирование.

Несколько организаций координируют помощь после паводка

Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.

01
Согласовать совместную способность
Определяем ожидаемый результат, участников и ограничения взаимодействия.
Результат
Понятно, какую совместную работу должна поддержать архитектура.
Таксономия способностей ↗
02
Сопоставить представления
Связываем потребности, сервисы, логическое взаимодействие и физическую реализацию.
Результат
Разрывы между обещанным сервисом и доступным ресурсом видны заранее.
Таксономия сервисов ↗
03
Проверить обмен
Проходим один запрос помощи через всех участников и сверяем используемые понятия.
Результат
Согласованность подтверждена на конкретном сценарии.
Логическая таксономия ↗

Связанные подходы

UAF ↗

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

DoDAF ↗

Архитектурная рамка Министерства обороны США для оборонных и сложных систем. Задаёт восемь точек зрения — All, Capability, Data and Information, Operational, Project, Services, Standards, Systems — и 52 модели внутри них; отдельным слоем стоит метамодель DM2, в реестр не переносившаяся.

MODAF ↗

Архитектурная рамка Министерства обороны Великобритании: от стратегического замысла и способностей до закупок и технических стандартов. Семь точек зрения и 47 представлений. Словарь элементов AV-2 ссылается на источник каждого элемента — онтологию MODAF, модель IDEAS или локальный источник, — а сама онтология MODAF задумана как расширение модели IDEAS 3. Используемый экземпляр — снимок сайта MOD, а не спецификация с предисловием: страницы сняты 2–3 июня 2010 года, PDF собран 4 июня 2010 года.

Где теряется смысл подхода

Считать одинаковый формат доказательством совместимости

Даже одинаково названные поля могут означать разное. Проверяйте смысл информации, ответственность и условия взаимодействия.

Не договориться о результате

Перед проработкой согласуйте вопрос: Что должна обеспечивать совместная деятельность? Ответ должен быть понятен участникам рассматриваемой работы.

Не проверить на конкретном случае

Пройдите весь пример от исходной ситуации до результата: Согласованность подтверждена на конкретном сценарии.

Сопоставление с частями предприятия

Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.

Есть сопоставление с 6 осями из 17

Ось реестра	В NAF	Сопоставление	Пояснение
Стратегия и способности	Concepts (C)ось	Охват тот же, что у оси.	Ряд сетки NAF: способности и концепты предприятия.
Приложения и информационные системы	Service Specifications (S)ось	Охват тот же, что у оси.	Ряд сетки: спецификации сервисов.
Управление архитектурой, нормы и соответствие	Architecture Foundation (A)ось	Охват тот же, что у оси.	Ряд сетки: метаданные, стандарты и основания архитектуры.
Технологическая ИТ-инфраструктура + Производство и физические активы	Physical Resource Specifications (P)ось	Шире оси: этот домен объединяет больше, чем одна общая ось.	Ряд сетки: физические ресурсы — и ИТ, и материальные.
Деятельность: функции и процессы	Logical Specifications (L)ось	С осью пересекается частично.	Ряд сетки: логические узлы и активности, независимые от реализации.
Делит по другому признаку	Taxonomy · Structure · Connectivity · Processes · States · Sequences · Information · Constraints · Roadmapось	Вне общих осей	Столбец сетки: задаёт РОД модели (таксономия, структура, связность, процессы…), а не предметную область. Пересекает все ряды сетки сразу. У NAF эта ось к тому же не строго однородна: в ряду C «States» занят эффектами, в ряду A «Sequences» — версиями архитектуры.

С чего начать: NAF за неделю

Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.

День первый. Замысел (ряд C).
C2 «Видение предприятия» на одной странице: чего должна достичь совместная работа, какие фазы. C1 — три-пять способностей без привязки к системам: оценка обстановки, доставка помощи, координация ресурсов. Заведите A1 — словарь самой архитектуры — и внесите первые термины.
День второй. Логика (ряд L).
L1: узлы — штаб, отряд, склад партнёра — как логические места, а не подразделения. L2: линии потребности между ними. L4: активности одного сценария — запрос помощи, согласование, назначение исполнителя — с потоками управления. Техники по-прежнему нет.
День третий. Обмен (L3, L7).
Для каждой линии потребности — что именно передаётся: донесение, заявка, карточка (L3). Сущности и атрибуты этих сведений — L7. Здесь и всплывёт, что «доставлено» у двух участников значит разное. Запишите оба значения в словарь и выберите одно.
День четвёртый. Сервисы и ресурсы (ряды S и P).
S1: какие сервисы участники предоставляют друг другу — например, актуальное состояние маршрутов и пунктов помощи; C1-S1 — какую способность каждый сервис обеспечивает. P1 и P2: какие ресурсы и их конфигурации это реализуют. P3: по каким протоколам и стандартам они взаимодействуют.
День пятый. Сценарий и разрывы (L6, P6, A2).
Проведите один запрос помощи по L6 (логическая последовательность) и по P6 (последовательность ресурсов). У каждого логического обмена должен найтись физический носитель. Что не нашлось — список разрывов. В A2 запишите, какие точки зрения вы построили и для кого.

Где ещё ошибаются

Начать с ресурсного ряда

Ряд P — самый знакомый: радиостанции, серверы, грузовики, протоколы. Но без L2 и L3 — кому что от кого нужно и что именно передаётся — таблица протоколов в P3 отвечает «как», не отвечая «зачем». Спускайтесь в ресурсы из логического ряда, а не наоборот.

Принять линию потребности за обмен

Линия потребности (Needline) в L2 говорит только, что узлам нужно обмениваться. Что именно передаётся — это L3; по какому протоколу — P3. Линия, у которой так и не появилось ни одного взаимодействия в L3, — не украшение схемы, а найденный разрыв.

Что ещё спрашивают

Чем NAF отличается от UAF?

NAF — рамка: какие точки зрения нужны и что в них должно быть. UAF — язык и метамодель OMG на основе UML и SysML, в которых эти точки зрения можно нарисовать; UAF собрал в одну сетку DoDAF, MODAF и NAF v4. Сама спецификация NAF говорит, что её информационная модель — основа для руководства по UAF, а не для прямой реализации. Нужен инструмент — берите UAF; нужен разговор с заказчиком о том, что вообще описывать, — NAF.

Нужны ли все девять столбцов?

Нет. На первую неделю хватает таксономии, структуры, связей и процессов. Состояния и последовательности нужны, когда есть конкретный сценарий с событиями; дорожные карты — когда обсуждают сроки; ограничения заполняют по мере появления правил. Информация (L7, P7) нужна раньше, чем кажется: именно там ловятся расхождения в смысле полей.

Как сочетать с BPMN и ArchiMate?

L4 — логические активности с потоками управления — естественное место для BPMN: NAF задаёт, что там должно быть, но не нотацию. ArchiMate — один из двух путей реализации, для которых у NAF есть руководство. Разумная раскладка: NAF говорит, какие представления нужны, ArchiMate или UAF — чем их рисовать, BPMN — шаги процессов внутри L4 и P4.

Раздатка · PDF

NAF простыми словами

21 страница: что это и чем не является, устройство подхода, 48 карточек словаря, 12 понятий с аналогиями, учебный пример и план первой недели.

Устройство подхода: 44 части с вопросами и примерами
Словарь: 48 карточек простыми словами из 165 на странице
Учебный пример: Несколько организаций координируют помощь после паводка
Типичные ошибки, план первой недели и ответы на вопросы

21 страница · 0,85 МБ · A4

Пришлём ссылку сразу после отправки формы

Артефакты

Дословные выписки из стандарта с переводом.

Architecture Foundation (A) — основание архитектуры

34 строки

Physical Resource (P) — ресурсы и системы

31 строка

Service (S) — сервисы

28 строк

Logical (L) — логический (операционный) уровень

28 строк

Сквозной концепт — строки сетки

24 строки

Concepts (C) — способности и стратегический замысел

20 строк

Разобрали простыми словами

Понятия этого подхода с объяснениями, примерами и типичными ошибками.

Архитектурное ограничение

Это жёсткое требование или граница, которую любое решение проблемы обязано соблюдать.

Архитектурный проект

Это деятельность, направленная на поставку архитектуры.

Атрибут данных

Представление свойства сущности данных.

Атрибут информации

Это описание конкретного свойства информационной сущности.

Базовая версия архитектуры

Это зафиксированный срез архитектуры, который служит точкой отсчёта.

Библиотека

Собрание артефактов.

В той же категории

Подходы, которые описывают предприятие целиком — от стратегии и процессов до данных и ИТ-инфраструктуры: язык, рамка или метод со своей моделью.

DEMO

Онтология предприятия и метод инженерии предприятия

МАРФА

Эталонная рамка корпоративной архитектуры

Zachman

Онтология корпоративной архитектуры

CIMOSA

Архитектура интегрированного производства

PERA

Эталонная архитектура предприятия и методология мастер-планирования

BIZBOK

Свод знаний по бизнес-архитектуре

История редакций

Титул действующего издания: NATO Architecture Framework Version 4.1, Architecture Capability Team, Digital Policy Committee, March 2026, Document Version 2026.03.

Раздел «Reason for Change» первой главы датирует предшественника — «NAF version 3 (NAFv3) was issued in 2007», — а сноска к этой фразе уточняет: «NAFv3 was issued as Annex 1 to AC/322-D(2007)0048, was released to the public with AC/322-D(2015)0009. It replaced MODAF Version 1.2.00».

Причина перехода к четвёртой редакции названа там же: NAFv3 «did not align with major terms and concepts» шести стандартов — ISO/IEC/IEEE 42010, ISO/IEC/IEEE 42020, ISO/IEC/IEEE 42030, TOGAF версии 9.1, ISO/IEC/IEEE 15288 и ISO 15704, — и NAFv4 эти ограничения устраняет.

Реализацию своей информационной модели спецификация от себя отделяет: NAF IM «is not intended for direct implementation», он служит концептуальной основой для отдельных руководств — по UAF DMM и по ArchiMate.

14 дней бесплатно

Опишите архитектуру своей компании в Storm

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

Попробовать бесплатно Без банковской карты

Это же в StormАрхитектура систем и интеграций База знаний и вики Реестр процессов