ArchiMate w praktyce

Archimate 3.0

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 jednolity sposób opisywać, analizować oraz wizualizować różne dziedziny architektury oraz relacje pomiędzy nimi. Swoim zakresem obejmuje warstwy biznesu, systemów informatycznych, infrastruktury.

Standard ArchiMate® zapewnia graficzny język do reprezentacji architektury korporacyjnej, z uwzględnieniem jej zmian w czasie (transformacja i migracja), a także jej motywacji i strategii. Notację ArchiMate opisałem w serii artykułów https://wolski.pro/archimate-3-0/. W tym wpisie przedstawiam ArchiMate w praktyce, czyli będą to praktyczne przykłady użycia notacji ArchiMate zamodelowane w Enterprise Architect.

Przedstawione w artykule, modele te mają przykładowy charakter. W każdej organizacji w zależności od: potrzeb, jej sytuacji, celu i roli architektury oraz sposobu wytwarzania oprogramowania, modele mogą wyglądać inaczej. W razie pytań zapraszam do kontaktu.

W artykule będę posługiwał się przykładem fikcyjnego banku MODBank. Bank ten oferuje swoim klientom kredyty hipoteczne, konsumpcyjne oraz karty kredytowe. W wyniku akwizycji dwóch firm KredytySamochodowy (KS) oraz TwojeFinanse (TS) bank pozyskał sieć placówek partnerskich sprzedających odpowiednio kredyty samochodowe i mikropożyczki. Zarząd ModBanku postawił sobie następujące cele:

  • udostępnienie całej oferty kredytowej w nowo nabytych placówkach partnerskich,
  • udostępnienie mikropożyczek i kredytów samochodowych w placówkach ModBanku,
  • ujednolicenie kanałów komunikacji z klientami (CRM, infolinia, strona internetowa).

Jedną z pierwszych czynności, jaką należy zrobić by osiągnąć wskazane cele jest opracowanie modeli opisujących stan obecny. Modele nie mogą być zbyt detaliczne. Powinny też dotyczyć takich obszarów jak architektura biznesowa, architektura aplikacji i architektura technologiczna.

Architektura biznesowa w ArchiMate

Na architekturę biznesową składa się wiele elementów notacji ArchiMate. Najczęściej korzystam z aktora biznesowego, procesu biznesowego, usługi biznesowej oraz obiektu biznesowego. Elementy zostały opisane w ArchiMate – Warstwa biznesowa

Archimate Elementy Notacji Warstwa Biznesowa
Wybrane elementy notacji ArchiMate – warstawa biznesowa

Użyte na powyższym rysunku połączenia to:

  • aktor biznesowy -> rola biznesowa : assigment
  • rola biznesowa -> proces biznesowy: assigment
  • proces biznesowy -> obiekt biznesowy: access
  • proces biznesowy -> usługa biznesowa: realization
  • zdarzenie biznesowe -> proces biznesowy: triggering
Archimate Warstwa Biznesowa Przyklad 3
Architektura biznesowa – MODBank

Na podstawie powyżej zdefiniowanych elementów powstały następujące przykładowe diagramy.

Archimate Warstwa Biznesowa Przyklad 1
Architektura biznesowa – Mikropożyczki

Na diagramie wskazano składowe podprocesy procesu Sprzedaż mikropożyczki. W procesie uczestniczy w roli Kredytodawcy aktor: Dział Mikropożyczek. Proces „Sprzedaż mikropożyczki” dostarcza (realizuje) usługę „Usługa sprzedaży mikropożyczki”. Podobny diagram powstał dla firmy KredytySamochodowy (KS) oraz TwojeFinanse (TS). Poniżej diagram dla KredytSamochodowy.

Archimate Warstwa Biznesowa Przyklad 2
Architektura biznesowa – Kredyty samochodowe

Analizując powyższe rysunki, należy mieć na uwadze, że zdefiniowane na diagramach procesy biznesowe są na poziomie N-1 i N-2. Oznacza to, ze zagnieżdżone procesy mogą być uszczegółowione diagramami BPMN.

Architektura aplikacji w ArchiMate

Architektura aplikacji ma za zadanie zaprezentować systemy wraz z usługami, jakie one dostarczają. We wpisie ArchiMate – Warstwa systemów informatycznych opisałem wszystkie elementy składowe. Najczęściej na diagramach używam komponentu, funkcji, usługi, interfejsu (wszystko aplikacji) oraz obiektu danych.

Archimate Elementy Notacji Warstwa Aplikacji
Wybrane elementy notacji ArchiMate – warstawa aplikacji

Użyte na powyższym rysunku połączenia to:

  • komponent aplikacji -> funkcja aplikacji : assigment
  • komponent aplikacji -> usługa aplikacji: realization
  • komponent aplikacji -> interfejs aplikacji: composition
  • funkcja aplikacji -> usługa aplikacji: realization
  • interfejs aplikacji -> usługa aplikacji : assigment
  • usługa aplikacji -> obiekt danych: access

W opisywanym przykładzie na architekturę aplikacji (w zakresie kredytów) w firmie MODBank składa się kilka poniżej zaprezentowanych systemów

Archimate Warstwa Aplikacji Przyklad 1
Architektura aplikacji – MODBank

Pozostałych przejmowanych firmach obecnie działają inne systemy.

Archimate Warstwa Aplikacji Przyklad 2
Architektura aplikacji – Mikropożyczki i Kredyty Samochodowe

Z powyższych rysunków można wywnioskować, ze o ile procesy biznesowe na wysokim poziomie abstrakcji wyglądają podobnie to już na poziomie procesów uszczegóławiających (N-2) zaczynają się różnić. Zidentyfikowane aplikacje wpierające procesy umożliwiające udzielenie kredytów różnią się w znaczący sposób. Bardzo często pomijam funkcje aplikacji. Wszystko zależy od celu modelowania.

Architektura technologiczna w ArchiMate

Architektura technologiczna opisuje przede wszystkim infrastrukturę, Jej składowe elementy opisałem na stronie ArchiMate – Warstwa technologiczna. Najczęściej korzystam z następujących elementów: węzeł, oprogramowanie, usługa technologiczna.

Archimate Elementy Notacji Warstwa Technologiczna
Wybrane elementy notacji ArchiMate – warstawa technologiczna

Użyte na powyższym rysunku połączenia to:

  • sieć -> węzeł : association
  • urządzenie-> węzeł : assigment
  • węzeł-> artefakt : assigment
  • węzeł-> oprogramowanie systemowe : assigment
  • urządzenie -> usługa technologiczna: realization
  • oprogramowanie systemowe -> usługa technologiczna: realization

W ten oto sposób można opisać fragment infrastruktury potrzebnej do działania aplikacji związanych z kredytami. Przykładowy diagram może wyglądać tak jak to przedstawiono na poniższym rysunku. Oczywiście jest wycinek rzeczywistej infrastruktury.

Archimate Warstwa Technologiczna Przyklad 1
Architektura Infrastruktura – MODBank

Na powyższym rysunku zastosowaną usługę „łącznik”. Zgodnie z notacją ArchiMate element Junction byłby bardziej właściwy, ale w czasie przygotowania raportów sprawia on problemy.

Tak przygotowane elementy pozwalają na przygotowanie wspólnego widoku dla wszystkich warstw.

Modele wielowarstowe

Modele wielowarstwowe w ArcjiMate mają za zadanie pokazać zależności pomiędzy architekturą biznesową a architekturą aplikacji oraz wskazać te elementy infrastruktury technicznej, które są niezbędne do działania aplikacji.

Archimate Warstwa Biznesowa I Aplikacji As Is
Usługi aplikacji wykorzystywane w procesie obsługi kredytu hipotecznego

Podobnie można przygotować połączenie aplikacji z infrastrukturą.

Archimate Warstwa Aplikacji I Technologiczna As Is
Usługi technologiczne wykorzystywane w procesie obsługi kredytu hipotecznego

Tak oto została przygotowana architektura obecna dla wszystkich trzech firm w integrowanym zakresie. Kolejny etap to analiza celów.

Motywacja w notacji ArchiMate

Notacja ArchiMate jest pomocna w analizie celów, wymagań oraz wszystkich innych elementów związanych z szeroko rozumianą motywacją zmiany. Rozszerzenie motywacji opisałem w tekście: ArchiMate – Elementy motywacji. Do moich ulubionych elementów należą: cel, wymaganie i pryncypium.

Archimate Elementy Notacji Motywacja
Wybrane elementy notacji ArchiMate – motywacja

Użyte na powyższym rysunku połączenia to:

  • wymaganie -> pryncypium: realization
  • wymaganie -> cel: realization
  • pryncypium -> cel: realization
  • cel -> czynnik sterujący: association

W omawianym przykładzie celem jest Włączenie do MODBanku nowo nabytych firm KS i TS. Cel ten jest dekomponowany na cele operacyjne, co zostało przedstawione na poniższym rysunku.

Archimate Motywacja Cele
ArchiMate cel strategiczny i cele operacyjne

Cele operacyjne można dekomponować. Dalsze kroki to opracowanie wymagań, które pozwolą na wskazanie działań, których realizacja pozwoli osiągnąć cele.

Archimate Motywacja Cele Realizacja
Cele i ich realizacja

W tym miejscu warto zauważyć, że cel „Integracja systemów CRM” ma przypisane pryncypium. To przykładowe pryncypium brzmi: Preferowane jest budowanie aplikacji wspólnych dla całej organizacji, niż tworzenie aplikacji podobnych dla różnych jednostek realizujących podobne funkcje. Pryncypia bardzo pomagają w przygotowaniu wymagań, gdyż określają oczekiwany kierunek zmian.

ArchiMate i architektura docelowa

Po zdefiniowaniu motywacji kolejnym etapem jest budowa modeli opisujących architektury biznesową, informacyjną i technologiczną, z uwzględnieniem architektury bazowej (tej która teraz funkcjonuje) oraz architektury docelowej. Standard ArchiMate, proponuje trzy typy diagramów: diagram warstwy biznesowej, diagram warstwy aplikacji i diagram warstwy technologii. Jednakże nic nie stoi na przeszkodzie, aby na diagramie warstwy biznesowej korzystać z elementów przypisanych do warstwy aplikacji.

Zgodnie z założeniami Archimate architektura biznesowa skupia się m.in. wokół serwisów, procesów i funkcji biznesowych. Proces biznesowy opisuje wewnętrzne zachowanie organizacji, które jest wymagane do realizacji zbioru produktów i usług biznesowych. Funkcje biznesowe, podobnie jak procesy biznesowe, także opisują wewnętrzne zachowanie organizacji, jednak ich celem jest zapewnienie zasobów biznesowych, umiejętności, kompetencji, wiedzy, itp. Usługa biznesowa natomiast ma za zadanie spełnienie konkretnych potrzeb biznesowych klienta (zewnętrznego, jak i wewnętrznego). Usługa biznesowa powinna dostarczać określoną funkcjonalność/wartość dla klienta, która ma określone dla niego znaczenie. Usługi biznesowe realizowane są poprzez procesy i funkcje biznesowe. Analizując architekturę biznesową musimy uwzględnić, których usług, procesów i funkcji biznesowych będą dotyczyły prace architektoniczne dla danego projektu. Musimy uwzględnić, które elementy architektury biznesowej będę modyfikowane, dodawane i usuwane. Każdy z tych elementów powinien zostać opisany na wcześniej ustalonym poziomie szczegółowości. Jeśli elementy zostały już opisane podczas wcześniejszych prac architektonicznych, to opisy te powinny zostać zweryfikowane i w razie potrzeby uzupełnione lub zmodyfikowane.

Analizując przykład MODBanku, zostały wybrane cztery podstawowe usługi, których prace architektoniczne dotyczą:

  • Usługa sprzedaży kredytu hipotecznego,
  • Usługa sprzedaży kredytu konsumpcyjnego,
  • Usługa sprzedaży mikropożyczki,
  • Usługa sprzedaży kredytu samochodowego.

Oczywiście liczba wybranych usług została ograniczona na potrzeby przykładu. W rzeczywistości liczba ta byłaby znacznie dłuższa i uwzględniałaby nie tylko usługi sprzedaży kredytów, ale także inne świadczone dla klientów, jak np. usługi dostępu do informacji o przyznanych kredytach, kartach kredytowych, itp. Na diagramie poniżej zostały przedstawione usługi, których prace architektoniczne dotyczą wraz ze wskazaniem, że są one wykorzystywane przez rolę biznesową Nabywca kredytu, a realizowane są natomiast przez odpowiednie procesy biznesowe.

Archimate Analiza Biznesowa
Diagram usług i procesów biznesowych, których dotyczą prace architektoniczne

Posługując się dalej przykładem ModBanku, gdy już zidentyfikowaliśmy procesy biznesowe, które będą modyfikowane w ramach projektu dotyczącego włączenia w struktury banku nowo nabytych spółek możemy dokonać analizy realizacji tych procesów przez usługi aplikacji, co pozwoli nam zidentyfikować elementy oprogramowania i infrastruktury, które będziemy musieli uwzględnić podczas dalszego modelowania architektury korporacyjnej. Na diagramach poniżej przedstawiłem obszar realizacji wybranych procesów biznesowych przez usługi aplikacji dla architektury istniejącej.

Archimate Analiza Biznesowa Systemy 1
Architektura istniejąca: Realizacja procesu „Sprzedaż kredytu hipotecznego” przez usługi aplikacji
Archimate Analiza Biznesowa Systemy 2
Architektura istniejąca: Realizacja procesu „Sprzedaż kredytu samochodowego” przez usługi aplikacji
Archimate Analiza Biznesowa Systemy 3
Architektura istniejąca: Realizacja procesu „Sprzedaż mikropożyczki” przez usługi aplikacji

Na dwóch ostatnich diagramach została wykorzystana relacja grupowania dla usług aplikacji, aby zaznaczyć, że dana grupa usług aplikacji należy do systemów informatycznych odpowiedniej firmy: udzielającej mikropożyczek (TS) i udzielającej kredyty samochodowe (KS). Język ArchiMate relację grupowania definiuje jako relację, która wskazuje, że dane obiekty należą do tej samej grupy określonej za pomocą wybranego kryterium. W tym przypadku kryterium dotyczyło przynależności do systemów informatycznych określonej firmy.

Analizując diagramy realizacji procesów biznesowych dla architektury istniejącej możemy zauważyć, że niektóre procesy wykorzystują usługi aplikacji, które udostępniają podobne funkcjonalności. Usługi te powinny zostać zintegrowane z już istniejącymi w ModBanku przez włączenie komponentów je realizujących do portfela aplikacji ModBanku, czy też implementację nowych lub aktualizację istniejących komponentów w portfelu aplikacji. Na diagramie poniżej przedstawiłem model realizacji procesów biznesowych przez zintegrowane usługi biznesowe dla architektury docelowej.

Archimate Architektura Docelowa
Architektura docelowa: Realizacja procesów biznesowych przez usługi aplikacji

Na powyższym diagramie wskazano usługi aplikacyjne, które będą wspierały procesy biznesowe dot. sprzedaży mikropożyczek i kredytów samochodowych. Nowe połączenia zostały pokazane kolorem zielonym. Oczywiście przykład jest trochę przejaskrawiony, gdyż bardzo rzadko zdarza się, by stare usługi przejęły aż dwa nowe procesy. Częstszym przypadkiem będzie utworzenie owych usług w aplikacji ModBank.

Analizując architekturę aplikacji mamy dość podobną sytuację. W opisywanym przykładzie na architekturę aplikacji w firmie MODBank składa się kilka poniżej zaprezentowanych systemów

Archimate Warstwa Aplikacji Przyklad 1
Architektura aplikacji – MODBank

Pozostałych przejmowanych firmach obecnie działają inne systemy.

Archimate Warstwa Aplikacji Przyklad 2
Architektura aplikacji – Mikropożyczki i Kredyty Samochodowe

Analizując funkcje aplikacji i przypisane do nich komponenty możemy zauważyć, że niektóre z nich realizują podobną funkcjonalność w poszczególnych firmach. Wszystkie systemy CRM realizują te same funkcje. Utrzymanie oddzielnych baz klientów może spowodować, iż konsultanci albo pominą docelową grupę klientów, albo zwielokrotnią tą samą ofertę – co może podnosić koszty marketingu, a także negatywnie być odebrane przez klientów. Dodatkowo utrzymanie wielu podobnych aplikacji jest kosztowne i może wpływać na konflikt, niespójność i nieaktualność danych oraz w znacznym stopniu ogranicza zdolność szybkiego dostosowania ich do nowych wymagań stawianych przez biznes. W związku z tym należy zastanowić się nad możliwością zastąpienia trzech systemów CRM jednym. Należy rozważyć możliwość utworzenia nowego wspólnego systemu CRM lub pozostawienie któregoś z już istniejących. Możemy także zauważyć, że system zarządzania kredytami samochodowymi i system zarządzania mikropożyczkami zapewne implementują podobne funkcje wspólne dla ogólnej funkcjonalności zarządzania kredytami, jak np. uruchomienie kredytu. W związku z tym należy rozważyć możliwość implementacji ich funkcjonalności w systemie ModBanku „Zarządzanie kredytami”. Podobna sytuacja dotyczy także systemów realizujących usługę aplikacji „Ocena ryzyka”. Na diagramie poniżej przedstawiona została proponowana architektura docelowa dla warstwy aplikacji.

Archimate Architektura Docelowa Aplikacje
Architektura docelowa: Aplikacje

Analizując diagramy istniejącej i docelowej architektury aplikacji możemy zauważyć, że w naszym przykładzie zdecydowano się na wykorzystanie istniejącego systemu ModBank CRM do obsługi kontaktów z klientami. Zdecydowano się także na implementację specjalistycznej funkcjonalności systemów (jak np. wycena samochodu, zarządzanie mikropożyczką) jako moduły w ramach istniejących systemów w ModBanku: systemu analiz i systemu zarządzania kredytami. Kolejnym krokiem jest analiza luk.

ArchiMate – implementacja i migracja

Podczas projektowania architektury biznesowej, aplikacji, danych i technologii ważnym krokiem na każdym z tych etapów jest przeprowadzenie analizy luk pomiędzy architekturą istniejącą i docelową. Analiza ta będzie wykorzystana podczas planowania implementacji i migracji pomiędzy architekturą istniejącą, architekturami przejścia i architekturą docelową. Modelując ten obszar najczęściej korzystam z takich elementów jak produkt, grupa zadań, luka i stan. Elementy te szczegółowo opisałem w ArchiMate – Elementy implementacji i migracji.

Archimate Elementy Notacji Implementacja I Migracja
Wybrane elementy notacji ArchiMate – implementacja i migracja

Użyte na powyższym rysunku połączenia to:

  • grupa zadań -> produkt: realization
  • produkt -> stan: realization
  • luka -> stan: association

Dla omawianego przykładu, na diagramie poniżej został zaprezentowany przykładowy diagram prezentujący punkt widzenia modelujący zmianę architektury dla programu „Integracja systemów informatycznych nowo nabytych spółek z systemami informatycznymi ModBank”.

Archimate Program Intergacji I Migracji Systemów
Program integracji systemów informatycznych nowo nabytych spółek z systemami informatycznymi ModBank

Na diagramie przedstawiłem program integracji systemów informatycznych nowo nabytych spółek z systemami informatycznymi ModBank. Program został podzielony na 6 mniejszych projektów realizowanych sekwencyjnie. Dla wybranych projektów zostały przedstawione produkty, które zostaną wytworzone po realizacji tych projektów. Analizując dalej poszczególne projekty możemy dla każdego z nich przedstawić sposób implementacji poszczególnych rozwiązań. Na diagramie poniżej przedstawiłem punkt widzenia migracji i implementacji dla projektów „Integracja systemów CRM” oraz „Integracja systemów zarządzania kredytami”.

Archimate Migracja I Implementacji Dla Projektów Przyklad
Punkt widzenia migracji i implementacji dla projektów „Integracja systemów CRM” oraz „Integracja systemów zarządzania kredytami”

Na diagramie zgodnie z opisem w legendzie liniami czerwonymi zostały połączone projekty z komponentami aplikacji, które nie będą funkcjonowały w architekturze docelowej, niebieskimi komponenty, które wymagają modyfikacji, a zielonymi nowo tworzone.

Podsumowanie

W zaprezentowanym artykule skupiłem się na zaprezentowaniu możliwości wykorzystania notacji ArchMate w obszarze modelowania architektury organizacji. Niemniej jednak zaprezentowane rozwiązania doprowadziły do sytuacji, w której możemy dość szybko prześledzić impakt zmiany od celu do procesów biznesowych i infrastruktury.

Archimate Od Celu Do Zmiany
Impakt zmiany od celu do aplikacji, procesów i infrastruktury

Na powyższym rysunku widać, że realizacje celu biznesowego „Ujednolicenie kanałów komunikacji z klientami” zostanie osiągnięte poprzez realizację wymagania „Zaimportowanie danych z systemów CRM KS i TK do systemu CRM ModBank”. Wspomniane wymaganie zostanie zrealizowane poprzez produkt: „Zintegrowany system ModBank CRM” w ramach grupy zadań: „Integracja systemów CRM”. Wspomniana grupa zadań wyłącza z eksploatacji dwa systemy i zmienia aplikację „System ModBank CRM”. Zmian ta dotyczy usługi: „Obsługa klienta” oraz infrastruktury (wskazanej na zielono serwer IIS i baza danych MODBANK). Zmian w usłudze „Obsługa klientów” powoduje, że zmianie ulegnie 6 procesów biznesowych.

Co daje taki obrazek? Myślę, że sporo. Przede wszystkim pozwala z dużym wyprzedzeniem określić zakres zmiany i tym samym zyskujemy czas na przygotowanie tej zmiany nie tylko w kodzie aplikacji, ale także w infrastrukturze i procesach biznesowych. Po drugie umożliwia przemyślenie poszczególnych kroków i oszacowanie ich złożoności oraz kosztów. Po trzecie pozwala na zastanowienie się, jak organizacja będzie działała w okresie przejściowym.

Powodzenia 🙂

Podobne wpisy
Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia

Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny. W projektach dla mnie ważne więcej

Szacowanie projektu w Enterprise Architect

Szacowanie projektu oraz jego złożoności jest trudne. Istnieją metody, które wspomagają ten proces. Jedną z nich jest metoda  use case więcej

Transformacja PIM-PSM w Enterprise Architect

Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM więcej

Sprawdzanie pisowni w Enterprise Architect – polski słownik

Robiąc projekt piszę szybko i popełniam literówki. Ręczne sprawdzanie wpisów jest kłopotliwe, gdyż domyślnie w Enterprise Architect nie ma zainstalowanego więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top