Architektura korporacyjna: modelowanie w ArchiMate za pomocą Archi

Artykuł omawia wykorzystanie ArchiMate, języka modelowania architektury korporacyjnej, ze szczególnym uwzględnieniem narzędzia Archi. ArchiMate zapewnia ustrukturyzowane podejście do modelowania złożonych systemów IT, oferując różne warstwy, takie jak motywacja, strategia, biznes i technologia. Autor wyjaśnia, w jaki sposób Archi ułatwia wizualizację architektury korporacyjnej, dzięki czemu łatwiej nią zarządzać i ją zrozumieć. Ponadto artykuł porusza praktyczne kwestie, takie jak konfiguracja repozytorium Git do pracy zespołowej oraz efektywne zarządzanie zmianami w modelu. Praktyczny przykładowy projekt pokazuje zastosowanie tych koncepcji w rzeczywistym scenariuszu.

W złożonym świecie artefaktów IT warto wprowadzić ustandaryzowany i dobrze zbudowany model opisu najważniejszych rzeczy. Z pewnością pomoże to uporządkować informacje i śledzić zmiany. W świecie profesjonalnym ważne jest, aby opisywać rzeczy w profesjonalny sposób. Mamy więc architekturę korporacyjną (Enterprise Architecture), którą można zdefiniować jako

„koncepcyjny plan, który definiuje strukturę i sposób działania organizacji. Celem architektury korporacyjnej jest określenie, w jaki sposób organizacja może skutecznie osiągać swoje obecne i przyszłe cele”

https://www.techtarget.com/searchcio/definition/enterprise-architecture

Możesz sobie wyobrazić, co by się stało, gdyby jakaś organizacja nie praktykowała architektury korporacyjnej, ale ja posunąłbym się nieco dalej i zapytał, co by się stało, gdyby organizacja coś modelowała, ale w sposób nieustrukturyzowany, nie korzystając z dobrodziejstw formalnego frameworku. Łatwo mógłbyś skończyć z bałaganem i chaosem informacyjnym, który negatywnie wpłynie na Twój biznes, technologię i operacje.

Język ArchiMate #

Choć mówi się, że ArchiMate to język, ja twierdzę, że to coś więcej niż język, ponieważ ma cechy frameworku. Udostępnia nam kilka warstw modelowania, takich jak motywacja, strategia, biznes, aplikacja, technologia oraz implementacja i migracja. Każda warstwa składa się z kilku elementów, które można następnie podzielić na 3 grupy: aktywne, behawioralne i pasywne. W rezultacie otrzymujesz macierzową strukturę pogrupowanych elementów, które można wykorzystywać w postaci diagramów zwanych widokami ArchiMate.

Podsumowując: to język z bonusami. Składa się z mniej więcej 6 koncepcji (warstw), które dzielą się dalej na 3 grupy różnych elementów. Wszystko można umieścić na diagramach i widokach.

Dostępne narzędzia do modelowania #

Jest kilka narzędzi, które poleciłbym, jeśli chodzi o architekturę korporacyjną, a zwłaszcza ArchiMate. Powiedziałbym, że Sparx Enterprise Architect jest najbardziej kompletny, ale wymaga pewnych niewielkich nakładów finansowych. Drugim jest Archi, narzędzie open source. Oba narzędzia wspierają pracę zespołową. Sparx EA za pomocą Pro Cloud Server, a Archi przy użyciu wtyczki coArchi z repozytorium Git. Przy większych projektach, w których nad modelem pracuje wiele osób i dużo się dzieje, EA na pewno sprawdzi się lepiej, ale w projektach realizowanych w pojedynkę Archi powinno dać radę.

Konfiguracja repozytorium #

Dla osób pracujących z różnych miejsc i w środowisku zespołowym posiadanie repozytorium będzie ogromną korzyścią. Nie jest to tak elastyczne i dynamiczne jak na przykład Miro, ale architektura korporacyjna jest raczej czymś statycznym niż sesją burzy mózgów. Zacznij więc od założenia repozytorium Git. Ja preferuję GitLab. W razie potrzeby utwórz grupę i pusty projekt. Na razie to wszystko.

Instalacja Archi #

Wejdź na https://www.archimatetool.com/download/ i pobierz najnowszą wersję Archi. Jest dostępna dla systemów Linux, Windows i Mac. Po pobraniu instalujesz program lub po prostu rozpakowujesz archiwum. Następnie wejdź na https://www.archimatetool.com/plugins/ i pobierz wtyczkę coArchi, ponieważ jest ona potrzebna do włączenia funkcji współpracy z użyciem repozytorium Git. Wtyczki można zainstalować z poziomu Archi, wybierając Help – Manage Plug-ins. Teraz wystarczy ponownie uruchomić Archi, aby włączyć wtyczkę do współpracy.

Zarządzanie modelem #

Istnieją dwa scenariusze zarządzania modelami. Albo zaczynasz własny model lokalnie, a następnie publikujesz go zdalnie, albo importujesz czyjś model do swojego pustego projektu. Myślę, że to obejmuje większość przypadków użycia. W pierwszym przypadku tworzysz pusty model, a następnie wybierasz Collaboration – Add local model to workspace and publish. W drugim przypadku wybierasz Collaboration – Import remote model to workspace. Jeśli nie utworzysz własnego projektu, Archi utworzy w model-repository/project/.git tak zwany plik tymczasowy dla Twojego projektu. Jeśli utworzyłeś projekt lokalnie, możesz go po prostu otworzyć w ten sposób.

Zmiany z użyciem Git SCM #

Praca zespołowa wymaga podstawowej znajomości Git SCM, ponieważ na początku należy pobrać zmiany z serwera (Collaboration – refresh model). Po zakończeniu wprowadzania zmian wykonaj Commit changes, a na koniec Publish changes. Jak w przypadku każdego innego repozytorium Git możesz przełączać się między gałęziami, scalać zmiany, poprawiać commity (amend) itd.

Przykładowy projekt #

Aby wizualnie zaprezentować ArchiMate, postanowiłem wybrać mój kolejny projekt/demo technologiczne jako podstawę tego modelu. Chodzi o NIS2 i jej wymagania dotyczące EDR, antywirusa, antyrootkita itp., które pokażę na setkach kontenerów w zautomatyzowanej formie z użyciem automatyzacji Ansible. Mamy więc różne warstwy dotyczące tego projektu: motywację oraz strategię, a schodząc niżej – biznes, aplikację, technologię i wreszcie implementację i motywację.

Zwróć uwagę, że kolory są tu istotne, ponieważ grupują koncepcje.

Motywacja #

Źródłem samego projektu jest unijny prawodawca, który określa szereg czynników (drivers) i wymagań NIS2, z których wynikają cele i rezultaty. Wszystkie one mogą być łatwo zmapowane na elementy strategii, takie jak kierunek działania (course of action), ale również na procesy biznesowe. Możesz szybko zejść na sam dół do plateau implementacji, opisującego stan architektury przed i po zmianach.

Strategia #

Różni odbiorcy potrzebują różnych punktów widzenia, dlatego każdy widok/diagram pozwala wybrać konkretny, interesujący punkt widzenia (viewpoint) dla danego diagramu. Dzięki temu elementy niepowiązane (bezpośrednio) są wyszarzone i wyraźnie widać tylko elementy wynikające bezpośrednio z danej koncepcji. Poziom strategii opisuje więc na wysokim poziomie, co możemy zrobić i za pomocą jakich środków. Pomagam sobie, dodając niewielki element w postaci wymagania z warstwy motywacji oraz procesu technologicznego. Na koniec mamy wymaganie „coverage”, które można zdefiniować jako rezultat tej strategii, ale w razie potrzeby mogłoby to być również wartość strumienia (value stream).

Biznes #

Warstwę biznesową zdefiniowaliśmy, aby określić, kto co robi – mamy więc Boba, inżyniera automatyzacji, który tworzy procesy automatyzacji. Umieściliśmy tu również elementy motywacji, elementy strategii, ale także elementy aplikacyjne, które nie są wyszarzone, ponieważ jest to punkt widzenia „business process cooperation” i zawiera on również elementy aplikacyjne, takie jak „clamav” i „rkhunter”, które odpowiednio implementują i realizują pokrycie antywirusowe i antyrootkitowe.

Aplikacja #

Bardzo dobrze jest móc, oprócz oczywistych komponentów aplikacji i ich funkcji, umieścić również informację, dlaczego to robimy. Ludzie często pytają, dlaczego robimy coś w technologii, więc taka konwencja mieszania elementów z różnych poziomów abstrakcji daje im na to odpowiedź.

Technologia #

W punkcie widzenia „technology usage” mogę wybrać zarówno elementy technologiczne, jak i aplikacyjne, a także dodać inne elementy, na przykład z warstwy motywacji. Pojawia się tu jedna nowa rzecz, czyli grupowanie, ale w sensie strukturalnym, a nie tylko wizualnym. Umieszczając elementy wewnątrz grupy, zostaniesz zapytany o relację między grupą a jej elementami, ponieważ zmniejsza to liczbę możliwości w zakresie dodatkowych relacji. Uważam, że warstwa technologii znajduje się logicznie na samym dole drzewa artefaktów, a umieszczona niżej warstwa implementacji i migracji w rzeczywistości tam nie jest.

Implementacja i migracja #

To najbardziej kompletny punkt widzenia, ponieważ zawiera elementy biznesowe, aplikacyjne, technologiczne, część elementów motywacji oraz elementy implementacyjne. Definiujesz tu więc, co, w jakiej formie, ewentualnie kto i jaki jest rezultat końcowy. To bardziej plan projektu. Śmiało dodawaj wszystko, czego potrzebujesz do opisania rzeczy, aby zaplanować zmiany oraz określić, do jakiej linii bazowej (baseline) się one odnoszą i czy zmienią ją na nową linię bazową.

Układ Archi z sekcją Hints #

Poniżej zrzut ekranu z Archi. Zwróć uwagę na sekcję „Hints”, dzięki której możesz dowiedzieć się więcej o specyfice różnych punktów widzenia, koncepcji i elementów, a także relacji między nimi.