Badanie przydatności TOGAF/ArchiMate mam chyba za sobą (zapewne nie na miarę doktoratu ale troszkę jednak tak, chociaż…;)).  Na stronie mojego kolegi: ArchitekturaKorporacyjna.pl (polecam analitykom),  w jednym z artykułów pojawia się ciekawe stwierdzenie:

TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu [biznesowego, jak sądzę] z aplikacją go wspierającą ? elementem pośrednim powinna być funkcja ? czyli: aplikacja wspiera realizację funkcji, a funkcja obejmuje cały proces lub jego fragment (w zależności od poziomu dekompozycji funkcji biznesowej). (Komentarze do TOGAF ? metamodel zawartości (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierwsze mnie zraziło w notacji ArchiMate: przerost pojęciowy (rozdrobnienie albo jak kto woli nadmierna gradacja). Umieszczenie dodatkowego pojęcia – funkcja – pomiędzy procesem biznesowym (pamiętamy, że samodzielna czynność to także proces) a narzędziem pracy jakim jest oprogramowanie wydaje się sztuczne. To troszkę jak umieszczenie pomiędzy młotkiem a procesem wbijania gwoździa funkcji “wbijanie”, nie wiem jaką wartość wnosi to do modelu, skoro młotek ma funkcję (przypadek użycia) “wbijanie” (pamiętajmy, że oprogramowanie to narzędzie pracy aktora, zasób).

Prowadzi to do niekompatybilności z systemem pojęciowym paradygmatu obiektowego (MDA/OMG), na który ArchiMate się powołuje, tym bardziej, że jednak MDA to standard procesu obiektowego tworzenia oprogramowania więc po co z nim walczyć? Testowałem modele ArchiMate “na ludziach” i okazywało się, że dla wielu z nich także są one nieintuicyjne. Trudno mi też wytłumaczyć ten nadmiar pojęciowy:  skoro “w  naturze” czynność jest wspierana “usługą systemu” to po co pakować między nie, między tę “wódkę a zakąskę” ;), pojęcie biznesowej funkcji oprogramowania skoro ono świadczy jakąś usługę, bo jest ona funkcjonalnością tego oprogramowania.

Autorzy ArchiMate wskazują, że tam gdzie ArchiMate jest zbyt ogólne, należy użyć odpowiednio BPMN lub UML. Ale tu pojawia się problem: w UML usługa oprogramowania to przypadek użycia powiązany bezpośrednio z aktorem, który ma swój cel działania (użycia systemu w trakcie realizacji procesu biznesowego). Czyli usługa oprogramowania jest jednak pojęciowo bezpośrednio związana z czynnością w procesie, którą wspiera (cel pracy aktora). To tylko jedna z niespójności. Jeżeli uznać, że proces tworzenia oprogramowania to trzy fazy MDA opisane przez OMG czyli CIM, PIM i PSM (model biznesowy, model logiki systemu, model jego implementacji), to niestety TOGAF i ArchiMate są z nim niekompatybilne a  TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z drugiej strony potrzebne jest w każdym większym projekcie uporządkowanie wiedzy o organizacji z pomocą modeli (których tu będzie więcej nią jeden) czyli zrozumienie jej zachowania, wymaga to ujęcia tych modeli w strukturę. Po co? By mieć miernik pozwalający odpowiedzieć na pytanie: Czy mamy już wszystkie potrzebne modele, czy rozumiemy tę organizację.  Modele te to: procesy biznesowe oraz obiektowe struktury oprogramowania. Do tego modele pojęciowe i reguły biznesowe. Wszystko to – notacje i ich modele pojęciowe – jest bardzo dobrze opracowane w przez OMG. Czego brakuje? Metamodelu całości. Tu z pomocą przychodzi tak zwana [[Siatka Zachmana]].  Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? szablon i sposób postępowania, który pozwala w sposób formalny i ściśle ustrukturalizowany definiować architekturę systemów korporacyjnych. Używa siatki bazując na sześciu podstawowych pytaniach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zadanych pięciu grupom użytkowników (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przedstawić holistyczny obraz przedsiębiorstwa, które jest modelowane. (Siatka Zachmana ? Wikipedia, wolna encyklopedia).

Taka kompletna siatka (matryca) wygląda tak:

Jest to pełny opis organizacji. Nie zawsze jest potrzeba tworzenia całości. Na etapie typowej analizy biznesowej i analizy wymagań potrzebne są etapy CIM i PIM. W siatce Zachmana można pominąć zbędne (tu nadmiarowe, Zachman dopuszcza częściowe struktury) kolumny i wiersze nadal zachowując kompatybilność z MDA:

Powyższe to nic innego jak matryca pozwalająca zbudować uporządkowany model organizacji i umieścić w nim istniejące, wspierająca ją oprogramowanie i (lub) opisać to, które powinno się w niej pojawić czyli wymagania. Powyższe mapuje się w 100% na model MDA: CIM i PIM. Nie trzeba więc niczego zmieniać a model pojęciowy jest spójny. Jeżeli ktoś korzysta z modelu MDA/OMG, bez problemu może przyporządkować polom (przecięcia wierszy i kolumn) modele notacji BPMN, UML i BMM, a także systemy reguł biznesowych i słownik pojęć dziedzinowych. (powyższe zrzuty ekranowe narzędzia Agilian)

Z każdym kolejnym projektem skłaniam się ku tezie, że Architektura Korporacyjna, jako całościowe (lub jak kto woli: holistyczne) podejście do dokumentowania (modelowania) organizacji, bliższa jest Siatce Zachmana niż TOGAF’owi, który w moich oczach jest po protu przekombinowany i niekompatybilny z notacjami, od których raczej nie ma ucieczki (BPMN, UML, BMM a nawet  strukturalne ERD i DFD).

Powyższy uproszczony (wyłączone nieużywane wiersze i kolumny) kształt Siatki Zachmana, coraz częściej służy mi jako zakres projektu analitycznego i korzeń jego struktury. Poszukując materiałów na ten temat znalazłem opracowanie opublikowane na stronie Business Process Trends już w 2003 roku o wdzięcznym tytule: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakończenie, dwa diagramy zapożyczone z tego opracowania:

– mapowanie MDA na Siatkę Zachmana:

oraz wskazanie, gdzie zastosować notacje UML:

Powyższy diagram warto uzupełnić uwagą, że zastosowanie notacji BPMN w obszarze procesów biznesowych wydaje się być obecnie znacznie rozsądniejsze (w 2003 roku, nie była stosowana), zaś w obszarze motywacji doskonale sprawuje się BMM. OMG daje także uporządkowane systemu zapisu reguł biznesowych i słowników pojęć.

TOGAF ma ambicje porównywania się z Siatką Zachmana, jednak w moim odczuciu obszarowe porównanie – zgodność – to nie to samo z kompatybilność (tu już jej brak) z systemami pojęciowymi (uznanymi za standardy notacjami), bo to tu tkwi sens i sedno problemu. Jak na razie nie sądzę, by notacja ArchiMate – język wyrazu TOGAF’a – wyparło dorobek OMG, a niestety nie jest w stanie go zastąpić. Obecna postać Siatki Zachman v.3.0. to już ugruntowana ontologia. (czysty plakat  ZachmaFramework 3.0, widać na nim bardzo ważną rzecz: śladowanie, mapowanie pomiędzy modelami).

Siatka Zachmana w użyciu – pakiet Visual-Paradigm.

c.d.n.