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
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
Na podstawie powyżej zdefiniowanych elementów powstały następujące przykładowe diagramy.
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.
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.
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
Pozostałych przejmowanych firmach obecnie działają inne systemy.
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.
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.
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.
Podobnie można przygotować połączenie aplikacji z infrastrukturą.
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.
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.
Cele operacyjne można dekomponować. Dalsze kroki to opracowanie wymagań, które pozwolą na wskazanie działań, których realizacja pozwoli osiągnąć cele.
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.
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.
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.
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
Pozostałych przejmowanych firmach obecnie działają inne systemy.
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.
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.
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”.
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”.
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.
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 🙂
