ArchiMate a przypadek użycia

Tworząc modele architektoniczne możemy stosować do tego celu różne języki. Z badań, które przeprowadziłem w zeszłym roku najpopularniejszy w Polsce w dalszym ciągu jest  język UML (stworzony przez OMG), coraz częściej zaczyna być również stosowany ArchiMate (stworzony przez The Open Group). W praktyce spotykam się również z taką kombinacją: na poziomie architektury strategicznej i segmentów (obydwa te pojęcia wprowadza TOGAF) stosowany jest ArchiMate, zaś na poziomie architektury potencjału/rozwiązania – UML. Pojawia się tutaj jednak kwestia jak łączyć takie modele.

Oczywiście zawsze można powiedzieć, że taką “integrację” umożliwia narzędzie informatyczne. Czyli w jednej bazie mamy gromadzone modele stworzone w różnych językach (np. w Sparx Enterprise Architect bezproblemowo obsłuży połączenie ArchiMate – BPMN [do uszczegółowienia procesów w architekturze biznesowej] – UML [do uszczegółowienia architektury aplikacji]).

Zupełnie innym poziomem “integracji” jest próba dokonania mapowania poszczególnych obiektów tych języków między sobą. Ostatnio prowadziłem dyskusję “skąd biorą  się przypadki użycia”  – tj. z jakich elementów ArchiMate można je “wywieść”.

Chwilę trwało, zanim doszedłem z rozmówcą do konsensusu – bo jak zwykle diabeł tkwił w szczegółach. On myślał o “biznesowych przypadkach użycia” (business use case), a ja o systemowych przypadkach użycia (system use case).

Dla porządku przytaczam obydwie definicje tych pojęć:

• Biznesowy przypadek użycia – reprezentuje funkcje dostarczane przez organizacje; opisuje on proces biznesowy z punktu widzenia zewnętrznej, dodanej wartości; biznesowe przypadki użycia to procesy biznesowe, które przecinają granice organizacji, obejmując ewentualnie partnerów i dostawców, aby zapewnić wartość dodaną organizacji (definicja przytoczona za M. Wolski).
• Systemowy przypadek użycia (puryści używają określenia: przypadek użycia) –  interakcja pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem w postaci określonej sekwencji kroków. Przypadek użycia powinien opisywać w jaki sposób system jest używany przez aktora, aby umożliwić mu realizację konkretnego celu.

Stosunkowo łatwo można dokonać mapowania obiekt ArchiMate – systemowy przypadek użycia. Proponuję, aby po stronie ArchiMate używać obiektu “usługa aplikacji” (application service), która  jest zdefiniowana w tym standardzie, jako usługa udostępniająca [warstwie biznesowej – przypis A.S.] zautomatyzowane zachowanie. W zależności do poziomu modeli architektonicznych tworzonych w ArchiMate (tj. architektura strategiczna/segmentów) usługa aplikacji może być zdekomponowana na 1…n systemowych przypadków użycia.

Zupełnie inaczej wygląda mapowanie obiekt ArchiMate – biznesowy przypadek użycia. Tutaj jest o wiele trudniej dokonać takiego przyporządkowania, gdyż w samej definicji biznesowego przypadku użycia następuje odwołanie do procesu, funkcji oraz wartości. W ArchiMate są to oddzielne obiekty – czyli proces biznesowy, funkcja biznesowa, wartość.

Ze względu jednak na fakt, że dla mnie sednem jego definicji jest zwrot: “z punktu widzenia zewnętrznej, dodanej wartości […] organizacji”, sugeruję aby mapować go na usługę biznesową (business service), którą ArchiMate definiuje jako: “usługę, która zaspokaja potrzebę biznesową klienta”. Czyli jednej usłudze biznesowej będzie najczęściej odpowiadał jeden biznesowy przypadek użycia.