ArchiMate – język modelowania architektury korporacyjnej – czy potrzebujemy kolejnego języka modelowania?
Czerwiec 13, 2010
W poprzednim artykule ([1]) przybliżyłem pojęcie architektury korporacyjnej. Jak napisałem, architektura korporacyjna służy precyzyjnemu opisowi przedsiębiorstwa widzianemu jako system. W przypadku modelowania aplikacji i systemów informatycznych, istnieją narzędzia i języki modelowania ogólnego przeznaczenia, jak choćby UML. Dla architektury korporacyjnej takich języków chociażby z uwagi na to, że jest to młoda dyscyplina nie było. Oczywiście język UML jest językiem ogólnym, który poprzez zastosowanie profili można uszczegółowić do zagadnień modelowania architektury korporacyjnej. Bez względu na to, z czego wyprowadzimy język opisu architektury korporacyjnej najważniejsze jest ujęcie zasad semantycznych i syntaktycznych. W tym artykule postaram się krótko przybliżyć język modelowania ArchiMate, który próbuje sprostać wyzwaniu bycia językiem opisu architektury korporacyjnej. Szczegółowy opis języka ArchiMate wykracza poza ramy tego artykułu. Zainteresowanych tematem odsyłam do [2]. Na początku jednak spróbuję odpowiedzieć na pytanie – Czy naprawdę potrzebujemy kolejnego języka modelowania w świecie zdominowanym przez UML, BPMN, ARIS, itp.?
Dlaczego potrzebujemy języka opisu architektury korporacyjnej?
Duże przedsiębiorstwa często zmagają się z brakiem wsparcia dla zarządzania architekturą w zakresie projektowania, komunikacji, realizacji, zmiany. Kiedy przyjrzymy się przedsiębiorstwu, które używa modeli do opisu architektury najczęściej spotkamy się z wieloma modelami opisującymi pewien obszar przedsiębiorstwa, np. procesy biznesowe, opisy przebiegu sterowania, modele danych warstwy aplikacji itd.. W takim modelowaniu brakuje jednak jednego: powiązania modeli z różnych obszarów i przełożenia ich na modele w innych obszarach pracy przedsiębiorstwa. Przykładowo, mając proces biznesowy bardzo trudno jest szybko wskazać aplikacje, oraz elementy infrastruktury (maszyny, elementy sieci, itd.), które wspierają realizację procesu biznesowego w zakresie aplikacji i systemów informatycznych.
Chcąc projektować architekturę na poziomie przedsiębiorstwa, tj. spójnie w różnych obszarach z kontrolą powiązań między tymi obszarami, konieczne jest używanie dobrze zdefiniowanego i jednoznacznego słownika pojęć oraz jasnych zasad opisu relacji między tymi pojęciami. W odróżnieniu od obszaru aplikacji, gdzie wystarczające jest używanie modeli obszaru aplikacji, przy opisie całego przedsiębiorstwa musimy poradzić sobie z koniecznością opisu spójnego pomiędzy różnymi obszarami jak i w samych obszarach jego działania.
Przekazywanie informacji (komunikacja) na temat architektury przedsiębiorstwa jest znaczącym wyzwaniem, ponieważ w odróżnieniu do ograniczonego obszaru architekturą przedsiębiorstwa zainteresowanych osób jest znacznie więcej a należy pamiętać, że każda z tych osób charakteryzuje się innym punktem widzenia, potrzebami jak i zakresem środków opisu świata, który leży w zakresie jej zainteresowania.
Architektura korporacyjna to nie tylko opis świata przez pryzmat stanu obecnego, ale może przede wszystkim opis zmian służących osiągnięciu pewnego stanu architektury, która będzie spełniać stawiane przed nią cele wynikające z misji działania przedsiębiorstwa. Wizualizacje architektur przejściowych i docelowych są jednym z podstawowych narzędzi, jakimi musi posługiwać się architekt korporacyjny. Zapewne wielu z czytających spotkało się z problemem takiego wyrażenia architektury przedsiębiorstwa na widokach, aby były one zrozumiałe przez zainteresowanych a jednocześnie zawierały wystarczającą ilość informacji, która pozwoli potraktować wizualizację jako widok architektury, a nie rysunek tworzony na potrzeby prezentacji. Ja miałem problem z tym wielokrotnie poczynając od zakresu informacyjnego, poprzez użycie takich a nie innych symboli a kończąc na kolorystyce. A przecież nie takie problemy powinny być istotą pracy architekta korporacyjnego.
Dlaczego nie możemy użyć istniejących języków modelowania?
No dobrze, mamy przecież język UML, ARIS, IDEF, BPMN, itd.. Otóż, powtórzę, UML jest to język ogólnego zastosowania, z którego należy dopiero wyprowadzić język właściwy, albo inaczej nadać mu znaczenie dla konkretnego zastosowania. Jak napisałem we wstępie, sprofilowanie UML do potrzeb modelowania architektury korporacyjnej jest możliwe, a sam ArchiMate w narzędziach wspierających UML realizowany jest najczęściej jako profil UML (np. Enterpirse Architect od wersji 7.5). Proszę zwrócić uwagę, w UML semantyka, czyli opis znaczenia symboli i ich powiązań, jest ograniczona wyłącznie do zakresu diagramu a i tu często użytkownicy mają problem z odnalezieniem znaczenia. W przypadku BPMN jest inaczej, ponieważ BPMN jest językiem wynikowym, ale ograniczonym wyłącznie do aspektów dynamiki, czyli tylko jednego z trzech obszarów zainteresowania architektury korporacyjnej (patrz. Rys. 2). Można by wymieniać i inne przykłady języków opisu jak ARIS (produkt komercyjny), IDEF, itd. z tym, że każdy z tych przykładów za początkowy cel obierał coś zgoła innego aniżeli architektura korporacyjna, czyli skupiał się na pewnym obszarze lub obszarach a nie ujęciu całościowym pracy przedsiębiorstwa. Dlatego też te języki opisu koncentrują się na jednym obszarze lepiej niż na innych, lub oferują zbyt wiele elementów, co stanowi problem, z uwagi na dużą liczbę symboli, w przypadku konieczności komunikowania architektury do szerokiej grupy zainteresowanych. Architektura korporacyjna potrzebuje języka prostego, zrozumiałego i możliwego do interpretacji przez jak największą liczbę zainteresowanych. Archimate jest właśnie odpowiedzią na próby ujęcia architektury całościowo, spójnie w różnych obszarach nie zawłaszczając jednak pola dla opisów szczegółowych za pomocą istniejących języków – UML, BPMN, ARIS, IDEF, itd. ArchiMate nie zastępuje żadnego z wymienionych języków, a powinien być traktowany jako uzupełnienie służące ułatwieniu badania i opisywania relacji pomiędzy elementami, których szczegóły można opisywać właśnie przy użyciu w/w języków i notacji.
Krótki opis ArchiMate
Wersja 1.0 ArchiMate została uznana jako techniczny standard opisu architektury korporacyjnej przez The Open Group®. Główne cele, dla których stworzono ArchiMate pokazuje Rys. 1.
Rysunek 1 Główne cele opisu architektury korporacyjnej w języku ArchiMate
Ponownie warto powtórzyć, że celem ArchiMate nie jest opis szczegółowy w obszarach, dla których istnieją już języki opisu. Celem jest głównie ujęcie najważniejszych elementów z tych obszarów i zadbanie o powiązania zarówno pomiędzy obszarami jak i elementami obszarów.
Archimate zakłada modelowanie architektury w trzech warstwach przedsiębiorstwa:
- biznesowej,
- aplikacji,
- infrastruktury.
A artykule [1] wyróżniłem cztery warstwy obszarów przedsiębiorstwa, przy czym według autorów ArchiMate, zresztą całkiem słusznie, warstwa danych powinna być rozpatrywana jako fragment trzech pozostałych (w ramach zarządzania informacjami), co pokazuje Rysunek 2. Każda warstwa obejmuje swoim opisem elementy zachowania, tj. dynamiki (funkcje, usługi, procesy) oraz struktur, tj. wszystkich tych elementów aktywnych (ludzie, sprzęt, interfejsy, aplikacje / komponenty / systemy informatyczne), które wspierają realizację funkcji, usług i procesów przedsiębiorstwa.
Rysunek 2 Koncepcja warstw modelu języka ArchiMate
Do opisu elementów architektury autorzy ArchiMate zastosowali paradygmat budowania rozwiązań w oparciu o usługowość (Service Oriented Computing). Co to oznacza? Każda warstwa swoje funkcje jak procesy oferuje do warstw wyższych poprzez usługi., tj.
- warstwa infrastruktury dla warstwy aplikacji,
- warstwa aplikacji dla warstwy biznesowe,
- warstwa biznesowa dla klienta.
Usługi oferowane są przez interfejsy, które stanowią opis sposobu udostępniania usług przez elementy aktywne warstwy (komponent, rola biznesowa, urządzenie, itd.). Elementy zachowania zarządzają danymi (informacjami).
Ogólny metamodel w oparciu, o który zbudowany jest język ArchiMate przedstawia rys. 3.
Rysunek 3 Główna idea (uproszczony metamodel) języka ArchiMate
W celu zapoznania się z wszystkimi elementami i relacjami języka ArchiMate zachęcam do przejrzenia przybornika języka na stronie [3]. Struktura i najważniejsze idee języka ArchiMate przedstawia rysunek 4, na którym pokazuję koncepcję całego języka ArchiMate w ujęciu wszystkich warstw z uwzględnieniem podziału na elementy informacyjne, zachowania i struktury przedsiębiorstwa. Oczywiście widok ten jest tylko przybliżeniem i nie zawiera opisu wszystkich elementów, relacji pomiędzy elementami i ich znaczeń. Jest to jednak dobry punkt startu pozwalający zrozumieć, co obejmuje swoim opisem język (całe przedsiębiorstwo) i jak realizuje postulaty kontroli zależności pomiędzy elementami różnych warstw (usługowość oraz relacje).
Rysunek 4 Ogólna koncepcja języka ArchiMate
Jak skorzystać z ArchiMate?
Poziom opisu poszczególnych elementów i sposób użycia relacji języka w konkretnym przypadku jest tym, co musi zostać wypracowane przez architektów korporacyjnych. Zanim architekci korporacyjni przystąpią do modelowania przy użyciu ArchiMate muszą bardzo dokładnie określić kryteria powoływania każdego z egzemplarzy elementów języka (repozytorium architektury). ArchiMate podaje definicje dla każdego z elementów, ale nie są one precyzyjne i nie wystarczają do jednoznacznego użycia w pracy. Stąd właśnie największe zadanie przed przystąpieniem do pracy z ArchiMate, polega na podaniu definicji i kryteriów powoływania – funkcji, usług, procesów biznesowych, interfejsów, itd.. Konieczne jest znalezienie odpowiedzi na pytania dotyczące elementów w każdej z warstw, np. Czym interfejs biznesowy różni się od interfejsu aplikacji a ten od interfejsu infrastruktury i co przedstawia każdy z tych interfejsów? To samo dotyczy modelowania danych (informacje) a zwłaszcza rozgraniczenia elementu obiektu biznesowego (warstwa biznesowa) od elementu danych (warstwa aplikacji). Relacji i różnych ich typów w ArchiMate jest bardzo dużo. Aby rozsądnie skorzystać z ArchiMate sugeruję od razu ograniczyć liczbę stosowanych typów relacji do minimum w celu minimalizacji ryzyka niejednoznacznego rozumienia modeli i widoków. Oczywiście, aby w pełni skorzystać z języka i nie ograniczać jego użycia do „rysowania architektury” konieczne jest budowanie modeli za jego pomocą korzystając z narzędzia informatycznego pozwalającego na zarządzanie elementami, relacjami i wersjami.
Każde przedsiębiorstwo jest inne, co do charakteru branży, kultury pracy z architekturą, jak również potrzeb użycia języka. Widok z rys. 4. przedstawia język przekrojowo poprzez wszystkie warstwy. Zakładając, że architekt korporacyjny ma do dyspozycji narzędzie z pełnym modelem architektury korporacyjnej (repozytorium wszystkich instancji elementów i ich relacji), przy tworzeniu konkretnych widoków, architekt rzadko będzie przygotowywać widoki zawierające egzemplarze wszystkie elementów z każdej z trzech warstw. To oznacza, że jeśli przygotowuje widok warstwy biznesowej w ujęciu procesów biznesowych nie musi przedstawiać usług infrastruktury. Jednak w modelu takie dane są i kiedy na przykład padnie pytanie – Które aplikacje i ile maszyn wspiera dany proces biznesowy?, architekt będzie w stanie szybko niezbędne informacje z modelu pobrać. I to właśnie dostęp do wiedzy opisanej na zrównoważonym poziomie, według mnie świadczy o sile i dość dużych możliwościach płynących z użycia języka – pomimo tego, że początkowo może wyglądać on jak zabawka.
Podsumowanie
Jeśli implementujemy architekturę korporacyjną, to prędzej czy później będziemy potrzebowali środków wyrazu, które pozwolą nam na łatwiejsze zarządzanie elementami, nad którymi powinniśmy mieć kontrolę. ArchiMate wydaje się krokiem we właściwą stronę, chociaż sam nie jest jeszcze językiem pozwalającym na kompleksowy opis i wsparcie zarządzania architekturą korporacyjną. ArchiMate nie faworyzuje, co do poziomu i zakresu opisu, żadnego z obszarów ani elementów w ramach tych obszarów. ArchiMate służy opisowi zależności pomiędzy obszarami jak i samych obszarów na wysokim poziomie. Języka tego można użyć jako środka do przedstawienia mapy przedsiębiorstwa, gdzie elementy ArchiMate mogą być uszczegóławiane z użyciem innych języków opisu architektur.
Warto przyjrzeć się ArchiMate chociażby dlatego, że to z czym możemy się zetknąć próbując opisać nasz świat (przedsiębiorstwo) ktoś wcześniej już sprawdził i podał dość prosty przepis jak sobie z tym poradzić.
Pomimo, że język ten oferuje duże możliwości dla architektów korporacyjnych, to na pewno nie daje gotowej recepty na dwa problemy, które leżą u podstaw zarządzania architekturą korporacyjną. Jednym z nich jest zarządzanie zmianą w architekturze korporacyjnej, tj. takie zarządzanie modelami, aby móc zarządzać kolejnymi wersjami architektur. Drugim niedociągnięciem wersji 1.0 języka, z którym jednak można sobie łatwiej poradzić jest brak kilku podstawowych elementów opisu architektury korporacyjnej, jak choćby reguły biznesowe, zasady architektoniczne czy też decyzje architektoniczne, które mają związek z zarządzeniem zmianą. Mam nadzieję te drobne niedociągnięcia zostaną wyeliminowane w kolejnych wersjach. Tymczasem zachęcam do rozpoczęcia własnych analiz nad językiem i prób wykorzystania ArchiMate w swojej pracy.
Odnośniki
[1] ArchiReq – Parę słów o architekturze korporacyjnej