NATO Architecture Framework NAF 4.0: planowanie koalicyjne i projektowanie interoperacyjności

Kiedy trzydzieści sojuszniczych narodów musi połączyć swoje systemy dowodzenia i kontroli na potrzeby operacji koalicyjnej, ktoś musi odpowiedzieć na dwa pytania przed podłączeniem choćby jednego kabla: jakiej zdolności potrzebuje koalicja i co muszą robić systemy każdego narodu, żeby ją dostarczyć? NATO Architecture Framework wersja 4.0 — NAF 4.0 — to ustrukturyzowana metoda, którą narody używają do odpowiedzi na oba pytania w formie, którą wszyscy mogą odczytać, porównać i przetestować. Niniejszy artykuł omawia sześć punktów widzenia NAF 4.0, wyjaśnia, jak różnią się od US DODAF i korporacyjnego TOGAF, oraz pokazuje, jak ramy są stosowane w praktycznym planowaniu spiralnym Federated Mission Networking (FMN).

Dlaczego wspólne ramy architektoniczne mają znaczenie dla koalicji

Bez wspólnego języka architektonicznego każdy naród opisuje swoje systemy na własny sposób. Jeden naród tworzy diagram PowerPoint; drugi tworzy model UML; trzeci tworzy dokument Word. Żaden z nich nie może być automatycznie porównywany z innymi, a luki interoperacyjności między nimi można znaleźć tylko ręcznie — powoli, kosztownie i niekompletnie. NAF 4.0 zapewnia wspólny język. Gdy wszystkie narody używają tych samych punktów widzenia, tego samego meta-modelu i tego samego słownictwa, ustrukturyzowane porównanie między architekturą narodu a architekturą docelową sojuszu staje się wykonalne. Luki pojawiają się jako brakujące elementy w modelu, a nie jako nieudokumentowane rozbieżności między dokumentami.

Ramy zapewniają też traceability. Standard techniczny w Technicznym Punkcie Widzenia powinien być traceble do serwisu w Serwisowym Punkcie Widzenia, który powinien być traceble do przepływu informacji w Operacyjnym Punkcie Widzenia, który powinien być traceble do wymogu zdolnościowego w Zdolnościowym Punkcie Widzenia, który powinien być traceble do celu strategicznego w Strategicznym Punkcie Widzenia. Gdy ten łańcuch istnieje, każdy interesariusz może zapytać "dlaczego potrzebujemy tej konkretnej wersji TLS?" i podążyć łańcuchem do koncepcji operacyjnej, która jej wymaga. Gdy nie istnieje, systemy gromadzą dług techniczny, którego nikt nie może uzasadnić usunięcia.

Sześć punktów widzenia NAF 4.0

Strategiczny Punkt Widzenia (St)

Strategiczny Punkt Widzenia przechwytuje polityczny i strategiczny kontekst, w którym operuje architektura. W użyciu sojuszniczym oznacza to koncepcję strategiczną NATO, konkretny mandat misji, zobowiązania narodów uczestniczących i krajowe zastrzeżenia ograniczające to, co siły każdego narodu mogą robić. Widoki St wyrażają, jakie wyniki musi dostarczyć koalicja i pod jakimi ograniczeniami politycznymi. Każda zdolność zdefiniowana w kolejnych punktach widzenia musi być traceble do wymogu strategicznego — element architektoniczny, którego nie można powiązać z Strategicznym Punktem Widzenia, nie ma w architekturze racji bytu.

W praktyce Strategiczny Punkt Widzenia jest najtrudniejszy do dokładnego wyprodukowania, bo wymaga bezpośredniego zaangażowania interesariuszy polityczno-wojskowych, którzy zazwyczaj nie myślą w kategoriach modelowania architektonicznego. Architekci, którzy pomijają ten krok i przechodzą bezpośrednio do widoków operacyjnych lub systemowych, produkują technicznie spójne architektury, które mogą odpowiadać na błędne pytania operacyjne.

Zdolnościowy Punkt Widzenia (C)

Zdolnościowy Punkt Widzenia definiuje, co siła musi być w stanie zrobić, ustrukturyzowane jako taksonomia zdolności z zależnościami między nimi i fazowaniem czasowym przez horyzont planowania. Zdolność w rozumieniu NAF to umiejętność osiągnięcia pożądanego efektu — niezależnie od sposobu implementacji. "Udostępnianie rozpoznanego obrazu powietrznego między węzłami C2 koalicji w czasie zbliżonym do rzeczywistego" to zdolność; "uruchomienie bramki Link 16 JREAP-C" to potencjalne rozwiązanie. Utrzymanie Zdolnościowego Punktu Widzenia agnostycznym wobec rozwiązań jest ważne: zachowuje swobodę zaspokojenia zdolności różnymi implementacjami w różnych narodach, przy zachowaniu interoperacyjności na granicy serwisu.

W planowaniu spiralnym FMN Zdolnościowy Punkt Widzenia to miejsce, gdzie definiowany jest zakres każdej spirali. Spirala 4 FMN dodaje zdolności wykraczające poza Spiralę 3, a te przyrostowe zdolności są wyrażane w Zdolnościowym Punkcie Widzenia przed podjęciem jakichkolwiek decyzji systemowych lub serwisowych. Narody używają tego samego punktu widzenia do deklarowania, które zdolności FMN zobowiązują się wdrożyć i w jakim horyzoncie czasowym — tworząc macierz zgodności, którą śledzi zarządzanie FMN.

Operacyjny Punkt Widzenia (Op)

Operacyjny Punkt Widzenia to most między tym, co siła musi robić, a systemami, które pozwalają jej to robić. Opisuje koncepcję operacyjną: zaangażowane role (dowódca, oficer łącznikowy, operator sensora), działania, które wykonują, informacje, które wymieniają, żeby je wykonać, i wymogi informacyjne, które te wymiany generują. Operacyjny Punkt Widzenia NAF 4.0 produkuje diagramy takie jak Model Działalności Operacyjnej (Op-A) i Model Informacyjny (Op-Iv), które razem pokazują, jakie informacje przepływają między kim i w jakich warunkach.

Dla projektowania interoperacyjności Operacyjny Punkt Widzenia to miejsce, gdzie przepływy informacji koalicji są ujawniane. Wymiana informacji między krajowym systemem C2 a sojuszniczym systemem sensorowym staje się zdefiniowanym węzłem w modelu Op, ze zdefiniowanym typem informacji i zdefiniowanym wymogiem terminowości. Ta definicja następnie napędza wybory serwisowe i techniczne w punktach widzenia poniżej. Problem interoperacyjności nieprzedstawiony w Operacyjnym Punkcie Widzenia nie może być systematycznie rozwiązany w Systemowym lub Serwisowym punkcie widzenia.

Systemowy Punkt Widzenia (Sy)

Systemowy Punkt Widzenia opisuje fizyczne i logiczne systemy realizujące koncepcję operacyjną. Pokazuje funkcje systemów, interfejsy systemów, przepływy danych między systemami i fizyczne platformy, na których systemy są rozmieszczone. To najznakomitszy punkt widzenia dla inżynierów i integratorów systemów — odpowiada ogólnie widokom na poziomie systemu w DODAF (SV-1 do SV-10) i domenie architektury systemów w ogólnej praktyce.

W architekturze koalicyjnej Systemowy Punkt Widzenia musi reprezentować zarówno wspólną infrastrukturę sojuszu (jak Usługi Podstawowe FMN), jak i krajowe systemy każdego narodu łączące się z nią. Specyfikacje interfejsów na granicy między systemami krajowymi a infrastrukturą sojuszu to kluczowe wyniki tego punktu widzenia — muszą być wystarczająco precyzyjne, żeby napisać test zgodności.

Serwisowy Punkt Widzenia (Sv)

Serwisowy Punkt Widzenia specyfikuje serwisy w sensie architektury zorientowanej na serwisy (SOA) lub API: dobrze zdefiniowane jednostki funkcjonalne z opublikowanymi interfejsami, które systemy eksponują do konsumpcji przez inne systemy. Ten punkt widzenia był znacząco wzmocniony w NAF 4.0 względem wcześniejszych wersji, odzwierciedlając przejście w architekturze interoperacyjności koalicyjnej od punkt-do-punktu integracji systemów w kierunku serwisowej federacji.

W FMN Serwisowy Punkt Widzenia jest centralny. Architektura FMN definiuje portfolio serwisów Federated Mission Networking — głos, wiadomości błyskawiczne, udostępnianie plików, wymiana COP, katalog, zarządzanie tożsamością — ze specyfikowanymi interfejsami i zachowaniami. Każdy serwis w katalogu FMN ma wpis w Serwisowym Punkcie Widzenia, który narody mogą implementować niezależnie, wiedząc, że zgodne implementacje będą interoperacyjne. To architektonicznie podobne do sposobu działania warstwy aplikacyjnej internetu: niezależne implementacje wspólnej specyfikacji produkują interoperacyjne serwisy.

Techniczny Punkt Widzenia (Tr)

Techniczny Punkt Widzenia wymienia standardy, profile techniczne i ograniczenia, którym muszą być zgodne systemy i serwisy. To normatywna warstwa referencyjna: system pojawiający się w Systemowym Punkcie Widzenia musi być zgodny ze standardami wymienionymi dla niego w Technicznym Punkcie Widzenia. W FMN Techniczny Punkt Widzenia zawiera konkretne odniesienia STANAG, wersje protokołów, wymogi zestawów szyfrów i specyfikacje interfejsów realizujące serwisy każdej spirali.

Techniczny Punkt Widzenia to miejsce, gdzie architektura NAF 4.0 bezpośrednio przecina się z zamówieniami publicznymi. Specyfikacja zamówienia dla krajowego systemu, który połączy się z FMN, powinna móc wyodrębnić swoje wymogi techniczne bezpośrednio z Technicznego Punktu Widzenia — a wynikowy system powinien przejść testowanie zgodności z tymi samymi wymogami. Gdy ten łańcuch trzyma, dokument architektoniczny jest żywą specyfikacją; gdy się zrywa, architektura staje się historycznym artefaktem, który nie ma związku z tym, co faktycznie zamówiono.

NAF kontra DODAF kontra TOGAF

NAF 4.0 i DODAF 2.02 to bliskie kuzynowie, nie konkurenci. Mają wspólne korzenie, a ich widoki można mapować wzajemnie na poziomie konceptualnym. Główna różnica to zarządzanie: DODAF to krajowy standard USA DoD; NAF to standard sojuszniczy wiążący narody NATO i narody partnerskie adoptujące go. Organizacje USA pracujące na programach NATO zazwyczaj produkują architektury spełniające oba ramy jednocześnie, ponieważ struktury widoków są wystarczająco kompatybilne, żeby jeden model mógł generować zgodne produkty w obu. Gdzie się rozchodzą, to w szczegółach meta-modelu: NAF 4.0 jest budowany na MODEM, który jest formalnie bardziej specyfikowany niż bazowy meta-model DM2 DODAF w niektórych obszarach.

TOGAF zajmuje całkowicie inną domenę. The Open Group Architecture Framework to metoda architektury IT przedsiębiorstwa zbudowana wokół Metody Opracowania Architektury (ADM), która strukturyzuje pracę architektoniczną jako serię iteracyjnych faz skupionych na dostarczaniu zmiany biznesowej wspieranej przez IT. TOGAF nie ma inherentnego modelu koncepcji operacyjnych, misji wojskowych ani taksonomii zdolności — jest zorientowany na dostarczanie usług IT, zarządzanie portfolio aplikacji i zarządzanie zmianami organizacyjnymi. Organizacje obronne niekiedy używają TOGAF w ramach wewnętrznych programów zakupu IT, uruchamiając go obok NAF zamiast zamiast niego. Oba ramy służą różnym interesariuszom: NAF odpowiada na pytanie, jak siły koalicji będą razem operować; TOGAF odpowiada na pytanie, jak organizacja będzie zarządzać swoim IT, żeby wspierać swoje procesy biznesowe.

NAF w planowaniu spiralnym FMN

Program Federated Mission Networking używa NAF jako języka architektury przez cały cykl planowania spiralnego. Każda spirala FMN jest definiowana przez architekturę docelową wyrażoną w widokach NAF, a zgodność krajowa jest mierzona wobec tej docelowej. Proces przebiega następująco. Po pierwsze, Ramy Zdolnościowe FMN identyfikują przyrosty zdolnościowe, które spirala musi dostarczyć — wynik Zdolnościowego Punktu Widzenia. Po drugie, Grupa Robocza Architektury FMN produkuje widoki operacyjne opisujące, jak te zdolności będą ćwiczone w praktyce. Po trzecie, specyfikacje serwisów są pisane dla każdego serwisu w katalogu spirali — produkty Serwisowego Punktu Widzenia. Po czwarte, profile techniczne są identyfikowane dla każdego serwisu — produkty Technicznego Punktu Widzenia. Po piąte, narody oceniają własne architektury wobec celu FMN, identyfikując luki między istniejącymi systemami a wymaganymi serwisami.

Narody, które zainwestowały w narzędzia i dyscyplinę NAF, mogą wykonywać tę analizę luk półautomatycznie: porównać wpisy Technicznego Punktu Widzenia narodu z wymogami FMN Technicznego Punktu Widzenia i wygenerować ustrukturyzowaną listę niezgodności. Narody bez dojrzałej krajowej praktyki architektonicznej wykonują tę samą analizę ręcznie, co jest wolniejsze i bardziej podatne na błędy, ale produkuje tę samą kategorię wyników. Lista luk staje się wkładem do krajowego planu opracowania zdolności — mapy drogowej zamówień, modernizacji i konfiguracji, które doprowadzą naród do zgodności FMN dla spirali. Więcej szczegółów na temat tego, czego konkretnie wymaga FMN Spirala 4, zawiera nasza analiza wymogów FMN Spirali 4.

CWIX — Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise — to doroczne wydarzenie, gdzie zgodność FMN jest testowana w praktyce, a nie na papierze. Związek między architekturą NAF a testowaniem CWIX jest bezpośredni: przypadki testowe przeprowadzane na CWIX powinny wynikać ze specyfikacji interfejsów w Serwisowym i Technicznym Punkcie Widzenia NAF. Architektura nieprojektowana z myślą o testowalności — z jasnymi definicjami interfejsów, które można bezpośrednio przetłumaczyć na przypadki testowe — przyniesie niejednoznaczne wyniki CWIX trudne do usunięcia. Nasza analiza mapy drogowej spirali FMN obejmuje sposób, w jaki kolejne spirale budują na sobie i jak wygląda przyszła trajektoria opracowania zdolności FMN.