NATO:n arkkitehtuurikehys NAF 4.0: koalitiosuunnittelu ja yhteensopivuussuunnittelu

Kun kolmekymmentä liittoutunutta kansakuntaa tarvitsee yhdistää komento-ja-hallintajärjestelmänsä koalitio-operaatiota varten, jonkun on vastattava kahteen kysymykseen ennen kuin yhtäkään kaapelia kytketään: mitä kyvykkyyttä koalitio tarvitsee, ja mitä jokaisen kansakunnan järjestelmien on tehtävä sen toimittamiseksi? NATO:n arkkitehtuurikehys versio 4.0 — NAF 4.0 — on strukturoitu menetelmä, jota kansakunnat käyttävät vastatakseen molempiin kysymyksiin muodossa, jonka kaikki voivat lukea, vertailla ja testata vastaan. Tässä artikkelissa tarkastellaan NAF 4.0:n kuutta näkökulmaa, selitetään, miten ne eroavat Yhdysvaltain DODAF:sta ja yritysmaailman TOGAF:sta, ja näytetään, miten kehystä sovelletaan käytännön Federated Mission Networking (FMN) -kierrossuunnittelussa.

Miksi yhteinen arkkitehtuurikehys on tärkeä koalitioille

Ilman yhteistä arkkitehtuurikieltä jokainen kansakunta kuvaa omat järjestelmänsä omalla tavallaan. Yksi kansakunta tuottaa PowerPoint-kaavion; toinen tuottaa UML-mallin; kolmas tuottaa Word-asiakirjan. Mitään näistä ei voi automaattisesti vertailla toisiin, ja niiden väliset yhteensopivuuspuutteet voidaan löytää vain manuaalisesti — hitaasti, kalliisti ja epätäydellisesti. NAF 4.0 tarjoaa yhteisen kielen. Kun kaikki kansakunnat käyttävät samoja näkökulmia, samaa metamallia ja samaa sanastoa, strukturoitu vertailu kansakunnan arkkitehtuurin ja liitouman tavoitearkkitehtuurin välillä tulee hallittavaksi. Puutteet näyttävät puuttuvina elementteinä mallissa eikä dokumentoitumattomina erimielisyyksinä asiakirjojen välillä.

Kehys tarjoaa myös jäljitettävyyden. Tekninen standardi teknisessä näkökulmassa tulisi olla jäljitettävissä palveluun palvelunäkökulmassa, joka tulisi olla jäljitettävissä tietovirtaan operatiivisessa näkökulmassa, joka tulisi olla jäljitettävissä kyvykkyysvaatimukseen kyvykkyys-näkökulmassa, joka tulisi olla jäljitettävissä strategiseen tavoitteeseen strategisessa näkökulmassa. Kun tämä ketju on olemassa, mikä tahansa sidosryhmä voi kysyä "miksi tarvitsemme tämän TLS-version?" ja seurata ketjua operatiiviseen konseptiin, joka vaatii sen. Kun se ei ole olemassa, järjestelmät keräävät teknistä velkaa, jota kukaan ei pysty perustelemaan poistettavaksi.

NAF 4.0:n kuusi näkökulmaa

Strateginen näkökulma (St)

Strateginen näkökulma kaappaa poliittisen ja strategisen kontekstin, jossa arkkitehtuuri toimii. Liittouman käytössä tämä tarkoittaa NATO:n strategista konseptia, erityistä tehtävämandaattia, osallistuvien kansakuntien sitoumuksia ja kansallisia varaumia, jotka rajoittavat mitä kukin kansakunnan joukot voivat tehdä. St-näkymät ilmaisevat, mitä tuloksia koalition on tuotettava ja millä poliittisilla rajoituksilla. Jokaisen myöhemmissä näkökulmissa määritellyn kyvykkyyden on oltava jäljitettävissä strategiseen vaatimukseen — arkkitehtuurielementti, jota ei voi jäljittää strategiseen näkökulmaan, ei kuulu arkkitehtuuriin lainkaan.

Käytännössä strateginen näkökulma on vaikein tuottaa tarkasti, koska se vaatii suoraa vuorovaikutusta poliittis-sotilaallisten sidosryhmien kanssa, jotka eivät tyypillisesti ajattele arkkitehtuurimallinnuksen termein. Arkkitehdit, jotka ohittavat tämän vaiheen ja siirtyvät suoraan operatiivisiin tai järjestelmänäkymiin, tuottavat teknisesti johdonmukaisia arkkitehtuureja, jotka saattavat vastata vääriin operatiivisiin kysymyksiin.

Kyvykkyys-näkökulma (C)

Kyvykkyys-näkökulma määrittelee, mitä joukon on kyettävä tekemään, jäsennettynä kyvykkyys-taksonomiana niiden välisine riippuvuuksineen ja ajallisine vaiheineen suunnitteluhorisontin yli. NAF-termein kyvykkyys on kyky saavuttaa haluttu vaikutus — riippumatta siitä, miten se toteutetaan. "Jaa tunnistettu ilmakuva koalition C2-solmujen välillä lähes reaaliajassa" on kyvykkyys; "aja Link 16 JREAP-C -yhdyskäytävä" on potentiaalinen ratkaisu. Kyvykkyys-näkökulman pitäminen ratkaisusta riippumattomana on tärkeää: se säilyttää vapauden tyydyttää kyvykkyys eri toteutuksilla eri kansakunnissa samalla kun pysytään yhteensopivina palvelurajapinnassa.

FMN-kierrossuunnittelussa kyvykkyys-näkökulma on paikka, jossa jokaisen kierroksen laajuus määritellään. FMN Spiral 4 lisää kyvykkyyksiä Spiral 3:n yli, ja nämä inkrementaaliset kyvykkyydet ilmaistaan kyvykkyys-näkökulmassa ennen kuin järjestelmä- tai palvelupäätöksiä tehdään. Kansakunnat käyttävät samaa näkökulmaa ilmoittaakseen, mitkä FMN:n kyvykkyydet ne sitoutuvat toteuttamaan ja missä aikataulussa — tuottaen vaatimustenmukaisuusmatriisin, jota FMN:n hallinto seuraa.

Operatiivinen näkökulma (Op)

Operatiivinen näkökulma on silta sen välillä, mitä joukon on tehtävä, ja järjestelmien välillä, jotka antavat sen tehdä niin. Se kuvaa operatiivisen konseptin: mukana olevat roolit (komentaja, yhteysupseeri, anturioperaattori), heidän suorittamansa toiminnot, heidän vaihtamansa tieto näiden suorittamiseksi ja tietovaatimukset, joita nämä vaihdot tuottavat. NAF 4.0:n operatiivinen näkökulma tuottaa kaavioita kuten operatiivisen toimintamallin (Op-A) ja informaatiomallin (Op-Iv), jotka yhdessä osoittavat, mitä tietoa virtaa kenen välillä ja millä ehdoilla.

Yhteensopivuussuunnittelussa operatiivinen näkökulma on paikka, jossa koalition tietovirrat tehdään eksplisiittisiksi. Tietojenvaihtotapahtuma kansallisen C2-järjestelmän ja liittoutuneen anturijärjestelmän välillä muodostuu määritellyksi solmuksi Op-mallissa, jossa on määritelty tietotyyppi ja ajantasaisuusvaatimus. Tämä määritelmä ohjaa sitten palvelu- ja teknisiä valintoja sen alla olevissa näkökulmissa. Yhteensopivuusongelma, jota ei ole edustettuna operatiivisessa näkökulmassa, ei voi olla järjestelmällisesti käsitelty järjestelmä- tai palvelunäkökulmissa.

Järjestelmä-näkökulma (Sy)

Järjestelmä-näkökulma kuvaa fyysiset ja loogiset järjestelmät, jotka toteuttavat operatiivisen konseptin. Se näyttää järjestelmätoiminnot, järjestelmärajapinnat, tietovirrat järjestelmien välillä ja fyysiset alustat, joille järjestelmät on otettu käyttöön. Tämä on tuttavin näkökulma järjestelmäinsinööreille ja integraattoreille — se vastaa laajasti DODAF:n järjestelmätason näkymiä (SV-1–SV-10) ja järjestelmäarkkitehtuurin toimialuetta yleisessä käytännössä.

Koalitioarkkitehtuurissa järjestelmä-näkökulman on edustettava sekä liitouman yhteistä infrastruktuuria (kuten FMN Core Services) että jokaisen kansakunnan kansallisia järjestelmiä, jotka yhdistyvät siihen. Rajapintaspesifikaatiot kansallisten järjestelmien ja liittouman infrastruktuurin rajapinnassa ovat tämän näkökulman kriittiset toimitukset — niiden on oltava riittävän tarkkoja, jotta niistä voidaan kirjoittaa vaatimustenmukaisuustesti.

Palvelu-näkökulma (Sv)

Palvelu-näkökulma täsmentää palvelut palvelupohjaisen arkkitehtuurin (SOA) tai API-mielessä: hyvin määriteltyjä toiminnallisia yksiköitä julkaistuine rajapintoineen, joita järjestelmät paljastavat muiden järjestelmien kulutettavaksi. Tätä näkökulmaa vahvistettiin olennaisesti NAF 4.0:ssa aiempiin versioihin nähden, mikä heijastaa muutosta koalition yhteensopivuusarkkitehtuurissa pisteestä pisteeseen -järjestelmäintegraatiosta kohti palvelupohjaista federaatiota.

FMN:ssä palvelu-näkökulma on keskeinen. FMN-arkkitehtuuri määrittelee Federated Mission Networking -palveluportfolion — ääni, pikaviestit, tiedostonjako, COP-vaihto, hakemisto, identiteetin hallinta — täsmennettyine rajapintoineen ja käyttäytymistapoineen. Jokaisella FMN-luettelon palvelulla on palvelu-näkökulmakirjaus, jonka kansakunnat voivat toteuttaa itsenäisesti tietäen, että standardin mukaiset toteutukset toimivat yhteen. Tämä on arkkitehtuurisesti samanlaatuinen kuin Internetin sovelluskerros toimii: yhteisen spesifikaation itsenäiset toteutukset tuottavat yhteensopivia palveluja.

Tekninen näkökulma (Tr)

Tekninen näkökulma luettelee standardit, tekniset profiilit ja rajoitteet, joita järjestelmien ja palvelujen on noudatettava. Se on normatiivinen viitekerros: järjestelmä-näkökulmassa esiintyvän järjestelmän on noudatettava teknisessä näkökulmassa sille lueteltuja standardeja. FMN:ssä tekninen näkökulma sisältää erityiset STANAG-viittaukset, protokollaversiot, salausohjelmapakettivaatimukset ja rajapintaspesifikaatiot, jotka toteuttavat kunkin kierroksen palvelut.

Tekninen näkökulma on paikka, jossa NAF 4.0 -arkkitehtuuri leikkaa suorimmin hankinnan kanssa. FMN:ään liittyvän kansallisen järjestelmän hankintaspesifikaation tulisi kyetä poimimaan tekniset vaatimuksensa suoraan teknisestä näkökulmasta — ja tuloksena olevan järjestelmän tulisi läpäistä vaatimustenmukaisuustestaus samojen vaatimusten mukaan. Kun tämä ketju pitää, arkkitehtuuridokumentti on elävä spesifikaatio; kun se katkeaa, arkkitehtuurista tulee historiallinen artefakti, jolla ei ole suhdetta siihen, mitä todella hankittiin.

NAF versus DODAF versus TOGAF

NAF 4.0 ja DODAF 2.02 ovat läheisiä sukulaisia, eivät kilpailijoita. Ne jakavat yhteisen alkuperän, ja heidän näkymänsä voidaan ristiintäsmäyttää käsitteellisellä tasolla. Tärkein ero on hallinto: DODAF on Yhdysvaltain DoD:n kansallinen standardi; NAF on liitouman standardi, joka sitoo NATO:n kansakuntia ja kumppanikansakuntia, jotka ottavat sen käyttöön. Yhdysvaltalaiset organisaatiot, jotka työskentelevät NATO-ohjelmien parissa, tuottavat tyypillisesti arkkitehtuureja, jotka täyttävät molemmat kehykset samanaikaisesti, koska näkymärakenteet ovat riittävän yhteensopivia, jotta yksi malli voi tuottaa vaatimuksenmukaisia tuotteita molemmissa. Missä ne eroavat, on metamallien yksityiskohdat: NAF 4.0 on rakennettu MODEMille (MODAF-objektimalli), joka on joillakin alueilla muodollisemmin täsmennetty kuin DODAF:n taustalla oleva DM2-metamalli.

TOGAF on täysin eri toimialueella. The Open Group Architecture Framework on yritys-IT-arkkitehtuurimenetelmä, joka on rakennettu arkkitehtuurin kehitysmenetelmän (ADM) ympärille, joka jäsentää arkkitehtuurin työn sarjaksi iteratiivisia vaiheita, jotka keskittyvät IT-mahdollistaman liiketoimintamuutoksen toimittamiseen. TOGAF:ssa ei ole luontaista mallia operatiivisista konsepteista, sotilaallisista tehtävistä tai kyvykkyys-taksonomioista — se on suunnattu IT-palvelujen toimittamiseen, sovellusportfolion hallintaan ja organisaation muutoshallintaan. Puolustusorganisaatiot käyttävät joskus TOGAF:ia sisäisissä IT-hankintaohjelmaissa, rinnakkain NAF:in kanssa eikä sen sijaan. Nämä kaksi kehystä palvelevat eri sidosryhmiä: NAF vastaa kysymykseen, miten koalitijoukot toimivat yhdessä; TOGAF vastaa kysymykseen, miten organisaatio hallinnoi IT:tään liiketoimintaprosessiensa tukemiseksi.

NAF FMN-kierrossuunnittelussa

Federated Mission Networking -ohjelma käyttää NAF:ia arkkitehtuurikielenä koko kierrossuunnittelusyklin ajan. Jokainen FMN-kierros määritellään NAF-näkymissä ilmaistulla tavoitearkkitehtuurilla, ja kansallinen vaatimustenmukaisuus mitataan kyseistä tavoitetta vastaan. Prosessi etenee seuraavasti. Ensiksi FMN Capability Framework tunnistaa kyvykkyysinkrementit, jotka kierroksen on toimitettava — kyvykkyys-näkökulman toimitettava. Toiseksi FMN Architecture Working Group tuottaa operatiiviset näkymät, jotka kuvaavat, miten nämä kyvykkyydet tullaan käyttämään käytännössä. Kolmanneksi palveluspesifikaatiot kirjoitetaan jokaiselle kierroksen luettelon palvelulle — palvelu-näkökulman tuotteet. Neljänneksi teknisiä profiileja tunnistetaan jokaiselle palvelulle — teknisen näkökulman tuotteet. Viidenneksi kansakunnat arvioivat omat arkkitehtuurinsa FMN-tavoitetta vasten, tunnistaen puutteet olemassa olevien järjestelmiensä ja vaadittujen palvelujen välillä.

Kansakunnat, jotka ovat investoineet NAF-työkaluihin ja -kuriin, voivat suorittaa tämän puute-analyysin puoliautomaattisesti: vertaa kansakunnan teknisen näkökulman kirjauksia FMN:n teknisen näkökulman vaatimuksiin ja tuota strukturoitu luettelo vaatimusten vastaisista kohdista. Kansakunnat, joilla ei ole kypsää kansallista arkkitehtuurikäytäntöä, suorittavat saman analyysin manuaalisesti, mikä on hitaampaa ja virhealttiimpaa, mutta tuottaa saman kategorian tuloksia. Puuteluettelosta tulee syöte kansalliseen kyvykkyyden kehityssuunnitelmaan — hankintoja, päivityksiä ja konfiguraatioita koskeva etenemissuunnitelma, joka tuo kansakunnan FMN-vaatimustenmukaisuuteen kierroksella. Lisätietoja siitä, mitä FMN Spiral 4 erityisesti vaatii, on analyysissamme FMN Spiral 4 -vaatimuksista.

CWIX — Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — on vuosittainen tapahtuma, jossa FMN-vaatimustenmukaisuus testataan käytännössä eikä vain paperilla. NAF-arkkitehtuurin ja CWIX-testauksen välinen suhde on suora: CWIX:ssä suoritettavien testien tulisi olla johdettuja NAF-palvelu- ja teknisten näkökulmien rajapintaspesifikaatioista. Arkkitehtuuri, jota ei ole suunniteltu testattavuuden mielessä — selkein rajapintamäärittelyin, jotka voidaan suoraan kääntää testiehtodoksioksi — tuottaa epäselviä CWIX-tuloksia, joita on vaikea korjata. Analyysimme FMN-kierrossuunnitelmasta kattaa, miten peräkkäiset kierrokset rakentuvat toistensa päälle ja miltä FMN:n kyvykkyydenkehityksen tuleva suunta näyttää.