Analiza biznesowa to dość duże wyzwanie. Nie polega tylko na zapisaniu z pomocą wywiadów tego, co firma robi. Chodzi o zrozumienie tego co dana firma robi i po co to robi. Powoli coraz więcej się mówi o modelach i notacjach. Stały się wręcz modne (bo, że pomagają to już wiadomo). Jednak celem analizy nie jest opracowanie modeli procesów, te są tylko narzędziem osiągania celu. Celem analizy jest odkrycie i wskazanie tego, co i na co ma wpływ w modelowanej organizacji.

Niejako standardem w projektach związanych z oprogramowaniem, są ostatnio notacje: BPMN na etapie tworzenia modeli biznesowych i notacja UML  na etapie projektowania oprogramowania (całego systemu). Od dłuższego czasu spotykam się z pewnymi ograniczeniami obu tych notacji.

W jednym z poprzednich  artykułów napiałem:

Na poziomie procesów biznesowych, stosuję zamiennie BPMN albo ArchiMate.  Z każdym kolejnym projektem skłaniam się jednak do używania na tym poziomie ArchiMate. Powodem jest to, że BPMN oferuje wyłącznie czyste pojęcia z definicji wykonawczej procesu (czynność, dane, zdarzenie, rola, pula, bramki). Na tym poziomie jednak, nie raz należy wyrazić rozdzielnie takie pojęcia jak rola i aktor (np. klient i kontrahent mogą pełnić rolę zamawiającego w procesie) albo pojęcia takie jak funkcje biznesowe (aktor wraz z zasobami jakich używa, pełni funkcję administracji wewnętrznej) albo usługi powiązanej z procesami (proces sprzedaży powiązany z usługą obsługi klienta). Przykłady można mnożyć. (Co jest wadą większości analiz biznesowych?).

Od czasu do czasu jestem pytany jak reprezentować System (oprogramowanie analizowane lub projektowane) na modelach BPMN. Niestety notacja ta nie ma takiego odrębnego pojęcia w swojej przestrzeni pojęciowej. Najczęściej spotykanym sposobem zobrazowania systemu na modelu procesu jest użycie dedykowanego toru (lane) dla zobrazowania oprogramowania i umieszczanie w nim czynności wykonywanych przez (z użyciem) oprogramowanie (od tej metody odszedłem kilka lat temu). Inna metoda to oznaczanie czynności związanych z użycie systemu stereotypem przypadek użycia (tę nadal stosuję). Pierwsza metoda moim  zdaniem łamie definicje roli w procesie. Jeżeli jakaś czynność jest realizowana przez osobę (aktora) używającą do pracy oprogramowania, pojawia się problem: co jest tu modelowane i gdzie się podział aktor skoro tor to system. Drugi sposób to użycie możliwości programu CASE użytego do analizy i niestandardowego wzbogacenia notacji o pojęcie stereotypu, którego formalnie BPMN nie ma. Jedno i drugie kłóci się także z modelowaniem etapu CIM ([[Computation Independent Model]]).

Jak już nie raz podkreślałem, siła formalnych notacji leży w ich bardzo dobrze opracowanym słowniku pojęć i relacji między tymi pojęciami. Łamanie tych zasad powoduje, że tak wykonana analiza staje się ryzykowna, gdyż pozwala na wprowadzanie niejednoznaczności w modelach.

Jednak problem istnieje… powstała notacja

ArchiMate

Notacja powstała w Telematica Institute, zyskała sobie własną tożsamość jako ArchiMate, została “wchłonięta” pod skrzydła The Open Group. Specyfikacja 1.0 powstała w 2004 roku więć notacja została już dość dobrze “przećwiczona”. Z niszowej stała się standardem. Obecnie stanowi oficjalne narzędzie modelowania w projektach na bazie metodyki TOGAF:

(źr. www.archimate.nl, obecnie TOGAF 9 i Archimate v.2.0; poprzednia ArchiMate v.1.0 zawierała tylko pojęcia z zakresu warstw biznesowej, aplikacji i technologii, pola zakreślone ukośną linią to rozszerzenie wprowadzone w wersji 2.0).

Ważne jest to, że notacja ta swoimi pojęciami biznesowymi, opisuje (modeluje) organizacje przekrojowo. W ramach systemu pojęciowego ArchiMate mamy trzy grupy pojęć dla trzech warstw modeli:

Jak widać słownik pojęć w warstwie biznesowej jest znacznie bogatszy niż w notacji BPMN. Każde pojęcie ma ściśle zdefiniowane znaczenie a znaczenia te (zasięg ich definicji) oczywiście nie zachodzą na siebie. Co nam to daje? Możliwe jest przeprowadzenie bardzo wnikliwej analizy logiki procesów biznesowych, skojarzenie jej z usługami systemu, jego funkcjonalnością i metodami implementacji. Czy ArchiMate zastępuje BPMN czy UML? Nie, ale pozwala uniknąć ich nadużywania i nadrabia ich braki w sferze biznesowych modeli abstrakcyjnych.

Jak już pisałem BPMN i UML to notacje, które powstały w celach “inżynierskich” tu, w inżynierii oprogramowania, są raczej bezkonkurencyjne.  Jednak są, moim zdaniem, zbyt ubogie i mało zrozumiałe do modelowania złożoności biznesowej. Pokażę to na przykładzie modelu procesu sprzedaży. Załóżmy, że w toku analizy udokumentowaliśmy proces fakturowania wraz z tym kto fakturuje, fakturą jako dokumentem i danymi. Chcemy następnie opracować specyfikację  usług, jakie planowany system miałby realizować, przyporządkować logicznie poszczególne usługi do grup (funkcjonalność systemu). Na koniec zaprojektować architekturę systemu.

Jak wspomniałem poprzednio, problem rozwiązuje stosowanie języka (notacji) adekwatnego do problemu. Tu pokażę przykład jak notacja ArchiMate radzi sobie z problemem łączenia biznesu, oprogramowania i technologii:

A gdzie BPMN i UML? Ano każdy proces (przyjęcie zamówienia, kompletacja, fakturowanie) w kontekście szczegółów przepływu pracy, modelowany byłby w notacji BPMN (konkretne role, dokumenty, czynności). Pozostałe warstwy operują pojęciami, których szczegóły  można (należy jeżeli taki jest zakres projektu) modelować już w notacji UML. Usługi mapują się na przypadki użycia, pozostałe to architektura: komponenty oprogramowania, dane, architektura techniczna.

Jak widać, ArchiMate pozwala na tym poziomie abstrakcji na więcej niż same BPMN czy UML, ale też nie zastępuje ich. Wzbogaca także system pojęciowy na potrzeby analizy biznesowej co pozwala wiernie odtworzyć rzeczywistość biznesową w sposób zrozumiały dla “biznesu”.  Jako podsumowanie przytoczę jeszcze raz znany już tu diagram:

(jak tworzyć modele ArchiMate  z pomocą narzędzia Agilian).

O architekturze korporacyjnej w kontekście analizy i projektowani innym razem. Teraz tylko kilka korzyści z posiadania takiego modelu:

  1. możliwość wywodzenia wymagań na oprogramowanie w modelu biznesowego,
  2. możliwość analizy wpływu i zależności usług biznesowych od infrastruktury IT (projekty związane z analizą ciągłości działania organizacji),
  3. możliwość prowadzenia przekrojowych analiz ryzyka.

Więcej na temat samej Architekturze Korporacyjnej na stronie ArchitekturaKorporacyjna.pl, którą gorąco polecam.

Zainteresowanym notacją ArchiMate i jej używaniem polecam stronę ArchiMate Good practices.

___

P.S. Z uwagi na wady semantyczne notacji ArchiMate i rozpoczęcie przez The Open Group jej licencjonowania zarzuciłem stosowanie tej notacji (2012). Nadal udzielam konsultacji w zakresie recenzowania modeli wykonanych w tej notacji.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Ostatnie komentarze i interpretacje wypowiedzi prawników The Open Group zmierzają do tezy, że notacja, nazwa itp. są objęte jednak ochrona i wymagają opłat dla komercyjnego stosowania… źle to wygląda…

    1. Jarek Żeliński

      Zakusy na zyski z licencji i certyfikacji i ograniczanie dostępu do specyfikacji ArchiMate nieco mnie zniesmaczyły. Przyznaję, że rezygnuję z tej notacji jak i z TOGAF’a jako metodyki. W dwóch projektach sprawdziła się moja hipoteza: modelowanie i analiza warstwy biznesowej i IT oraz ocena wzajemnych zależności nie wymaga nowej notacji a dobrze wykonanego modelu, wystarczą BPMN, UML oraz narzędzie potrafiące zarządzać relacjami pomiędzy obiektami na tych modelach… zaryzykuję tezę, że jest to efektywniejsze niż tworzenie kolejnych dziesiątek diagramów ArchiMate.

  2. Piotr

    Witam
    To mój pierwszy komentarz. Przywitać się chciałem i podziękować w imieniu żółtodziobów za dzielenie się swoją wiedzą.

    Ostatnio dosyć aktywnie śledzę Pana artykuły w szczególności metody pracy i narzędzia. I tu się zagubiłem w chronologii wydarzeń. W kilku artykułach na tej stronie była mowa o ArchiMate i jego miejscu w analizie na przykładzie piramidy (był wtedy na czubku). Teraz czytam, że ze względów (między innymi) licencyjnych porzuca Pan stosowanie tej notacji. Czy ten stan rzeczy jest aktualny (czyli aktualna piramida miała by na wierzchołku BPMN)? Innymi słowy duet BPMN/UML nadal broni się dzielnie mimo swoich niedoskonałości?

    P.

    1. Jaroslaw Zelinski

      ArchiMate zarzuciłem z powodów licencyjnych, niestety braku spójności tej notacji, jest to nisza więc dodatkowo użycia ArchiMate drastycznie zawęża pule możliwych odbiorców. “Piramida” od góry :): BMM, BPMN, UML. Tu uwaga: BPMN to procesowy paradygmat analizy i modelowania organizacji, UML to obiektowy paradygmat modelowania systemów (nie tylko IT).

      Z tymi niedoskonałościami bym nie przesadzał, bo jakie one są (poza tym, że jak każdego języka trzeba się dobrze nauczyć w mowie i piśmie :)) ?

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.