Dziś mia­ła miej­sce kon­fe­ren­cja Virtu GigaCon. Mój refe­rat doty­czył wpły­wu wir­tu­ali­za­cji (jej wpro­wa­dze­nia jako narzę­dzia pra­cy) na ryzy­ka zwią­za­ne z dzia­ła­niem sys­te­mu IT w orga­ni­za­cji. Tu podzie­lę się kil­ko­ma jed­nak nie całym refe­ra­tem (zapra­szam na następ­ne kon­fe­ren­cje ;)) a wąt­kiem doty­czą­cym ana­li­zy oddzia­ły­wa­nia. Analiza taka pole­ga na opra­co­wa­niu np. listy tego na co w orga­ni­za­cji ma wpływ coś, np. na co ma wpływ Proces XXX albo na co ma wpływ Pracownik JK czy tez na co w orga­ni­za­cji ma wpływ Serwer XXX.

Analizy takie robi się naj­czę­ściej w pro­jek­tach zwią­za­nych z oce­ną ryzy­ka funk­cjo­no­wa­nia, jed­nak jest to bar­dzo przy­dat­ne narzę­dzie w pra­cy nad wyma­ga­nia­mi na opro­gra­mo­wa­nie i opra­co­wy­wa­nie wyma­gań poza-funk­cjo­nal­nych. Podam pro­sty przy­kład: dobrą prak­ty­ką jest prio­ry­te­ty­za­cja przy­pad­ków uży­cia, na jakiej pod­sta­wie nada­je­my te prio­ry­te­ty? Najczęściej na bazie dekla­ra­cji zama­wia­ją­ce­go, jed­nak nie raz oka­zu­je się, że pozor­nie mało istot­na usłu­ga sys­te­mu jako sama w sobie, jest w pew­nych sytu­acjach klu­czo­wym ele­men­tem. Po pierw­sze war­to znać prze­bieg pro­ce­su w jakim dana usłu­ga jest wyko­rzy­sty­wa­na, tu mam sytu­ację rela­tyw­nie pro­stą bo łań­cuch jest tak dobry jak naj­słab­sze ogni­wo. Jeżeli jakiś pro­ces ma wyso­ki prio­ry­tet to zna­czy, że wszyst­kie przy­pad­ki uży­cia (wyma­ga­ne funk­cjo­nal­no­ści) zwią­za­ne w tym pro­ce­sem tak­że. dekla­ra­tyw­na lista przy­pad­ków uży­cia raczej nam tego nie powiem.

Ale to dość ​„pro­sta ana­li­za”, wystar­czy mieć mode­le pro­ce­sów i wypro­wa­dzo­ne z nich przy­pad­ki uży­cia. Zaczynają się pro­ble­my przy pró­bie oce­ny zwią­za­nej np. ze sta­no­wi­skiem zaj­mo­wa­nym przez akto­ra (role w pro­ce­sie. Można domnie­my­wać, że pew­ne funk­cjo­na­li­ści są waż­ne, nie z powo­du udzia­łu w waż­nym pro­ce­sie, ale z powo­du tego, że ich użyt­kow­ni­kiem jest waż­na oso­ba w fir­mie. Inny rodzaj zależ­no­ści: któ­re apli­ka­cje powin­ny mieć wyso­ką nie­za­wod­ność a któ­re nie, wie­dząc, że cześć z nich współ­dzie­li plat­for­mę sprzę­to­wą czy sys­te­mo­wą z innym, pro­ce­sy są wspie­ra­ne przez wie­le posia­da­nych systemów.

Tu daje o sobie znać meto­da spe­cy­fi­ko­wa­nia wyma­gań poza-funk­cjo­nal­nych jako osob­nej listy dla całe­go sys­te­mu (i tu pyta­nie co nazy­wa­my tu sys­te­mem, kon­kret­ne opro­gra­mo­wa­nie czy wszyst­kie zaso­by IT jakie mamy). Pokaże to na przykładzie.

Podstawą dobrze opra­co­wa­ne­go mode­lu jest two­rze­nie go od ogó­łu do szcze­gó­łu i śla­do­wa­nie to jest wypro­wa­dza­nie każ­de­go szcze­gó­łu z nad­rzęd­ne­go mode­lu uogól­nio­ne­go lub powiązanego.

Po lewej stro­nie ​„pira­mi­da”, stan­dar­do­wy trój­war­stwo­wy model orga­ni­za­cji, od góry:

1. war­stwa strategii
2. war­stwa łań­cu­cha war­to­ści doda­nej i pro­ce­sów biznesowych
3. war­stwa wyko­naw­cza i zasoby

Warstwa pierw­sza to stra­te­gia i tak­ty­ka dzia­ła­nia fir­my. Tu może sie poja­wić ogól­na archi­tek­tu­ra pro­ce­sów (tak­ty­ka dzia­ła­nia). Kolejna to klu­czo­wy ele­ment, abs­trak­cja opi­su­ją­ca jak fir­ma budu­je war­tość, jak powsta­ją jej pro­duk­ty (tak­że pośred­nie). Najniżej mamy zaso­by: ludzie, IT, inne. Taki model to nic inne­go jak model archi­tek­tu­ry kor­po­ra­cyj­nej (tyle, że jak widać nie musi to być nota­cja [[ArchiMate]] a wystar­czy BPMN i UML).

Kompletny opis (model) orga­ni­za­cji to:

1. mode­le opi­su­ją­ce cele biz­ne­so­we i klu­czo­we dzia­ła­nia (archi­tek­tu­ra procesów),
2. mode­le pro­ce­sów biznesowych,
3. mode­le struk­tu­ry orga­ni­za­cyj­nej wraz z opi­sa­mi kom­pe­ten­cji oraz mode­le archi­tek­tu­ry sys­te­mu IT.

Model zawie­ra­ją­cy wyżej opi­sa­ne śla­do­wa­nia (i tyl­ko taki!) pozwa­la na ana­li­zę zale­zno­ści, np. chce­my dowie­dzieć się na co ma wpływ Proces_2, wte­dy powi­nien powstać np. taki diagram:

Jak widać, śla­do­wa­nie jest tu warun­kiem koniecz­nym dla­cze­go? Taki model może powstać ​„auto­ma­tycz­nie” (narzę­dzie do mode­lo­wa­nia musi posia­dać taka funk­cjo­nal­ność). jed­nak to nie jedy­ny waru­nek: model musi zacho­wy­wać for­mal­na popraw­ność, czy­li nie uży­wa­my poję­cia Rola (pas na mode­lu pro­ce­sów) do symu­lo­wa­nia ​„sys­te­mu” któ­ry coś robi, bo opro­gra­mo­wa­nie to narzę­dzie czło­wie­ka (rola w pro­ce­sie), spe­cy­fi­ka uży­cia dane­go narzę­dzia to umie­jęt­no­ści akto­ra (użyt­kow­ni­ka) i jest to co naj­wy­żej pro­blem sko­ja­rze­nia danej czyn­no­ści (pro­ce­su) z doku­men­tem opi­su­ją­cym pro­ce­du­rę lub instruk­cję użyt­kow­ni­ka (to tak­że narzę­dzie powin­no umożliwiać).

Wszelkie łama­nie for­ma­li­zmów nota­cji odno­si taki sam sku­tek jak np. wyko­rzy­sty­wa­nie pól w bazie danych do prze­cho­wy­wa­nia innych danych niż te z nagłów­ka np. wpi­sy­wa­nie dru­gie­go imie­nia do pola Nazwisko czy nazwy dziel­ni­cy w pole Miasto. Z takiej bazy danych żaden sen­sow­ny raport już nie powsta­nie. Jeżeli na mode­lu pro­ce­sów uży­to sym­bo­li w innych zna­cze­niach niż to wyni­ka z uży­tej nota­cji żad­nej sen­sow­nej infor­ma­cji też nie uzy­ska­my… to już nie mode­le tyl­ko zwy­kłe obrazki.