NATO Architecture Framework

Technik i obszarów, które możemy modelować jest bardzo wiele. Ponadto powstało wiele szablonów, ram, frameworków, które mówią co i jak trzeba modelować. Dokładając do tego mnogość notacji i diagramów otrzymujemy kociołek z całą masą możliwości. Tylko czy taka możliwość wyboru jest dobra?

I tak, i nie. Z jednej strony fajnie, że mamy wybór, ale z drugiej musimy przeanalizować wiele wariantów, wiele możliwości. To zajmuje czas i często paraliżuje. Pisze o tym dlatego, że czytając notację UML widzę kilkanaście diagramów, Notacja ArchiMate to kolejne perspektywy, które dość często dublują punkt widzenia i zakres prezentowanych informacji, które znajdziemy w UML. W tym poście będę chciał pokazać duży NATO Architecture Framework (NAF), który obfituje w wiele propozycji widoków. Jako widok, albo diagram, albo perspektywę, rozumiem rysunek, przedstawiający w sposób uproszczony fragment rzeczywistości. Z NATO Architecture Framework „wyciągnę” kilka użytecznych w danym momencie diagramów. Stosowanie wszystkich jest mało sensowne.

Jako że NATO Architecture Framework jest kojarzony przede wszystkim ze światem militarnym, a bankomaty, i sklepy internetowe zostały już opisane dokładnie :-), to opiszę punkt kontrolny, w którym to żołnierze sprawdzają pojazdy i osoby. Tu małe zastrzeżenie. Opisany przykład ma charakter szkoleniowy i mogę rozmijać się trochę z rzeczywistością. Proszę o wybaczenie nieścisłości :-).

NATO Architecture Framework – wstęp

NATO Architecture Framework (https://www.nato.int/cps/en/natohq/topics_157575.htm) to dokument, którego celem jest opracowywanie i opisywanie architektur do celów wojskowych i biznesowych. NAF definiuje szereg perspektyw, które mają za zadanie ujednolicić sposób prezentacji architektury interesariuszom. NATO Architecture Framework wskazuje wytyczne, zasady i opisy produktów architekta a tym samym poprzez taką standaryzację umożliwia porównanie wielu architektur i ich ewentualną integrację. NATO Architecture Framework odnosi się do architektur opracowanych przez międzynarodowe organy normalizacyjne International Standards Organization (ISO), Institute of Electrical and Electronic Engineers (IEEE), The Open Group (TOG), Object Management Group (OMG) itp.

Z powyższego opisu wynika, że otrzymuje gotowy standard pracy. Niestety jak nie jest tak kolorowo, gdyż NATO Architecture Framework oferuje aż 46 widoków.

Nato Architecture Framework Widoki
NATO Architecture Framework (źródło: NAV4 v. 2019.10)

NATO Architecture Framework zbudowany jest na siatce, gdzie w liniach poziomych są zdefiniowane warstwy od koncepcji (zielone) do fizycznej struktury (pomarańczowe). Na samym dole znajduje się warstwa opisująca metadane. Natomiast w pionie mamy taksonomie, strukturę, połączenia, procesy, stany sekwencje ograniczenia i na samym końcu plan rozwoju. Każdy z widoków został opisany w następujący sposób:

  • nazwa i opis punktu widzenia oraz oznaczenie obowiązkowe i opcjonalne informacje, które mają być dostarczone przez widok,
  • opis celu widoku, w tym wskazanie, jakiego efektu spodziewamy się po diagramie
  • przeznaczenie – wskazanie interesariuszy lub sytuacji, gdy ten widok będzie miał zastosowanie
  • przykłady wykorzystania wykorzystanie widoku w innych pracach
  • reprezentacja – zawierająca przykładowe rodzaje modeli, które można wykorzystać do przedstawienia widoków
  • przykład – ilustrujący dany widok
Nato Architecture Framework Opis Prespektywy
NATO Architecture Framework – P2 Resource Structure (źródło: NAV4 v. 2019.10)

NATO Architecture Framework w przykładowych technikach, które można wykorzystywać, wskazuje UML (z dużą ilością stereotypów), SysML, a także połączone obrazki (connected shapes). Jednocześnie na wskazanej perspektywie (P2 Resource Structure) można opisać fizyczną architekturę, integrację systemów, specyfikację wymagań na system. Podobna sytuacja ma miejsce w niemal każdym widoku. Innymi słowy, pojęcie widoku w NATO Architecture Framework oznacza dość pojemny byt, w którym zgodnie ze zdefiniowanym zakresem można umieścić bardzo wiele informacji. W moim odczuciu zastosowana notacja również może być dobra adekwatnie do potrzeb.

W moim sposobie modelowania świata do opisywania bytów na wyższym poziomie abstrakcji używam notacji ArchiMate a do opisywania detali korzystam z BPMN lub UML. Podobne podejście zastosowałem i przy przygotowaniu poniższego przykładu. Z bogactwa widoków NATO Architecture Framework, do opisu patrolu i punktu kontrolnego wybrałem:

  • C1 – Capability Taxonomy
  • C4 – Standard Processes
  • C7 – Performance Parameters
  • Cr – Capability Roadmap
  • S1 – Service Taxonomy
  • S5 – Service States
  • S6 – Service Interactions
  • C1-S1 – Capability to Service Mapping
  • L1 – Node Types
  • L7 – Logical Data Model
  • P1 – Resource Types
  • P2 – Resource Structure
  • A2 – Architecture Products

NATO Architecture Framework – przykładowe widoki

C1 – Capability Taxonomy – Taksonomia zdolności

Taksonomia zdolności dotyczy identyfikacji zdolność i zależności między nimi. W moim rozumieniu zdolność to możliwość realizowania określonych działań posiadana przez osobę, organizację lub system (https://wolski.pro/archimate-3-0/elementy-strategii/#zdolnosc). W ujęciu militarnym taka zdolność może dotyczyć kontroli nad danym obszarem lub obrony przeciwlotniczej. Warto jest zauważyć, że zdolności mogą budować hierarchie przez co kilka mniejszych zdolności budują większą.

Nato Architecture Framework C1 Capability Taxonomy Taksonomia Zdolnosci
C1 – Capability Taxonomy – taksonomia zdolności

C4 – Standard Processes – Procesy

Punkt widzenia dotyczy identyfikacji standardowych działań. To procesy biznesowe najwyższego poziomu abstrakcji. W tym przypadku mamy „Przeprowadzenie patrolu pieszego” i „Kontrolę osób i pojazdów”. Te dwa procesy składają się na ten widok. Ponadto dodałem 3 elementy z widoku L4 – Logical Activities, który odpowiada za detaliczny opis procesu.

Nato Architecture Framework C4 Standard Processes Procesy
C4 – Standard Processes – Procesy, L4-Logical Activities – aktywności

Koncepcja ta wpisuje się idealnie mechanizm połączenia warstw pomiędzy procesami, który opisałem w tekście Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania.

C7 – Performance Parametrers – Parametry wydajności (jakości)

Celem tego widoku jest identyfikacja i opisu miar, wskaźników, które pozwolą nam na zdefiniowanie, na jakim poziomie jest opisywana zdolność. W tym przypadku miarą są poziomy wyszkolenia. W tym miejscu należy zauważyć, że określanie parametrów jakości jest oddzielnym złożonym przedsięwzięciem.

Nato Architecture Framework C7 Performance Parametrers Parametry Zdolnosci
C7 – Performance Parametrers – Parametry wydajności

Cr – Capabilty Rodmap – Mapa rozwoju zdolności

Mapa rozwoju zdolności to widok, który daje możliwość pokazania jak w czasie będziemy rozwijać nasze zdolności. Podobny widok można zastsować na wszystkich poziomach NATO Architecture Framework

Nato Architecture Framework Cr Capabilty Rodmap Mapa Rozwoju Zdolnosci
Cr Capabilty Rodmap – Mapa rozwoju zdolności

S1 – Service Taxonomy – Taksonomia usług

Widok ten pozwala pokazać zidentyfikowane usługi. Na tym poziomie opisu, wydaje się, ze warto jest modelować usługi biznesowe. Usługa biznesowa reprezentuje jednoznacznie zdefiniowane zachowanie biznesowe. Tak usługę definiuje notacja Archimate (https://wolski.pro/archimate-3-0/warstwa-biznesu/#usluga_biznesowa). Upraszczając usługa to jest to co jest widoczne na zewnętrz organizacji i z czego możemy skorzystać.

Nato Architecture Framework S1 Service Taxonomy Taksonomia Usług
S1 – Service Taxonomy – Taksonomia usług

Na powyższym rysunku zidentyfikowane zdefiniowałem kilka usług. Usługi te realizowane są przez proces biznesowy (C4 Standard Processes). Osoba z zewnątrz będzie widziała kontrolę pojazdów lub zatrzymanie osoby. To usługi, które żartobliwie ujmując temat, wojsko może sprzedawać na wolnym rynku. Posiadając katalog usług możemy nie tylko komponować bardziej złożone usługi, ale także budować zdolności.

C1-S1 – Capability to Service Mapping – Mapowanie usług do zdolności

Mapowanie usług do zdolności to właśnie widok, który umożliwi wskazanie jakie usługi, jakie kompetencje musi mieć firma, by zbudować odpowiedni potencjał-zdolności.

Nato Architecture Framework C1 S1 Capability To Service Mapping Mapowanie Uslug Do Zdolnosci
C1-S1 – Capability to Service Mapping – Mapowanie usług do zdolności

Ten widok wraz z widokiem P2 – Resource Structure opisują zasoby potrzebne do posiadania danej zdolności.

S5 – Service States – Stany usługi

Widok S5 pozwala na identyfikację możliwych stanów usługi. Na tym widoku za można pokazać również przejścia pomiędzy stanami. Tak zdefiniowany opis jednoznacznie wskazuje na możliwość wykorzystania diagramu maszyny stanowej. Takie podejście bardzo ładnie wkomponowuje się w podejście wysoki poziom abstrakcji ArchiMate a niski to UML i BPMN. Poniżej przykładowy diagram maszyny stanowej dla usługi: kontrola pojazdu

Nato Architecture Framework S5 Service States Stany Usługi
S5 – Service States – Stany usługi

S6 – Service Interactions – Integracja usług

Widok integracji usług pomaga opisywać interakcję usługi z osobami, które je wykonują lub z nich korzystają. Widok ten to nic innego jak diagram sekwencji, który identyfikuje interakcje konsumentów usług z usługą, oraz może pokazywać sekwencje uruchomienia poszczególnych usług.

Nato Architecture Framework S6 Service Interactions Integracja Usług
S6 – Service Interactions – Integracja usług

Powyższy diagram prezentuje interakcję usług w czasie kontroli pojazdu i osób. W mojej ocenie lepszy byłby tu diagram BPMN. Zamieszczam ten diagram tylko dla celów szkoleniowych 🙂

L1 – Node Types – Typy węzłów

Widok L1 ma za zadanie pokazać byty logiczne opisywanej organizacji. Byty logiczne w NATO Architecture Framework nazwane są węzłami. Tymi węzłami mogą być sprzęt, ludzie, miejsca. Wszystko to,co może wejść w interakcję z usługami.

Nato Architecture Framework L1 Node Types Typy Wezlow
L1 – Node Types – Typy węzłów

W tym przypadku ograniczałem katalog węzłów do osób, których hierarchię opisałem za pomocą relacji specjalizacji. I tak są to:

  • kontrolujący – żołnierz, który przeprowadza kontolę
  • ubezpieczający kontolującego – żołnierz, który stoi trochę dalej i bezpośrednio ubezpiecza kontrolujęcego
  • ubezpieczający kontrolę – żołnierz lub żołnierze, którzy zabezpieczają kontrolującą wcześniej opisaną dwójkę żołnierzy

L7 – Logical Data Model – Logiczny model danych

W NATO Architeture Framework nie zabrakło miejsca na model logiczny, którego celem jest identyfikacja elementów informacyjnych i opisanie relacji między nimi. W omawianym przypadku opisałem fragment takiego modelu dla żołnierza. Użyłem diagramu ERD.

Nato Architecture Framework L7 Logical Data Model Logiczny Model Danych
L7 – Logical Data Model – Logiczny model danych

P1 – Resource Types – Typy zasobów

Typy zasobów to widok do wskazania już aspektów technologicznych i fizycznych. To bardzo podobny widok do wskazanego wcześniej L1 – Node Types. Granica pomiędzy węzłami a zasobami jest tak, że węzły to elementy niezależne od środowiska implementacji a zasoby wskazują już na implementacje.

Nato Architecture Framework P1 Resource Types Typy Zasobww
P1 – Resource Types – Typy zasobów

I po takim stwierdzeniu zaczyna być bardzo ciekawie. W moim odczuciu takie elementy jak „Zespół kontroli” jak i „System komunikacji” mogą być traktowane jako węzeł, ale również jako zasób. Takie rozważania, należy przeprowadzić w organizacji i jednoznacznie stwierdzić, że przykładowo oprogramowanie i żelastwo (np.: broń, routery, serwery, a także pojazdy) to zasoby natomiast reszta to węzły. Podział może być zupełnie inny. Warto jednak takie rozważania poczynić by modele były jednorodne.

P2 – Resource Structure – Struktura zasobów

Struktura zasobów to widok, którego zadaniem jest wskazanie zależności pomiędzy zasobami. Rysunek taki uzupełniłem o elementy o węzły z widoku L1 – Node Types – Typy węzłów. Dzięki takiemu zabiegowi widzę, że zdolność obsługi posterunku kontrolnego wymaga dwóch zespołów, systemu komunikacji i odpowiednio przedszkolnych żołnierzy.

Nato Architecture Framework P2 Resource Structure Struktura Zasobow
P2 – Resource Structure – Struktura zasobów

A2 – Architecture Products – Produkty architektury

Warstwa z poziomu A to opisy metadanych. Perspektywa produktów architektury ma za zadanie pokazać składowe elementy architektury danej organizacji. W tym przypadku to kilka pakietów, w których umieściłem prezentowane powyżej artefakty.

Nato Architecture Framework A2 Architecture Products Produkty Architektury
A2 – Architecture Products – Produkty architektury

NATO Architecture Framework – podsumowanie

Wskazane powyżej widoki są przykładowe. Celowo nie modelowałem bardziej szczegółowo modeli opisujących system. Widoki takie jak P4 Resource Functions, P5 Resource States, P6 Resource Sequence, P7 Physical Data Model to nic innego jak projekt rozwiązania w notacji UML lub SysML albo inny rodzaj dokumentacji adekwatny dla typu zasobu.

Dobrze skonstruowane widoki pozwalają wspomóc proces podejmowania decyzji. Tworząc architekturę warto tak komponować widoki, by pozwalały śledzić zależności pomiędzy elementami. W tym przypadku widok ten obejmuje zaprezentowane wcześniej perspektywy.

Nato Architecture Framework A2 Widok Calosci
Widok wspólny

Podsumowując. Posiadanie wielu możliwości jest dobre, ale z mnogości opcji wybrać należy to co jest dla nas użyteczne. Kilka technik. Dokładnie tak zrobiłem w powyższym przykładzie. Innymi słowy warto jest narysować kilka przykładów, pogadać z ludźmi w firmie i sprawdzić co pomaga zrozumieć złożoność problemu a co zajmuje tylko czas na rysowanie. Wszelakie frameworki to tylko zestaw propozycji, które się sprawdzają, ale nie gdy są stosowane wszystkie oferowane przez nie możliwości. Frameworki sprawdzają się wtedy gdy są stosowane intencjonalnie. Mniej znaczy więcej.

Trafnie wybranych technik życzę 🙂

Podobne wpisy

  • ArchiMate w praktyce ArchiMate® jest otwartym i niezależnym językiem do modelowania architektury korporacyjnej. Jego głównym celem jest dostarczenie architektom korporacyjnym narzędzia pozwalającego w […]
  • Moje ulubione perspektywy w architekturze korporacyjnej Na moich stronach przedstawiłem szereg perspektyw Archimate (https://wolski.pro/archimate-2-0/perspektywy/). Użycie ich wszystkich w danej organizacji jest oczywistym nieporozumieniem. […]
  • Architekt w podejściu zwinnym W ostatnim wpisie opisałem co myślę o roli analityka w podejściu zwinnym. Drugą rolą, o której chciałbym wspomnieć jest rola architekta. Rola ta określona jest w klasycznym podejściu do […]
  • Impact mapping (mapowanie wpływu) W swojej praktyce wielokrotnie spotykałem się z sytuacją, w której wprowadzana zmiana była realizowana zgodnie z maksymą Króla Juliana "Teraz prędko, zanim dotrze do nas, że to bez […]
  • Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania Modelowanie procesów biznesowych jest dziś stosunkowo powszechne. W wielu organizacjach robi się to nawet w dwóch miejscach :-). W komórce odpowiedzialnej za usprawnianie lub nadzór nad […]
Reklama
MODESTO - licencje Enterprise Architect

4 komentarze dla “NATO Architecture Framework”

  1. To jest chyba pierwszy tak obszerny polski wpis dotyczący NAF, gratuluję! Uczestniczyłem w pracach grupy roboczej przy NATO nad metodyką dla wersji 4. W Polsce temat jest mało znany, ja przynajmniej znam dwa ośrodki (firmy) gdzie są jakieś kompetencje w tej dziedzinie. Temat jest bardzo obszerny i ciekawy. W NATO i w kilku europejskich firmach zbrojeniowych nawet został wdrożony. Jednak pionierem są tutaj Stany z DODAF, nieźle jest również w UK z MODAF. NAFv4 jest złożeniem MODAF i NAFv3. Są prace aby wszystkie te frameworki zawrzeć w UAF pod pieczą OMG
    (https://www.omg.org/uaf/index.htm). Prace nad unifikacją są prowadzone między innymi z powodu zainteresowania rynku komercyjnego tym frameworkiem.

  2. Dzięki za komentarz i dobre słowo 🙂 Istotnie prace zmierzają w stronę Unified Architecture Framework (UAF). Nie umiem powiedzieć czy biznes będzie zainteresowany, bo obecnie modne są zwinne działania. Czas pokaże :-).

  3. DODAF i MODAF sa obecne na rynku od pewnego czasu, UAF to w zasadzie uogólniony profil, który (jak samo OMG deklaruje) nastawiony jest na reużycie UML i SysML. Osobiście jestem sceptykiem z powodu, który wskazałeś Michał, ale jest nim w moich oczach nie tyle zwinność jako taka, a to, że widać na rynku trendy do ograniczania objętości dokumentacji (kto to będzie czytał i kiedy). W dużych korporacjach widzę narastający opór przed megaprojektami analitycznymi, gdyż już po kwartale pracy zaczyna się aktualizacja tego co zdążyło powstać. osobiście jestem zwolennikiem analizy projektowania zorientowanego na architekturę i polityki jej implementacji. To metoda znana z megaprojektów budowlanych: nikt nie zaczyna budowy od opracowania detalicznego projektu, powstaje szkielet i strategia jego uszczegóławiania. Kilka lat temu był fajny artykuł chyba na Modernanalyst: liczy się cykl życia produktu a nie szczegółowe wymagania. Ostateczna dokumentacja jest znana po zakończeniu (nadzoru autorskiego).

    Prawdopodobnie UAF będzie tak własnie używany: nie do projektowania przed wdrożeniem a to bieżącego dokumentowania wdrożenia.

  4. Zgadzam się z Tobą, że świat długiej analizy z detalami, a potem budowania już raczej nie wróci. Postrzegam frameworki jako zestaw technik, który pozwolą zaprojektować dany fragment rozwiązania tuż przed implementacją. Iteracyjne, adekwatne do potrzeb budowanie architektury to najlepsze rozwiązanie. Obecnie obserwuję problem z zastosowaniem 2-4 diagramów w projektach. Wybór z 40-60 technik może być trudny. Z drugiej strony nie chciałbym, aby ktoś, widząc 46 widoków NATO Architecture Framework stosował je wszystkie. Myślę, że czeka nas zmiana postrzegania architektury w projektach.

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry