Архітектурна система НАТО NAF 4.0: коаліційне планування і проектування сумісності

Коли тридцять союзних країн повинні підключити свої системи командування та управління для коаліційної операції, хтось повинен відповісти на два питання, перш ніж буде підключений хоча б один кабель: яка можливість потрібна коаліції, і що повинні робити системи кожної країни для її забезпечення? Архітектурна система НАТО версії 4.0 — NAF 4.0 — є структурованим методом, який країни використовують для відповіді на обидва питання у формі, яку кожен може прочитати, порівняти та перевірити. У цій статті розглядаються шість аспектів NAF 4.0, пояснюються їх відмінності від американського DODAF та корпоративного TOGAF, і показується, як система застосовується в практичному спіральному плануванні Federated Mission Networking (FMN).

Чому спільна архітектурна система важлива для коаліцій

Без загальної архітектурної мови кожна країна описує власні системи по-своєму. Одна країна робить PowerPoint-діаграму; інша — UML-модель; третя — документ Word. Жоден з них не може бути автоматично порівняний з іншими, і прогалини в сумісності між ними можна виявити лише вручну — повільно, дорого і неповно. NAF 4.0 надає спільну мову. Коли всі країни використовують ті самі аспекти, ту саму мета-модель і той самий словник, структурне порівняння між архітектурою країни і цільовою архітектурою альянсу стає можливим. Прогалини з'являються як відсутні елементи в моделі, а не як недокументовані розбіжності між документами.

Система також забезпечує простежуваність. Технічний стандарт у технічному аспекті повинен простежуватися до служби в аспекті служб, яка повинна простежуватися до потоку інформації в оперативному аспекті, який повинен простежуватися до вимоги можливостей в аспекті можливостей, який повинен простежуватися до стратегічної цілі в стратегічному аспекті. Коли цей ланцюг існує, будь-який зацікавлений може запитати «навіщо нам ця конкретна версія TLS?» і простежити ланцюг до оперативної концепції, яка її вимагає. Коли він не існує, системи накопичують технічний борг, який ніхто не може виправдано усунути.

Шість аспектів NAF 4.0

Стратегічний аспект (St)

Стратегічний аспект охоплює політичний і стратегічний контекст, в якому функціонує архітектура. У застосуванні альянсу це означає стратегічну концепцію НАТО, конкретний мандат місії, зобов'язання країн-учасниць і національні застереження, що обмежують дії сил кожної країни. Аспекти St висловлюють, які результати повинна забезпечити коаліція і в яких політичних обмеженнях. Кожна можливість, визначена в подальших аспектах, повинна простежуватися до стратегічної вимоги — архітектурний елемент, що не може бути прослідкований до стратегічного аспекту, взагалі не має права перебувати в архітектурі.

На практиці стратегічний аспект є найскладнішим для точного створення, оскільки він вимагає прямого залучення політико-військових зацікавлених сторін, які зазвичай не мислять у термінах архітектурного моделювання. Архітектори, які пропускають цей крок і переходять безпосередньо до оперативних аспектів або аспектів систем, створюють технічно узгоджені архітектури, які можуть відповідати на неправильні оперативні питання.

Аспект можливостей (C)

Аспект можливостей визначає, що сили повинні вміти робити, структуровано у вигляді таксономії можливостей із залежностями між ними і часовими фазами в горизонті планування. Можливість у термінах NAF — це здатність досягти бажаного ефекту, незалежно від того, як вона реалізована. «Обмінюватися розпізнаною повітряною картиною між вузлами коаліційного C2 майже в реальному часі» — це можливість; «запустити шлюз Link 16 JREAP-C» — потенційне рішення. Важливо зберігати аспект можливостей нейтральним до рішень: це зберігає свободу задовольнити можливість за допомогою різних реалізацій в різних країнах, зберігаючи при цьому сумісність на межі служб.

У спіральному плануванні FMN аспект можливостей — це місце, де визначається обсяг кожної спіралі. FMN Spiral 4 додає можливості до Spiral 3, і ці прирости можливостей виражаються в аспекті можливостей до будь-яких рішень про системи або служби. Країни використовують той самий аспект для декларування, які можливості FMN вони зобов'язуються реалізувати і в які терміни — створюючи матрицю відповідності, яку відстежує управління FMN.

Оперативний аспект (Op)

Оперативний аспект — це міст між тим, що повинні робити сили, і системами, які це дозволяють. Він описує оперативну концепцію: залучені ролі (командир, офіцер зв'язку, оператор датчика), дії, які вони виконують, інформацію, якою вони обмінюються для їх виконання, та інформаційні вимоги, що генерують ці обміни. Оперативний аспект NAF 4.0 виробляє такі діаграми, як Operational Activity Model (Op-A) та Information Model (Op-Iv), які разом показують, яка інформація між ким тече і за яких умов.

Для проектування сумісності оперативний аспект — це місце, де явно визначаються інформаційні потоки коаліції. Обмін інформацією між національною системою C2 і союзною сенсорною системою стає визначеним вузлом в моделі Op, з визначеним типом інформації та визначеною вимогою своєчасності. Це визначення потім визначає вибір служб і технологій в аспектах нижче. Проблема сумісності, яка не представлена в оперативному аспекті, не може бути систематично вирішена в аспектах систем або служб.

Аспект систем (Sy)

Аспект систем описує фізичні та логічні системи, що реалізують оперативну концепцію. Він показує функції систем, інтерфейси систем, потоки даних між системами і фізичні платформи, на яких розгорнуті системи. Це найбільш знайомий аспект для системних інженерів та інтеграторів — він відповідає за призначенням системним аспектам у DODAF (SV-1 через SV-10) і до домену системної архітектури в загальній практиці.

У коаліційній архітектурі аспект систем повинен представляти як спільну інфраструктуру альянсу (наприклад, Core Services FMN), так і національні системи кожної країни, що підключаються до неї. Специфікації інтерфейсів на межі між національними системами і інфраструктурою альянсу є критичними результатами цього аспекту — вони повинні бути достатньо точними, щоб написати тест на відповідність.

Аспект служб (Sv)

Аспект служб специфікує служби в сенсі сервісно-орієнтованої архітектури (SOA) або API: добре визначені функціональні одиниці з опублікованими інтерфейсами, які системи надають для використання іншими системами. Цей аспект суттєво посилився в NAF 4.0 порівняно з попередніми версіями, що відображає зсув в архітектурі коаліційної сумісності від інтеграції систем точка-точка до сервісно-базованої федерації.

В FMN аспект служб є центральним. Архітектура FMN визначає портфель служб Federated Mission Networking — голосовий зв'язок, миттєві повідомлення, обмін файлами, обмін COP, каталог, управління ідентифікацією — з визначеними інтерфейсами і поведінкою. Кожна служба в каталозі FMN має запис в аспекті служб, який країни можуть реалізовувати незалежно, знаючи, що відповідні реалізації будуть взаємодіяти. Архітектурно це аналогічно роботі прикладного рівня Інтернету: незалежні реалізації спільної специфікації виробляють сумісні служби.

Технічний аспект (Tr)

Технічний аспект перераховує стандарти, технічні профілі і обмеження, яким повинні відповідати системи та служби. Це нормативний довідковий рівень: система, що з'являється в аспекті систем, повинна відповідати стандартам, переліченим для неї в технічному аспекті. В FMN технічний аспект містить конкретні посилання на STANAG, версії протоколів, вимоги до наборів шифрів та специфікації інтерфейсів, що реалізують служби кожної спіралі.

Технічний аспект — це місце, де архітектура NAF 4.0 найбільш безпосередньо перетинається з закупівлями. Специфікація закупівлі для національної системи, що підключатиметься до FMN, повинна мати можливість безпосередньо витягти технічні вимоги з технічного аспекту, а результуюча система повинна пройти тестування на відповідність цим же вимогам. Коли цей ланцюг зберігається, архітектурний документ є живою специфікацією; коли він руйнується, архітектура стає історичним артефактом, що не має ніякого відношення до того, що фактично було закуплено.

NAF порівняно з DODAF і TOGAF

NAF 4.0 і DODAF 2.02 — це близькі родичі, а не конкуренти. Вони мають спільне коріння, і їх аспекти можна зіставити на концептуальному рівні. Основна відмінність — у управлінні: DODAF є американським національним стандартом Міністерства оборони США; NAF є стандартом альянсу, що зобов'язує країни НАТО та партнерів, які його приймають. Американські організації, що працюють над натівськими програмами, зазвичай виробляють архітектури, які одночасно задовольняють обидві системи, оскільки структури аспектів достатньо сумісні, щоб одна модель могла генерувати відповідні продукти в обох. Де вони розходяться — у деталях мета-моделі: NAF 4.0 побудований на MODEM (MODAF Object Model), який в деяких областях формально більш специфікований, ніж базова мета-модель DM2 DODAF.

TOGAF займає зовсім іншу область. The Open Group Architecture Framework — це корпоративна ІТ-архітектурна система, побудована навколо Architecture Development Method (ADM), який структурує архітектурну роботу як серію ітеративних фаз, орієнтованих на надання бізнес-змін з підтримкою ІТ. TOGAF не має вбудованої моделі оперативних концепцій, військових місій або таксономій можливостей — він орієнтований на надання ІТ-послуг, управління портфелем застосунків та організаційне управління змінами. Оборонні організації іноді використовують TOGAF у своїх внутрішніх програмах ІТ-закупівель, паралельно з NAF, а не замість нього. Дві системи служать різним зацікавленим сторонам: NAF відповідає на питання, як коаліційні сили будуть діяти разом; TOGAF відповідає на питання, як організація управлятиме своїми ІТ для підтримки бізнес-процесів.

NAF у спіральному плануванні FMN

Програма Federated Mission Networking використовує NAF як архітектурну мову протягом всього циклу спірального планування. Кожна спіраль FMN визначається цільовою архітектурою, вираженою в аспектах NAF, а відповідність країн вимірюється відносно цього цільового рівня. Процес виглядає наступним чином. По-перше, Capability Framework FMN визначає прирости можливостей, які спіраль повинна забезпечити — результат аспекту можливостей. По-друге, Робоча група з архітектури FMN виробляє оперативні аспекти, що описують, як ці можливості будуть реалізовуватися на практиці. По-третє, для кожної служби в каталозі спіралі пишуться специфікації служб — продукти аспекту служб. По-четверте, для кожної служби визначаються технічні профілі — продукти технічного аспекту. По-п'яте, країни оцінюють власні архітектури відносно цільового рівня FMN, виявляючи прогалини між існуючими системами та необхідними службами.

Країни, що вклали кошти в інструментарій і дисципліну NAF, можуть виконувати цей аналіз прогалин напівавтоматично: порівнювати записи технічного аспекту країни з вимогами технічного аспекту FMN і генерувати структурований список невідповідностей. Країни без зрілої національної архітектурної практики виконують той самий аналіз вручну, що є повільнішим і більш схильним до помилок, але виробляє той самий тип результатів. Список прогалин стає вхідними даними для плану розвитку національних можливостей — дорожньої карти закупівель, оновлень і конфігурацій, що забезпечать відповідність країни вимогам FMN для спіралі. Для отримання докладнішої інформації про вимоги FMN Spiral 4 дивіться наш аналіз вимог FMN Spiral 4.

CWIX — Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — це щорічний захід, де відповідність FMN перевіряється на практиці, а не на папері. Зв'язок між архітектурою NAF і тестуванням CWIX є прямим: тестові сценарії, що виконуються на CWIX, повинні виходити з специфікацій інтерфейсів в аспектах служб і технічних аспектах NAF. Архітектура, яка не проектувалася з урахуванням можливості тестування — з чіткими визначеннями інтерфейсів, які можна безпосередньо перекласти в тестові сценарії — буде виробляти неоднозначні результати CWIX, які важко усунути. Наш аналіз дорожньої карти спіралі FMN охоплює, як послідовні спіралі будуються одна на одній і якою є майбутня траєкторія розвитку можливостей FMN.