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.