Przykładowe widoki ArchiMate: Pełna galeria – Motywacja, Strategia, Biznes, Aplikacje, Technologia i Migracja

Widok frameworku

Widok frameworku.

Ten widok reprezentuje framework do budowania wszystkich aspektów rozwoju i powiązanych diagramów. Widok można dostosować do sytuacji. Dlatego ten widok może być używany do nawigacji między diagramami. Ta wersja widoku jest stosowana z frameworku ArchiMate (3). Motywacja jest tu wprowadzana jako „warstwa”, a nie jako „aspekt”.

Punkt widzenia motywacji

Punkt widzenia motywacji

Punkt widzenia motywacji.

Ten widok może być używany do analizy motywacji lub czynników napędzających, które kierują organizacją i jej projektowaniem lub zmianą architektury przedsiębiorstwa. Analizy motywacji są punktem wyjścia dla wszystkich działań zmiany lub transformacji biznesowych w organizacji. Widok reprezentuje wizję pracy rozwojowej — czy zakres i skala obejmują całą organizację, jej część (np. linia biznesowa) lub pojedynczy program lub projekt (poziom rozwiązania). Uwaga: Do elementu np. Wynik (lub innego elementu ArchiMate) można dodać wartość, aby wskazać rzeczywistą wartość dodaną!

Elementy motywacji oparte są na Modelu Motywacji Biznesowej (BMM) [specyfikacja w.1.3, 2015, OMG].

Widok misji – wizji – wartości

Misja – Wizja – Wartości.

Ten widok może być używany do przedstawienia misji, wizji i wartości centralnych organizacji. Misja wyraża, na przykład: „Jaka jest misja organizacji, co faktycznie robi lub zamierza robić, i jaki jest główny powód jej istnienia?” Wizja to stan przyszły, którego organizacja chce osiągnąć. Wartości centralne wspierają wizję, kształtują kulturę i odzwierciedlają wartości organizacji. Aby zrealizować wizję organizacji, należy osiągnąć cele strategiczne.

Źródło: Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Modelowanie strategii za pomocą ArchiMate.

Widok mapy wartości strategicznych

Mapa wartości – Widok mapy strategii.

Ten widok może być używany do wizualizacji strategii organizacji. Widok zawiera elementy wartości strategicznych, a wszystkie działania rozwojowe muszą być wyprowadzone — bezpośrednio lub pośrednio — z elementów wartości strategicznych. Poprzez wizualizację wartości strategicznej możliwe jest śledzenie wszystkich innych elementów związanych z rzeczywistym wykonaniem strategii. Dzięki temu widokowi strategia może być zmaterializowana: wizualizowana, komunikowana i łączone z rzeczywistością.

Widok analizy interesariuszy

Widok analizy interesariuszy.

Ten widok może być używany do analizy interesariuszy w kontekście rozwoju biznesowego: jakie są czynniki zmiany? Najpierw identyfikuje się istotnych interesariuszy, a następnie ustala się czynniki zmiany zgodne z ich interesami. Pojęcie „Ocena” może być używane do szczegółowej analizy czynników, np. według podejścia SWOT (Zalety, Wady, Okazje, Zagrożenia). Zazwyczaj można tworzyć różne widoki interesariuszy z różnych punktów widzenia. Inny powód podziału dużego obrazu na mniejsze fragmenty to utrzymanie diagramów zwięzłych i czytelnych — dla prostoty.

Punkt widzenia interesariuszy

Punkt widzenia interesariuszy.

Ten widok może być używany do łączenia czynników napędzających interesariuszy z celami biznesowymi. Cele są kluczowymi elementami rozwoju organizacji. Wszystkie kolejne elementy powinny być związane z tymi podstawowymi czynnikami napędzającymi wszystkie działania zmiany.

Widok zasad

Widok zasad.

Widok ryzyka i bezpieczeństwa

Widok ryzyka i bezpieczeństwa. Mapowanie koncepcji ryzyka i bezpieczeństwa na ArchiMate. Problemy bezpieczeństwa i ochrony danych są częścią zarządzania ryzykiem. Ten sposób modelowania obejmuje oba aspekty.

Źródła:

• Jak modelować zarządzanie ryzykiem i bezpieczeństwo w przedsiębiorstwie za pomocą języka ArchiMate®, The Open Group, Numer dokumentu: W172, 2017.
• Modelowanie zarządzania ryzykiem i bezpieczeństwem w przedsiębiorstwie za pomocą języka ArchiMate®. The Open Group, 2015.

Widok analizy SWOT

Widok analizy SWOT.

Widok celów

Widok celów (z elementem wartości).

Cel i kluczowe wyniki

Wzór OKR.

OKR to popularna strategia zarządzania służąca do definiowania celów i śledzenia wyników. Pomaga tworzyć zgodność i zaangażowanie wokół mierzalnych celów. OKR ma dwa ważne elementy: cel, który chcesz osiągnąć, oraz kluczowe wyniki, które są sposobem pomiaru osiągnięcia celu.

Cel:

• Pamiętana, jakościowa charakterystyka tego, co chcesz osiągnąć. Cele powinny być krótkie, inspirujące i angażujące. Cel powinien motywować i wyzwania zespół.

Kluczowe wyniki:

• Zbiór metryk mierzących postępy w kierunku celu. Powinieneś mieć 2–5 kluczowych wyników dla każdego celu. Nie zbyt dużo, inaczej nikt ich nie zapamięta.

Poniżej przedstawiono inną wersję OKR.

Wzór OKR (2).

Punkt widzenia strategii

Widok warstwy strategii

Widok strategii

Widok strategii.

Wersja ArchiMate 3 obsługuje teraz pojęcia związane z strategią biznesową, takie jak „Kierunek działania”, „Zdolność” i „Zasób”, które mogą być wykorzystywane do modelowania strategii biznesowej organizacji. Wartość i znaczenie tego widoku polegają na tym, że cele organizacji mogą być powiązane z strategią, a także na tym, jak są one powiązane z architekturą przedsiębiorstwa poprzez zdolności. Ten widok może być wykorzystywany do zastosowania „modelowania strategicznego opartego na celach” (Azevedo et al. 2015), w którym cele tworzą hierarchię, dzięki czemu cele najwyższego poziomu mogą być rozłożone na cele niższego poziomu.

Widok strategii biznesowej

Strategia biznesowa.

Widok Modelu motywacji biznesowej (BMM)

Widok Modelu motywacji biznesowej (BMM).

Widok wymagań

Widok wymagań.

Ten widok może być wykorzystywany do zbierania wymagań opartych na celach strategicznych. Łączy strategię z realizacją: strategię można śledzić do wykonania.

Widok strategia do zdolności

Widok strategia do zdolności.

Ten widok może być wykorzystywany np. do celów Planowania opartego na zdolnościach (CBP), a także innych pojęć ArchiMate, takich jak „Wzmacniacz” i „Cel”, jak pokazano na rysunku poniżej. Ten widok może być wykorzystywany do wspierania celów planowania strategicznego (i realizacji). Dlatego ten widok może być wykorzystywany w fazie Strategia do Zdolności, która może być częścią „Strategia do Portfela” w IT4IT.

Widok mapy zdolności

Widok mapy możliwości.

Ten widok może służyć do przedstawienia przeglądu możliwości organizacji: co organizacja robi lub może robić.

Widok planowania możliwości

Widok planowania możliwości.

Ten widok może być używany np. w celu planowania opartego na możliwościach (CBP), tzn. „połączenie strategii z architekturą przedsiębiorstwa”. Widok może być używany np. do mapowania strategii na wymagane możliwości oraz możliwości na zasoby i inne elementy budowlane.

Widok realizacji możliwości

Widok realizacji możliwości.

Widok realizacji możliwości 2

Inny widok definiujący, jak możliwości są realizowane przez które elementy…

Widok realizacji możliwości 2.

Widok strumienia wartości

Widok strumienia wartości (szablon).

Uwaga! „Związanie kierowane” używane na początku łańcucha wartości / strumienia wartości. Strumień wartości może składać się z etapów wartości. Podobnie, ogólny, wysokopoziomowy strumień wartości może być „łańcuchem wartości”, który z kolei składa się z strumieni wartości. Na przykład, IT4IT (link) wprowadza łańcuch wartości składający się z czterech strumieni wartości: Strategia portfela, Wdrożenie popytu, Zaspokojenie żądania, Wykrycie do poprawy (link).

Widok przekładania strumienia wartości na możliwości

Poniżej przedstawiono prosty przykład łańcucha dostarczania wartości. Łańcuchy wartości, sieci wartości i strumienie wartości mogą być modelowane za pomocą elementu ArchiMate Value Stream, zawartego w wersji ArchiMate 3.1.

Widok przykładu łańcucha wartości od idei do produkcji.

Łańcuch dostarczania wartości. Jest to rozszerzony przykład ilustrujący, jak funkcje wspierają (obsługują) strumień wartości. Ten widok może służyć do określenia, co organizacja robi (model biznesowy), dlaczego potrzebne są możliwości oraz jak są one powiązane z tworzeniem wartości.

Ten widok jest zawarty w implementacji referencyjnej frameworku Lean EA (LEAF) (link). Przejdź do „Strumienie wartości”, „Łańcuch dostarczania wartości”.

Widok kanwy modelu biznesowego

Widok modelu biznesowego.

Jest to podstawowa forma kanwy modelu biznesowego A. OsterwalderaKanwa modelu biznesowego (BMC), ale może być dostosowana do sytuacji. Istnieją również wersje, takie jak „Kanwa modelu usług” lub „Kanwa Lean”. BMC może być używane np. do projektowania modelu biznesowego i innowacji.

Modelowanie BMC za pomocą ArchiMate „umożliwia śledzenie wymagań od potrzeb biznesowych do specyfikacji projektowych. Pomaga odkryć wpływ zmian modelu biznesowego na projekt architektury.” [LO Meertens et al.]

Ogólny rozwój obejmuje wbudowaną obsługę architektoniczną analizy strategii i modelu biznesowego. Pozwala to analitykom biznesowym i programistom obserwować np. jak model biznesowy wspiera strategię oraz jak model biznesowy dostosowuje się do organizacji, i odwrotnie.

Jeśli BMC jest modelowany w narzędziu modelowania, zaletą tego podejścia jest możliwość wykorzystania wszystkich elementów BMC w innych widokach w tym samym repozytorium modeli. Gdy model biznesowy jest zmieniany, wszystkie zmiany są od razu widoczne. Modelerzy biznesowi mogą tworzyć nowe elementy (np. usługi) lub wykorzystywać wszystkie istniejące elementy w repozytorium (np. jednostki organizacyjne lub zasoby).

Widok Kanwa koncepcyjny

Kanwa koncepcyjna. BMC może mieć różne warianty, jak pokazano na poniższym rysunku. Układ tej kanwy koncepcyjnej jest zgodny z warstwowym podejściem ArchiMate.

Punkt widzenia biznesowego

Widok warstwy architektury biznesowej.

Widok mapy usług biznesowych

Widok usług biznesowych.

Ten widok zapewnia przegląd usług biznesowych organizacji. Ten widok może być używany jako „katalog usług” lub „portfel usług” dla zarządu. Bardzo ważne jest określenie, jakie usługi organizacja oferuje swoim klientom. Dodatkowo usługi biznesowe są punktem wyjścia do modelowania wszystkich podstawowych procesów i struktur organizacyjnych. Dlatego usługi biznesowe są jednymi z najważniejszych elementów architektury przedsiębiorstwa.

Widok mapy procesów biznesowych

Widok procesów biznesowych.

Ten widok może być używany jako „mapa procesów”, która zapewnia przegląd procesów biznesowych organizacji.

Widok współpracy procesów biznesowych

Widok współpracy procesów biznesowych.

Ten widok może być używany np. do modelowania modeli działania.

Widok mapy aktorów biznesowych

Widok aktorów biznesowych.

Aktorzy biznesowi mogą być a) wewnętrzni lub b) zewnętrzni. Wewnętrzni aktorzy biznesowi to np. jednostki organizacyjne, a zewnętrzni aktorzy biznesowi to np. klienci, partnerzy biznesowi lub inne grupy interesariuszy współpracujące z organizacją (np. organizacje sektora publicznego lub inne organy zarządzające).

Widok współpracy aktorów biznesowych

Widok współpracy aktorów biznesowych.

Dwa przypadki użycia to:

1. Widok wewnętrzny przedsiębiorstwa: punkt widzenia współpracy aktorów biznesowych opisujący sposób, w jaki wewnętrzni aktorzy biznesowi współpracują i wymieniają informacje.
2. Widok międzyorganizacyjny: punkt widzenia ekosystemu przedstawiający środowisko działania organizacji. Ekosystem to sieć organizacji i partnerów biznesowych, które współpracują poprzez interakcje wspólne. Są tu dostawcy, podwykonawcy i inni partnerzy B2B, klienci itd.

Widok procesu biznesowego

Widok procesu biznesowego.

Ten widok procesu biznesowego zapewnia „strukturę i składniki najwyższego poziomu jednego lub kilku procesów biznesowych (lub ich części), w których są świadczone usługi, aktorom przypisane są role, a informacje są wykorzystywane przez procesy biznesowe” [specyfikacja ArchiMate 2.1]. Diagram procesu zawiera elementy „Przecięcie”, używane do modelowania „rozgałęzienia” i „połączenia” w przebiegach procesów.

Poniżej przedstawiono widok procesu najwyższego poziomu. Jest on oparty na modelu działania wyprowadzonym z modelu biznesowego, jak pokazano na wyżej przedstawionym diagramie przepływu wartości.

Proces od idei do produkcji.

SIPOC (Dostawcy, Wejścia, Proces, Wyjścia, Klienci)

SIPOC.

Narzędzie Six Sigma o nazwie SIPOC (Dostawcy, Wejścia, Proces, Wyjścia, Klienci) może być używane do definiowania elementów wspólnych dla wszystkich procesów. Jest to proste narzędzie do analizy przypadków biznesowych: jaką wartość otrzymuje klient i jak ją otrzymuje.

Widok procesu biznesowego z rolami biznesowymi jako „korytami procesów” – podejście warstwowe

Widok koryt procesu biznesowego (szablon) 2.0.

„Rola biznesowa A” reprezentuje klienta, podczas gdy najwyżej położone „koryto” reprezentuje trasę przejścia klienta.

Uwaga! Krokii procesu (działania) są zagnieżdżone w rolach biznesowych (wizualizowane jako „korytka”), co oznacza: te role biznesowe są przypisane do tych procesów biznesowych/kroków procesu. Dlatego ten widok jest połączeniem widoku procesu biznesowego i widoku warstwowego.

Wersja poniżej ilustruje przepływy informacji i danych (relacje przepływu). Najwyższe „koryto” reprezentuje trasę przejścia klienta (działania powiązane relacjami wyzwalającymi).

Widok koryt procesu biznesowego (szablon) 2.0 (przepływ informacji).

Wersja poniżej przedstawia podejście do projektowania usług. Najwyższe „koryto” (Rola A) reprezentuje trasę przejścia klienta, która jest połączona z organizacją (Role B i C) poprzez usługi biznesowe (1 i 2).

Widok koryt procesu biznesowego (szablon) 2.0 (usługi).

Widok warstwowy procesu biznesowego

Widok warstwowy procesu.

Ten widok może być używany do modelowania procesów biznesowych, które zawierają zarówno kroki ręczne, jak i zautomatyzowane.

Widok mapy trasy przejścia klienta

Podczas analizy tras przejścia klienta na wysokim poziomie, ta wersja jest tworzona za pomocą elementów motywacji i strategii.

Mapa trasy przejścia klienta (na wysokim poziomie).

Podczas szczegółowej analizy ścieżek obsługi klienta, ta wersja jest tworzona za pomocą elementów warstwy biznesowej i warstwy aplikacji (jądro).

Widok trasy przejścia klienta (przykład) 1.0.

Ten widok skupiony na kliencie skupia się na doświadczeniu klienta. Ten podejście „od zewnątrz do środka” związane z „projektowaniem usług” podkreśla istotny aspekt, że usługi i produkty są tworzone w celu dostarczania wartości klientom – a pośrednio również organizacji. Trasy przejścia klienta mogą być wykorzystywane do wizualizacji strumieni wartości klientów obejmujących wiele usług aplikacji i aplikacji.

Widok szkicu usługi

Widok szkicu usługi 1 (usługi i przepływy)

Ten widok jest skupiony na kliencie i usłudze, ale również podkreśla aspekt „wewnętrzny” usługi. Dzięki temu podejściu rozwój oparty na usłudze może identyfikować potencjalne wpływy behawioralne i strukturalne na usługi do zaprojektowania. Dlatego ten widok uzupełnia podejście oparte na doświadczeniu klienta poprzez aspekty procesowe i funkcjonalne.

Ten widok ma kilka wariantów. Przykład powyżej skupia się na przepływach informacji między warstwami i elementami.

Widok historii użytkownika

Widok historii użytkownika.

Ten widok może być używany do wizualizacji historii użytkownika.

Widok modeli usług chmury

Widok modeli usług chmury.

Widok informacji

Widok informacji.

Informacje mogą być modelowane na różnych poziomach abstrakcji w następujący sposób: a) poziom koncepcyjny, b) poziom logiczny i c) poziom fizyczny. Rysunek powyżej ilustruje te poziomy abstrakcji.

Widok modelu danych koncepcyjnych

Widok modelu danych koncepcyjnych.

Architektura informacji EA obejmuje obiekty biznesowe wykorzystywane w procesach biznesowych, tzn. pojęcia. Te pojęcia i ich relacje mogą być przedstawione w modelu danych koncepcyjnych.

Pojęcie „usługa”

Pojęcie usługi.

Pojęcie usługi często stanowi problem i może być rozumiane na wiele różnych sposobów. Aby jasno rozróżnić rodzaje usług, warto podawać prefiks: usługa biznesowa, usługa aplikacji lub usługa technologiczna. Zgodnie z ITIL usługi IT odnoszą się do usług produkcyjnych. Tak. Usługi IT najbardziej ściśle odpowiadają usługom aplikacji.

Usługa w porównaniu do produktu

Widok produktu.

Pojęcie produktu może być używane jako element złożony do grupowania usług. Zgodnie z specyfikacją ArchiMate:

„Produkt reprezentuje zbiór spójnych usług i/lub elementów struktury pasywnej, towarzyszących zestawowi umów, oferowanych jako całość klientom (wewnętrznych lub zewnętrznych).”

„Produkt może agregować lub składać usługi biznesowe, usługi aplikacji i usługi technologiczne, obiekty biznesowe, obiekty danych i obiekty technologiczne, a także umowy. W związku z tym produkt może agregować lub składać elementy z warstw innych niż warstwa biznesowa.”

„Wartość może być przypisana do produktu. Nazwa produktu to zazwyczaj nazwa używana w komunikacji z klientami, albo może to być bardziej ogólna nazwa (np. „ubezpieczenie podróżne”).”

Punkt widzenia aplikacji

Widok warstwy architektury aplikacji.

Widok mapy usług aplikacji

Widok usług aplikacji.

Widok mapy aplikacji

Widok mapy aplikacji.

Portfel aplikacji, w którym aplikacje mogą być grupowane według jednostki biznesowej.

Widok współpracy aplikacji (przepływy danych)

Widok współpracy aplikacji.

Widok integracji aplikacji (relacje dynamiczne)

W poniższym przykładzie pokazano kilka alternatywnych sposobów modelowania przesyłania danych między aplikacjami (1 do 10).

• „Aplikacja A” posiada obiekt danych „A-1”, który jest żądany przez „Aplikację B”.
• Dane przepływają z „Aplikacji A” do „Aplikacji B”.
• „Aplikacja A” realizuje usługę „A-1”, która jest używana przez „Aplikację B”.
• W praktyce „Aplikacja B” żąda interfejsu aplikacji „A-1” i otrzymuje odpowiedź…

Widok integracji aplikacji.

Widok struktury aplikacji

Ten widok pomaga projektować lub zrozumieć główną strukturę aplikacji oraz jej podkomponenty i powiązane dane. Diagram może być używany do rozkładania struktury systemu aplikacji w budowie w celu ilustracji modułowości/rozkładania: jakie są podsystemy/podkomponenty, jakie usługi aplikacji (lub interfejsy aplikacji) oferują.

Widok struktury aplikacji.

Zauważ, że usługi aplikacji (na rysunku górnym) to funkcjonalności zachowaniowe zapewniiane przez interfejsy strukturalne (interfejsy GUI i/lub API na rysunku dolnym). Usługi aplikacji i interfejsy aplikacji to „dwie strony tej samej monety”.

Widok struktury aplikacji 2.

Widok architektury aplikacji

Ten widok łączy podejścia poziomu EA i poziomu rozwiązania, ponieważ zarówno aplikacje, jak i moduły aplikacji istnieją w tym samym widoku.

Architektura aplikacji.

Model składników aplikacji (CM)

Model składników aplikacji 0-n to metoda modelowania architektury aplikacji składająca się z diagramów na różnych poziomach abstrakcji, jak poniżej:

• Na poziomie CM-0 diagram opisuje, jak aplikacja docelowa współdziała ze środowiskiem oraz jakie istnieją interakcje z sąsiednimi aplikacjami i użytkownikami. Aplikacja docelowa jest opisywana jako czarna skrzynka.
• Na poziomie CM-1 aplikacja docelowa jest rozkładana na moduły (główne komponenty), a także określone są usługi aplikacji (lub interfejsy aplikacji), które te moduły dostarczają i wymagają. Aplikacja docelowa jest opisywana jako biała skrzynka.
• Na poziomie CM-2 moduły są rozkładane na podkomponenty. (Liczba poziomów potrzebnych zależy od sytuacji.)

Diagram Modelu składników aplikacji (CM) poniżej składa się z komponentów aplikacji i usług aplikacji. Alternatywnie, zamiast usług aplikacji można użyć interfejsów aplikacji, w zależności od sytuacji. Zawsze ważne jest stosowanie stylu modelowania dopasowanego do celu i modelowanie tylko tych elementów, które dostarczają wystarczającą ilość informacji i dodają wartość. To zależy od modelera — czy chce on podkreślić aspekty funkcjonalne, czy być bardziej szczegółowym i modelować np. rzeczywiste interfejsy z dokładnymi nazwami.

Diagram modelu składników poniżej składa się z komponentów aplikacji i usług aplikacji. Alternatywnie, zamiast usług aplikacji można użyć interfejsów aplikacji.

Model składników aplikacji – 0 (CM-0)

Model składników aplikacji – 0.

Poziom Modelu składników – 0 (CM-0) (powyżej) ilustruje interakcje między aplikacją docelową a sąsiednimi aplikacjami. Wprowadzane są wszystkie istotne usługi aplikacji (lub interfejsy aplikacji). Diagram poziomu 0 składa się z komponentów warstwy architektury przedsiębiorstwa i ich usług, z aplikacją docelową pośrodku.

Model składników aplikacji – 1 (CM-1)

Model składników aplikacji – 1.

Poziom Modelu składników – 1 (CM-1) (powyżej) ilustruje, jak aplikacja docelowa jest rozkładana na moduły (lub główne komponenty), oraz jakie usługi aplikacji (lub interfejsy aplikacji) realizuje każdy moduł. Uwaga! Aplikacje zewnętrzne mogą być pominięte na tym poziomie, ale ich usługi (lub interfejsy) są pokazywane. Gdy pokazuje się więcej elementów niskiego poziomu, więcej elementów wysokiego poziomu można/muszą być pominięte – dla uproszczenia: utrzymaj diagram czytelny.

Model składników aplikacji – 2 (CM-2)

Model składników aplikacji – 2.

Poziom Modelu składników – 2 (CM-2) (powyżej) ilustruje, jak moduły aplikacji docelowej składają się z podkomponentów i jak się wzajemnie oddziałują.

Widok funkcji aplikacji

Rozkład funkcji aplikacji: jakie funkcje zawiera system i jakie usługi aplikacji oferuje?

Widok funkcji aplikacji.

Widok procesów aplikacji

Widok procesów aplikacji.

Widok procesów aplikacji – zagnieżdżanie.

Widok procesów aplikacji – wewnętrzne.

Widok diagramu sekwencji składników aplikacji

Diagramy sekwencyjne nie są całkowicie w zakresie ArchiMate, ale w zakresie UML. Można jednak modelować np. sekwencję działań podjętych przez elementy aplikacji za pomocą ArchiMate, jak pokazano poniżej.

Widok sekwencji aplikacji.

Relacje dynamiczne „Wyzwania” i „Przepływ” mogą być używane do modelowania dynamiki między elementami aplikacji. Układ tego widoku może przypominać pozycjonowanie diagramu sekwencji UML.

Widok diagramu sekwencji elementów aplikacji 2

Ta wersja (poniżej) ilustruje, jak ArchiMate może być używane do modelowania sekwencji działań podjętych przez wewnętrzne części elementów aplikacji. Wewnętrzne części to np. a) procesy lub funkcje zachowaniowe i b) podkomponenty strukturalne. Są one modelowane za pomocą elementów Proces aplikacji, Funkcja aplikacji i Element aplikacji. Są one tutaj pokazane jedynie jako alternatywy.

Widok sekwencji aplikacji (2).

Przepływ operacji w tym diagramie sekwencji (powyżej):

1. Podproces „X” elementu aplikacji „A” wysyła komunikat z prośbą z parametrem „A” do aplikacji B.
2. Podproces „B-1” elementu aplikacji „B” odbiera przychodzące żądanie, a następnie (synchronicznie) wywołuje element aplikacji C, gdzie Funkcja aplikacji „Y” odbiera żądanie, wykonuje pewne operacje i odpowiada.
3. Inny podproces „B-2” elementu aplikacji „B” wysyła komunikat z parametrami do elementu aplikacji D i otrzymuje potwierdzenie. Element aplikacji „D” zawiera podkomponenty, które wykonują przetwarzanie.
4. Element aplikacji „A” otrzymuje komunikat odpowiedzi od elementu aplikacji B.

Jak pokazano tutaj, możemy modelować dość skomplikowane przypadki integracji, łącząc te elementy (elementy aplikacji, procesy aplikacji i funkcje aplikacji oraz relacje (Wyzwania, Przepływ)). Diagramy sekwencji UML mają swoje specjalizowane zastosowanie w projektowaniu oprogramowania, ale ArchiMate może być wykorzystywany do wielu celów modelowania – również do projektowania aplikacji.

Integracja aplikacji jest jednym z najważniejszych elementów Architektury Przedsiębiorstwa (EA). Dlatego warto, abyśmy mogli szczegółowo modelować, jak aplikacje wymieniają dane i jakie mechanizmy interakcji są wykorzystywane. Dobrym źródłem do głębszego zrozumienia wzorców integracji jest książka „Enterprise Integration Patterns”, oto link.

Ostateczna sekwencja użytkownika dodana (poniżej) opiera się na tej samej idei wykorzystania dynamicznych relacji ArchiMate – Wyzwania i Przepływ – które mogą być używane do modelowania synchronicznych i asynchronicznych wzorców komunikacji (zapytanie-odpowiedź i wywołanie zwrotne, a także publikacja-subskrypcja itp.).

Widok wzorców sekwencji.

Widok procesu ETL

Widok procesu ETL.

Widok EAI / ESB

Widok wzorców EAI – ESB.

Widok warstwowy

Widok warstwowy.

Widok warstwowy może być używany jako diagram kontekstowy przeglądowy obszaru docelowego. Główną zaletą tego widoku jest ilustrowanie wykorzystania aplikacji w procesach biznesowych i usługach, które oferują. Na powyższym rysunku użyto elementu grupowania ArchiMate do modelowania różnych warstw, a na rysunku poniżej użyto elementu grupowania wizualnego dostarczanego przez narzędzie (Archi).

W ArchiMate istnieją zasadniczo trzy (3) warstwy: 1) warstwa biznesowa, 2) warstwa aplikacji i 3) warstwa technologiczna. Ich kolory zwykle są następujące: warstwa biznesowa to żółta, warstwa aplikacji to turkusowa, warstwa technologiczna to zielona (patrz ArchiMate Core Framework, link).

Widok warstwowy.

Widok aplikacji i baz danych

Bazy danych są istotną jednostką w globalnej architekturze przedsiębiorstwa. Na przykład „Baza danych klientów” lub „Baza danych klientów”, „Baza danych produktów” itd. Alternatywnie, baza danych może obejmować wszystkie tabele aplikacji (np. „Tabela klientów”, „Tabela zamówień”, „Tabela faktur” itd.), które razem tworzą jedną bazę danych. Zgodnie z specyfikacją ArchiMate obiekt danych może być używany do modelowania logicznych baz danych (rysunek poniżej), rozdział 9.4.1 „Obiekt danych” mówi: „Typowe przykłady obiektów danych to rekordy klientów, bazy danych klientów lub reklamacje ubezpieczeniowe.” „Ważną wyjątkiem jest sytuacja, gdy obiekt danych służy do modelowania zbioru danych, takiego jak baza danych, w której istnieje tylko jeden egzemplarz.” ArchiMate posiada elegancką wbudowaną mechanizm, który pozwala na używanie niektórych pojęć na różnych poziomach abstrakcji (i szczegółowości). Dlatego na przykład obiekt danych może być używany do modelowania logicznych baz danych, tabel baz danych, struktur komunikatów (przekazywanych między aplikacjami) itd.

Uwagi dotyczące modelowania baz danych.

Baza danych jako składnik aplikacji.

Poziomy abstrakcji bazy danych.

Widok modelu danych.

Widok przypadków użycia

ArchiMate może być używane do analizy przypadków użycia z perspektywy funkcjonalnej aplikacji. Przypadki użycia (znane z UML) mogą być mapowane na usługi aplikacji, jak pokazano na rysunku poniżej.

Widok przypadków użycia (schemat 1).

Przypadki użycia mogą być podzielone na: a) przypadki użycia biznesowe i b) przypadki użycia systemowe (tzw. przypadki użycia systemowe). Rysunek poniżej ilustruje, jak „główne przypadki użycia” są modelowane jako usługi biznesowe, a kolejne przypadki systemowe jako usługi aplikacji.

Widok przypadków użycia (przykład).

Gdy przypadki użycia są identyfikowane jako usługi aplikacji, mogą być dalej wykorzystywane jako elementy funkcjonalne aplikacji docelowej w innych diagramach (np. w widokach warstwowych). Innymi słowy: usługi aplikacji reprezentują zachowanie (funkcjonalność) aplikacji. Aby uzyskać więcej szczegółowych informacji na temat analizy przypadków użycia, zobacz ArchiMate Cookbook, link.

Punkt widzenia technologiczny

Widok warstwy architektury technologicznej.

Widok infrastruktury

Ten widok reprezentuje platformę aplikacji. Ten schemat może być używany do modelowania konfiguracji środowiska uruchomieniowego oraz wdrażania aplikacji biznesowych.

Widok infrastruktury.

Widok infrastruktury (zagnieżdżony).

Widok warstwy wdrożenia i migracji / warstwy architektury przejściowej

Widok planu wdrożenia

Widok planu wdrożenia.

Widok tablicy Kanban

Tablica Kanban (EA).

Kanban może być używany do wizualizacji pracy i przepływu pracy. Kanban pokazuje np. jak wymagania rozwojowe, epiki, historie użytkownika itd. przepływają z listy zadań do stanu gotowości (ukończone). Kanban może być stosowany w różnych celach w zależności od skali i zakresu przypadku rozwojowego. Na przykład „epiki” mogą być używane na poziomie EA, a „historie użytkownika” lub „wymagania” na poziomie projektu. Szczegółowość zadań może się różnić w zależności od sytuacji.

Widok ogólny

Widok ogólny.

Ten uproszczony widok może być używany np. jako diagram kontekstowy dla konkretnej usługi, programu lub projektu.

Dodatkowe funkcje

Omówienie kontekstu – mapa Drodzy Mlecznej

Jest to podejście do wizualizacji jak najwięcej w tym samym widoku. Aby uzyskać więcej informacji, zobacz Mapę Drodzy Mlecznej dla ArchiMate,link.

FM Mapa Drodzy Mlecznej (poziom 2). (Uwaga! Ten schemat kolorów używa domyślnych kolorów ArchiMate. Można użyć dowolnych innych kolorów, jeśli to konieczne.)

Widok współpracy

Warstwy można łączyć, jak pokazano na przykładzie diagramu przepływu danych poniżej.

Widok współpracy aplikacji (rozszerzony).

Metamodel

Metamodel.