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 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 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ą.
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.
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.
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
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ć.
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.
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
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.
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.
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.
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.
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.
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 – 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.
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ę 🙂
