Analiza biz­ne­so­wa to dość duże wyzwa­nie. Nie pole­ga tyl­ko na zapi­sa­niu z pomo­cą wywia­dów tego, co fir­ma robi. Chodzi o zro­zu­mie­nie tego co dana fir­ma robi i po co to robi. Powoli coraz wię­cej się mówi o mode­lach i nota­cjach. Stały się wręcz mod­ne (bo, że poma­ga­ją to już wia­do­mo). Jednak celem ana­li­zy nie jest opra­co­wa­nie mode­li pro­ce­sów, te są tyl­ko narzę­dziem osią­ga­nia celu. Celem ana­li­zy jest odkry­cie i wska­za­nie tego, co i na co ma wpływ w mode­lo­wa­nej organizacji.

Niejako stan­dar­dem w pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, są ostat­nio nota­cje: BPMN na eta­pie two­rze­nia mode­li biz­ne­so­wych i nota­cja UML na eta­pie pro­jek­to­wa­nia opro­gra­mo­wa­nia (całe­go sys­te­mu). Od dłuż­sze­go cza­su spo­ty­kam się z pew­ny­mi ogra­ni­cze­nia­mi obu tych notacji.

W jed­nym z poprzed­nich arty­ku­łów napiałem:

Na pozio­mie pro­ce­sów biz­ne­so­wych, sto­su­ję zamien­nie BPMN albo ArchiMate. Z każ­dym kolej­nym pro­jek­tem skła­niam się jed­nak do uży­wa­nia na tym pozio­mie ArchiMate. Powodem jest to, że BPMN ofe­ru­je wyłącz­nie czy­ste poję­cia z defi­ni­cji wyko­naw­czej pro­ce­su (czyn­ność, dane, zda­rze­nie, rola, pula, bram­ki). Na tym pozio­mie jed­nak, nie raz nale­ży wyra­zić roz­dziel­nie takie poję­cia jak rola i aktor (np. klient i kon­tra­hent mogą peł­nić rolę zama­wia­ją­ce­go w pro­ce­sie) albo poję­cia takie jak funk­cje biz­ne­so­we (aktor wraz z zaso­ba­mi jakich uży­wa, peł­ni funk­cję admi­ni­stra­cji wewnętrz­nej) albo usłu­gi powią­za­nej z pro­ce­sa­mi (pro­ces sprze­da­ży powią­za­ny z usłu­gą obsłu­gi klien­ta). Przykłady moż­na mno­żyć. (Co jest wadą więk­szo­ści ana­liz biz­ne­so­wych?).

Od cza­su do cza­su jestem pyta­ny jak repre­zen­to­wać System (opro­gra­mo­wa­nie ana­li­zo­wa­ne lub pro­jek­to­wa­ne) na mode­lach BPMN. Niestety nota­cja ta nie ma takie­go odręb­ne­go poję­cia w swo­jej prze­strze­ni poję­cio­wej. Najczęściej spo­ty­ka­nym spo­so­bem zobra­zo­wa­nia sys­te­mu na mode­lu pro­ce­su jest uży­cie dedy­ko­wa­ne­go toru (lane) dla zobra­zo­wa­nia opro­gra­mo­wa­nia i umiesz­cza­nie w nim czyn­no­ści wyko­ny­wa­nych przez (z uży­ciem) opro­gra­mo­wa­nie (od tej meto­dy odsze­dłem kil­ka lat temu). Inna meto­da to ozna­cza­nie czyn­no­ści zwią­za­nych z uży­cie sys­te­mu ste­reo­ty­pem przy­pa­dek uży­cia (tę nadal sto­su­ję). Pierwsza meto­da moim zda­niem łamie defi­ni­cje roli w pro­ce­sie. Jeżeli jakaś czyn­ność jest reali­zo­wa­na przez oso­bę (akto­ra) uży­wa­ją­cą do pra­cy opro­gra­mo­wa­nia, poja­wia się pro­blem: co jest tu mode­lo­wa­ne i gdzie się podział aktor sko­ro tor to sys­tem. Drugi spo­sób to uży­cie moż­li­wo­ści pro­gra­mu CASE uży­te­go do ana­li­zy i nie­stan­dar­do­we­go wzbo­ga­ce­nia nota­cji o poję­cie ste­reo­ty­pu, któ­re­go for­mal­nie BPMN nie ma. Jedno i dru­gie kłó­ci się tak­że z mode­lo­wa­niem eta­pu CIM ([[Computation Independent Model]]).

Jak już nie raz pod­kre­śla­łem, siła for­mal­nych nota­cji leży w ich bar­dzo dobrze opra­co­wa­nym słow­ni­ku pojęć i rela­cji mię­dzy tymi poję­cia­mi. Łamanie tych zasad powo­du­je, że tak wyko­na­na ana­li­za sta­je się ryzy­kow­na, gdyż pozwa­la na wpro­wa­dza­nie nie­jed­no­znacz­no­ści w modelach.

Jednak pro­blem ist­nie­je… powsta­ła notacja

ArchiMate

Notacja powsta­ła w Telematica Institute, zyska­ła sobie wła­sną toż­sa­mość jako ArchiMate, zosta­ła ​„wchło­nię­ta” pod skrzy­dła The Open Group. Specyfikacja 1.0 powsta­ła w 2004 roku więć nota­cja zosta­ła już dość dobrze ​„prze­ćwi­czo­na”. Z niszo­wej sta­ła się stan­dar­dem. Obecnie sta­no­wi ofi­cjal­ne narzę­dzie mode­lo­wa­nia w pro­jek­tach na bazie meto­dy­ki TOGAF:

(źr. www​.archi​ma​te​.nl, obec­nie TOGAF 9 i Archimate v.2.0; poprzed­nia ArchiMate v.1.0 zawie­ra­ła tyl­ko poję­cia z zakre­su warstw biz­ne­so­wej, apli­ka­cji i tech­no­lo­gii, pola zakre­ślo­ne uko­śną linią to roz­sze­rze­nie wpro­wa­dzo­ne w wer­sji 2.0).

Ważne jest to, że nota­cja ta swo­imi poję­cia­mi biz­ne­so­wy­mi, opi­su­je (mode­lu­je) orga­ni­za­cje prze­kro­jo­wo. W ramach sys­te­mu poję­cio­we­go ArchiMate mamy trzy gru­py pojęć dla trzech warstw modeli:

Jak widać słow­nik pojęć w war­stwie biz­ne­so­wej jest znacz­nie bogat­szy niż w nota­cji BPMN. Każde poję­cie ma ści­śle zde­fi­nio­wa­ne zna­cze­nie a zna­cze­nia te (zasięg ich defi­ni­cji) oczy­wi­ście nie zacho­dzą na sie­bie. Co nam to daje? Możliwe jest prze­pro­wa­dze­nie bar­dzo wni­kli­wej ana­li­zy logi­ki pro­ce­sów biz­ne­so­wych, sko­ja­rze­nie jej z usłu­ga­mi sys­te­mu, jego funk­cjo­nal­no­ścią i meto­da­mi imple­men­ta­cji. Czy ArchiMate zastę­pu­je BPMN czy UML? Nie, ale pozwa­la unik­nąć ich nad­uży­wa­nia i nad­ra­bia ich bra­ki w sfe­rze biz­ne­so­wych mode­li abstrakcyjnych.

Jak już pisa­łem BPMN i UML to nota­cje, któ­re powsta­ły w celach ​„inży­nier­skich” tu, w inży­nie­rii opro­gra­mo­wa­nia, są raczej bez­kon­ku­ren­cyj­ne. Jednak są, moim zda­niem, zbyt ubo­gie i mało zro­zu­mia­łe do mode­lo­wa­nia zło­żo­no­ści biz­ne­so­wej. Pokażę to na przy­kła­dzie mode­lu pro­ce­su sprze­da­ży. Załóżmy, że w toku ana­li­zy udo­ku­men­to­wa­li­śmy pro­ces fak­tu­ro­wa­nia wraz z tym kto fak­tu­ru­je, fak­tu­rą jako doku­men­tem i dany­mi. Chcemy następ­nie opra­co­wać spe­cy­fi­ka­cję usług, jakie pla­no­wa­ny sys­tem miał­by reali­zo­wać, przy­po­rząd­ko­wać logicz­nie poszcze­gól­ne usłu­gi do grup (funk­cjo­nal­ność sys­te­mu). Na koniec zapro­jek­to­wać archi­tek­tu­rę systemu.

Jak wspo­mnia­łem poprzed­nio, pro­blem roz­wią­zu­je sto­so­wa­nie języ­ka (nota­cji) ade­kwat­ne­go do pro­ble­mu. Tu poka­żę przy­kład jak nota­cja ArchiMate radzi sobie z pro­ble­mem łącze­nia biz­ne­su, opro­gra­mo­wa­nia i technologii:

A gdzie BPMN i UML? Ano każ­dy pro­ces (przy­ję­cie zamó­wie­nia, kom­ple­ta­cja, fak­tu­ro­wa­nie) w kon­tek­ście szcze­gó­łów prze­pły­wu pra­cy, mode­lo­wa­ny był­by w nota­cji BPMN (kon­kret­ne role, doku­men­ty, czyn­no­ści). Pozostałe war­stwy ope­ru­ją poję­cia­mi, któ­rych szcze­gó­ły moż­na (nale­ży jeże­li taki jest zakres pro­jek­tu) mode­lo­wać już w nota­cji UML. Usługi mapu­ją się na przy­pad­ki uży­cia, pozo­sta­łe to archi­tek­tu­ra: kom­po­nen­ty opro­gra­mo­wa­nia, dane, archi­tek­tu­ra techniczna.

Jak widać, ArchiMate pozwa­la na tym pozio­mie abs­trak­cji na wię­cej niż same BPMN czy UML, ale też nie zastę­pu­je ich. Wzbogaca tak­że sys­tem poję­cio­wy na potrze­by ana­li­zy biz­ne­so­wej co pozwa­la wier­nie odtwo­rzyć rze­czy­wi­stość biz­ne­so­wą w spo­sób zro­zu­mia­ły dla ​„biz­ne­su”. Jako pod­su­mo­wa­nie przy­to­czę jesz­cze raz zna­ny już tu diagram:

(jak two­rzyć mode­le ArchiMate z pomo­cą narzę­dzia Agilian).

O archi­tek­tu­rze kor­po­ra­cyj­nej w kon­tek­ście ana­li­zy i pro­jek­to­wa­ni innym razem. Teraz tyl­ko kil­ka korzy­ści z posia­da­nia takie­go modelu:

1. moż­li­wość wywo­dze­nia wyma­gań na opro­gra­mo­wa­nie w mode­lu biznesowego,
2. moż­li­wość ana­li­zy wpły­wu i zależ­no­ści usług biz­ne­so­wych od infra­struk­tu­ry IT (pro­jek­ty zwią­za­ne z ana­li­zą cią­gło­ści dzia­ła­nia organizacji),
3. moż­li­wość pro­wa­dze­nia prze­kro­jo­wych ana­liz ryzyka.

Więcej na temat samej Architekturze Korporacyjnej na stro­nie ArchitekturaKorporacyjna​.pl, któ­rą gorą­co polecam.

Zainteresowanym nota­cją ArchiMate i jej uży­wa­niem pole­cam stro­nę ArchiMate Good practices.

___

P.S. Z uwa­gi na wady seman­tycz­ne nota­cji ArchiMate i roz­po­czę­cie przez The Open Group jej licen­cjo­no­wa­nia zarzu­ci­łem sto­so­wa­nie tej nota­cji (2012). Nadal udzie­lam kon­sul­ta­cji w zakre­sie recen­zo­wa­nia mode­li wyko­na­nych w tej notacji.