Badanie przy­dat­no­ści TOGAF/ArchiMate mam chy­ba za sobą (zapew­ne nie na mia­rę dok­to­ra­tu ale trosz­kę jed­nak tak, cho­ciaż…;)). Na stro­nie moje­go kole­gi: ArchitekturaKorporacyjna​.pl (pole­cam ana­li­ty­kom), w jed­nym z arty­ku­łów poja­wia się cie­ka­we stwierdzenie:

TOGAF wska­zu­je, że nie­wła­ści­we pod­czas mode­lo­wa­nia jest bez­po­śred­nie wią­za­nie pro­ce­su [biz­ne­so­we­go, jak sądzę] z apli­ka­cją go wspie­ra­ją­cą ? ele­men­tem pośred­nim powin­na być funk­cja ? czy­li: apli­ka­cja wspie­ra reali­za­cję funk­cji, a funk­cja obej­mu­je cały pro­ces lub jego frag­ment (w zależ­no­ści od pozio­mu dekom­po­zy­cji funk­cji biz­ne­so­wej). (Komentarze do TOGAF ? meta­mo­del zawar­to­ści (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierw­sze mnie zra­zi­ło w nota­cji ArchiMate: prze­rost poję­cio­wy (roz­drob­nie­nie albo jak kto woli nad­mier­na gra­da­cja). Umieszczenie dodat­ko­we­go poję­cia – funk­cja – pomię­dzy pro­ce­sem biz­ne­so­wym (pamię­ta­my, że samo­dziel­na czyn­ność to tak­że pro­ces) a narzę­dziem pra­cy jakim jest opro­gra­mo­wa­nie wyda­je się sztucz­ne. To trosz­kę jak umiesz­cze­nie pomię­dzy młot­kiem a pro­ce­sem wbi­ja­nia gwoź­dzia funk­cji wbi­ja­nie”, nie wiem jaką war­tość wno­si to do mode­lu, sko­ro mło­tek ma funk­cję (przy­pa­dek uży­cia) wbi­ja­nie” (pamię­taj­my, że opro­gra­mo­wa­nie to narzę­dzie pra­cy akto­ra, zasób).

Prowadzi to do nie­kom­pa­ty­bil­no­ści z sys­te­mem poję­cio­wym para­dyg­ma­tu obiek­to­we­go (MDA/OMG), na któ­ry ArchiMate się powo­łu­je, tym bar­dziej, że jed­nak MDA to stan­dard pro­ce­su obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia więc po co z nim wal­czyć? Testowałem mode­le ArchiMate na ludziach” i oka­zy­wa­ło się, że dla wie­lu z nich tak­że są one nie­in­tu­icyj­ne. Trudno mi też wytłu­ma­czyć ten nad­miar poję­cio­wy: sko­ro w natu­rze” czyn­ność jest wspie­ra­na usłu­gą sys­te­mu” to po co pako­wać mię­dzy nie, mię­dzy tę wód­kę a zaką­skę” ;), poję­cie biz­ne­so­wej funk­cji opro­gra­mo­wa­nia sko­ro ono świad­czy jakąś usłu­gę, bo jest ona funk­cjo­nal­no­ścią tego oprogramowania.

Trzy warstwy modelowaniaAutorzy ArchiMate wska­zu­ją, że tam gdzie ArchiMate jest zbyt ogól­ne, nale­ży użyć odpo­wied­nio BPMN lub UML. Ale tu poja­wia się pro­blem: w UML usłu­ga opro­gra­mo­wa­nia to przy­pa­dek uży­cia powią­za­ny bez­po­śred­nio z akto­rem, któ­ry ma swój cel dzia­ła­nia (uży­cia sys­te­mu w trak­cie reali­za­cji pro­ce­su biz­ne­so­we­go). Czyli usłu­ga opro­gra­mo­wa­nia jest jed­nak poję­cio­wo bez­po­śred­nio zwią­za­na z czyn­no­ścią w pro­ce­sie, któ­rą wspie­ra (cel pra­cy akto­ra). To tyl­ko jed­na z nie­spój­no­ści. Jeżeli uznać, że pro­ces two­rze­nia opro­gra­mo­wa­nia to trzy fazy MDA opi­sa­ne przez OMG czy­li CIM, PIM i PSM (model biz­ne­so­wy, model logi­ki sys­te­mu, model jego imple­men­ta­cji), to nie­ste­ty TOGAF i ArchiMate są z nim nie­kom­pa­ty­bil­ne a TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z dru­giej stro­ny potrzeb­ne jest w każ­dym więk­szym pro­jek­cie upo­rząd­ko­wa­nie wie­dzy o orga­ni­za­cji z pomo­cą mode­li (któ­rych tu będzie wię­cej nią jeden) czy­li zro­zu­mie­nie jej zacho­wa­nia, wyma­ga to uję­cia tych mode­li w struk­tu­rę. Po co? By mieć mier­nik pozwa­la­ją­cy odpo­wie­dzieć na pyta­nie: Czy mamy już wszyst­kie potrzeb­ne mode­le, czy rozu­mie­my tę orga­ni­za­cję. Modele te to: pro­ce­sy biz­ne­so­we oraz obiek­to­we struk­tu­ry opro­gra­mo­wa­nia. Do tego mode­le poję­cio­we i regu­ły biz­ne­so­we. Wszystko to – nota­cje i ich mode­le poję­cio­we – jest bar­dzo dobrze opra­co­wa­ne w przez OMG. Czego bra­ku­je? Metamodelu cało­ści. Tu z pomo­cą przy­cho­dzi tak zwa­na [[Siatka Zachmana]]. Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? sza­blon i spo­sób postę­po­wa­nia, któ­ry pozwa­la w spo­sób for­mal­ny i ści­śle ustruk­tu­ra­li­zo­wa­ny defi­nio­wać archi­tek­tu­rę sys­te­mów kor­po­ra­cyj­nych. Używa siat­ki bazu­jąc na sze­ściu pod­sta­wo­wych pyta­niach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zada­nych pię­ciu gru­pom użyt­kow­ni­ków (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przed­sta­wić holi­stycz­ny obraz przed­się­bior­stwa, któ­re jest mode­lo­wa­ne. (Siatka Zachmana ? Wikipedia, wol­na ency­klo­pe­dia).

Taka kom­plet­na siat­ka (matry­ca) wyglą­da tak:

Siatka Zachmana zakres analizy

Jest to peł­ny opis orga­ni­za­cji. Nie zawsze jest potrze­ba two­rze­nia cało­ści. Na eta­pie typo­wej ana­li­zy biz­ne­so­wej i ana­li­zy wyma­gań potrzeb­ne są eta­py CIM i PIM. W siat­ce Zachmana moż­na pomi­nąć zbęd­ne (tu nad­mia­ro­we, Zachman dopusz­cza czę­ścio­we struk­tu­ry) kolum­ny i wier­sze nadal zacho­wu­jąc kom­pa­ty­bil­ność z MDA:

Siatka Zachmana zakres analizy CIM PIM

Powyższe to nic inne­go jak matry­ca pozwa­la­ją­ca zbu­do­wać upo­rząd­ko­wa­ny model orga­ni­za­cji i umie­ścić w nim ist­nie­ją­ce, wspie­ra­ją­ca ją opro­gra­mo­wa­nie i (lub) opi­sać to, któ­re powin­no się w niej poja­wić czy­li wyma­ga­nia. Powyższe mapu­je się w 100% na model MDA: CIM i PIM. Nie trze­ba więc nicze­go zmie­niać a model poję­cio­wy jest spój­ny. Jeżeli ktoś korzy­sta z mode­lu MDA/OMG, bez pro­ble­mu może przy­po­rząd­ko­wać polom (prze­cię­cia wier­szy i kolumn) mode­le nota­cji BPMN, UML i BMM, a tak­że sys­te­my reguł biz­ne­so­wych i słow­nik pojęć dzie­dzi­no­wych. (powyż­sze zrzu­ty ekra­no­we narzę­dzia Agilian)

Z każ­dym kolej­nym pro­jek­tem skła­niam się ku tezie, że Architektura Korporacyjna, jako cało­ścio­we (lub jak kto woli: holi­stycz­ne) podej­ście do doku­men­to­wa­nia (mode­lo­wa­nia) orga­ni­za­cji, bliż­sza jest Siatce Zachmana niż TOGAF’owi, któ­ry w moich oczach jest po pro­tu prze­kom­bi­no­wa­ny i nie­kom­pa­ty­bil­ny z nota­cja­mi, od któ­rych raczej nie ma uciecz­ki (BPMN, UML, BMM a nawet struk­tu­ral­ne ERD i DFD).

Powyższy uprosz­czo­ny (wyłą­czo­ne nie­uży­wa­ne wier­sze i kolum­ny) kształt Siatki Zachmana, coraz czę­ściej słu­ży mi jako zakres pro­jek­tu ana­li­tycz­ne­go i korzeń jego struk­tu­ry. Poszukując mate­ria­łów na ten temat zna­la­złem opra­co­wa­nie opu­bli­ko­wa­ne na stro­nie Business Process Trends już w 2003 roku o wdzięcz­nym tytu­le: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakoń­cze­nie, dwa dia­gra­my zapo­ży­czo­ne z tego opracowania:

- mapo­wa­nie MDA na Siatkę Zachmana:

MDA2Zachman

oraz wska­za­nie, gdzie zasto­so­wać nota­cje UML:

UML2ZachmanPowyższy dia­gram war­to uzu­peł­nić uwa­gą, że zasto­so­wa­nie nota­cji BPMN w obsza­rze pro­ce­sów biz­ne­so­wych wyda­je się być obec­nie znacz­nie roz­sąd­niej­sze (w 2003 roku, nie była sto­so­wa­na), zaś w obsza­rze moty­wa­cji dosko­na­le spra­wu­je się BMM. OMG daje tak­że upo­rząd­ko­wa­ne sys­te­mu zapi­su reguł biz­ne­so­wych i słow­ni­ków pojęć.

TOGAF ma ambi­cje porów­ny­wa­nia się z Siatką Zachmana, jed­nak w moim odczu­ciu obsza­ro­we porów­na­nie – zgod­ność – to nie to samo z kom­pa­ty­bil­ność (tu już jej brak) z sys­te­ma­mi poję­cio­wy­mi (uzna­ny­mi za stan­dar­dy nota­cja­mi), bo to tu tkwi sens i sed­no pro­ble­mu. Jak na razie nie sądzę, by nota­cja ArchiMate – język wyra­zu TOGAF’a – wypar­ło doro­bek OMG, a nie­ste­ty nie jest w sta­nie go zastą­pić. Obecna postać Siatki Zachman v.3.0. to już ugrun­to­wa­na onto­lo­gia. (czy­sty pla­kat ZachmaFramework 3.0, widać na nim bar­dzo waż­ną rzecz: śla­do­wa­nie, mapo­wa­nie pomię­dzy modelami).

Siatka Zachmana w uży­ciu – pakiet Visual-Paradigm.

c.d.n.

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 2 komentarzy

  1. Paweł Zubkiewicz

    Dobry arty­kuł jed­nak nie mogę sie zgo­dzić z Toba, ze funk­cje, czy­li jeśli dobrze rozu­mie capa­bi­li­ties po angiel­sku są nieprzydatne. 

    Mapowanie apli­ka­cji bez­po­śred­nio do (aktyw­no­ści) pro­ce­sów poważ­nie ogra­ni­cza ela­stycz­ność i podat­nosc na zmia­ny. Procesy sie nie­ustan­nie zmie­nia­ją, jak mówi moj kole­ga jest jed­nak orga­ni­za­cja któ­ra sie nie zmie­nia – ta któ­ra wła­śnie zamknię­to”. Pryncypium i zara­zem wyma­ga­niem jest umoż­li­wie­nie wpro­wa­dze­nia tych zmian moż­li­we szyb­ko i tanio, zapew­nia­jąc tym samym (poten­cjal­nie) prze­wa­gę kon­ku­ren­cyj­na fir­mie, któ­ra szyb­ciej sie zmie­nia i dosto­so­wu­je do rynku.

    Warstwa capa­bi­li­ties zapew­nia ta ela­stycz­ność, przy­naj­mniej w czę­ści, ponie­waż capa­bi­li­ties nie zmie­nia­ją sie tak czę­sto jak pro­ce­sy. Dodatkowo powin­ny być zapro­jek­to­wa­ne w taki spo­sób aby łatwo moż­na było je łączyć ze sobą i w ten spo­sób two­rzyć nowe pro­ce­sy. Tutaj w sumie jest taka sama zasa­da jak w pro­gra­mo­wa­niu czy archi­tek­tu­rze sys­te­mo­wej – kolej­ne war­stwy zapew­nia­ją ela­stycz­ność i uła­twia­ją wdro­że­nie zmian w systemie. 

    Sama kon­cep­cja capa­bi­li­ty nie jest dużo bar­dziej skom­pli­ko­wa­na niż super­sys­tem o któ­rym pisa­łes ostat­nio w arty­ku­le o domenie.

    Natomiast zgo­dzę sie z Toba, ze cież­ko jest wytłu­ma­czyć cała kon­cep­cje archi­tek­tu­ry kor­po­ra­cyj­nej i capa­bi­li­ty. No ale z moje­go doświad­cze­nia wyni­ka, ze ludzie maja tez pro­ble­my z bar­dziej pod­sta­wo­wy­mi ter­mi­na­mi, jak róż­ni­ca mie­dzy apli­ka­cja a systemem.

    1. Jarek Żeliński

      Capabilities to zdol­ność” (kogoś/czegoś do cze­goś”). Funkcja z per­spek­ty­wy opro­gra­mo­wa­nia to usłu­ga jaką świad­czy (przy­pa­dek uży­cia): np. (wspar­cie w) Wystawieniu fak­tu­ry VAT. Jest to usłu­ga opro­gra­mo­wa­nia wspie­ra­ją­ca czyn­no­ści Fakturowanie w pro­ce­sie Sprzedaży. Proces sprze­da­ży może się zmie­niać, ale ele­men­tar­na część Fakturowania gdzieś tam będzie. 

      Model SOA ma trzy war­stwy: pro­ce­sy, usłu­gi opro­gra­mo­wa­nia i opro­gra­mo­wa­nie jako zasób (wraz z plat­for­ma­mi itp.). Proces biz­ne­so­wy to abs­trak­cja tego co robi orga­ni­za­cja, usłu­gi opro­gra­mo­wa­nia to abs­trak­cja tego opro­gra­mo­wa­nia z per­spek­ty­wy użyt­kow­ni­ka (to jeden do jed­ne­go przy­pad­ki uży­cia), naj­niż­sza war­stwa to imple­men­ta­cja. Wprowadzanie dodat­ko­wej war­stwy pomię­dzy pro­ces (czyn­no­ści w pro­ce­sie) a usłu­gi opro­gra­mo­wa­nia sta­no­wi coś dziw­ne­go bo co reprezentuje? 

      Moim zda­niem są to chy­ba skut­ki dużych nie­kon­se­kwen­cji w defi­nio­wa­ni pojęć: usłu­ga opro­gra­mo­wa­nia, przy­pa­dek uży­cia i pro­ces ele­men­tar­ny. Wszystkie trzy to to samo” ale z róż­nych per­spek­tyw. Oprogramowanie jako czar­na skrzyn­ka opi­sy­wa­ne jest przy­pad­ka­mi uży­cia. Przypadek uży­cia to coś”, co po zaini­cjo­wa­niu da jako efekt coś mają­ce­go war­tość dla akto­ra czy­li kom­plet­na usłu­ga opro­gra­mo­wa­nia. Proces ma wej­ście i wyj­ście, będą­cy jego pro­duk­tem, dokład­nie tak jak przy­pa­dek uży­cia. (przy­po­mnę, że pro­ces biz­ne­so­wy to czyn­ność lub łań­cuch czynności…)

      Np. ele­men­tar­nym pro­ce­sem będzie wysta­wie­nie fak­tu­ry, potrzeb­na więc jest nam usłu­ga sys­te­mu wspie­ra­ją­ca te pra­cę, będzie przy­pa­dek uży­cia Wystawiania fak­tur, a jest to nic inne­go jak usłu­ga opro­gra­mo­wa­nia (wspar­cie czyn­no­ści wysta­wia­nia fak­tur). Tu oczy­wi­ście kła­nia się poję­cie gra­da­cji czyn­no­ści, przy­pad­ków uży­cia i usług opro­gra­mo­wa­nia i tu widzę źró­dło pro­ble­mu np. z jed­nej stro­ny wyod­ręb­nia­nie jako przy­pad­ku uży­cia klik­nię­cia roz­wi­ja­nej listy kon­tra­hen­tów pod­czas wysta­wia­nia fak­tu­ry a z dru­giej uzna­nie zarzą­dza­nia doku­men­ta­mi spół­ki” za usłu­gę opro­gra­mo­wa­nia. Dlatego defi­ni­cje tych pojęć rodem z SOA, OMG/UML/BPMN nie wyma­ga­ją wpro­wa­dza­nia żad­nej war­stwy pośred­niej nor­ma­li­zu­ją­cej” takie roz­bież­no­ści. Mam wra­że­nie, ze ArchiMate to pró­ba ogar­nię­cia roz­rzu­tu tych defi­ni­cji. Ja oso­bi­ście trzy­mam się defi­ni­cji naj­prost­szych (np. nie tole­ru­je sztucz­ne­go bar­dzo poję­cia sys­te­mo­wy przy­pa­dek uży­cia”), ele­men­tar­nych bo roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na takie daje dużo lep­sze zro­zu­mie­nie (mniej kloc­ków lego) niż mno­że­nie pojęć, któ­re bar­dzo czę­sto pole­ga nie­ste­ty na zasa­dzie wszyst­ko to cze­go nie rozu­miem dosta­nie nową nazwę”. 

      Co do ostat­nie­go Twojego zda­nia to fak­tycz­nie też to obserwuję 🙂
      P.S.
      Co do capa­bi­li­ties to coś cie­ka­we­go: http://​www​.aiai​.ed​.ac​.uk/​p​r​o​j​e​c​t​/​e​n​t​e​r​p​r​i​s​e​/​e​n​t​e​r​p​r​i​s​e​/​o​n​t​o​l​o​g​y​.​h​tml

Dodaj komentarz

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