Wzorzec CRUD dla przypadków użycia i mikroserwisy

Regularnie spo­ty­kam się z mon­stru­al­ny­mi spe­cy­fi­ka­cja­mi: naj­pierw wyma­gań” a potem przy­pad­ków uży­cia”: dzie­siąt­ki, set­ki (o ich ilo­ści napi­sa­łem tu). Na ich pod­sta­wie powsta­ją wyce­ny – nie mniej kosmicz­ne. Jednak jeże­li zesta­wić to z bada­nia­mi pro­jek­tów i oce­ną, że jed­ną z klu­czo­wych przy­czyn pora­żek jest nad­mier­na zło­żo­ność i nie­jed­no­znacz­ność spe­cy­fi­ka­cji wyma­gań, a potem same­go pro­jek­tu i jego zakre­su oraz utra­ta pano­wa­nia nad tym zakre­sem, to może war­to się nad tym pochylić?

Kluczem jest defi­ni­cja wyma­ga­nia i czę­sto są nimi wła­śnie przy­pad­ki uży­cia. Pojęcie przy­pad­ku uży­cia (UML) i usłu­gi (SoaML):

Przypadek uży­cia (UML, Superstructure v.2.4.1.): A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem.

Usługa (SoaML, v.1.0.1.): Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce contract.

Tak więc przy­pa­dek uży­cia jako efekt daje okre­ślo­ny, war­to­ścio­wy rezul­tat. Warto teraz w tym miej­scu pod­kre­ślić, że SOA (patrz spe­cy­fi­ka­cja) zakła­da, że usłu­ga jako efekt (pro­dukt) daje Real World Effect defi­ned as servi­ce ope­ra­tion post con­di­tion” co jest o tyle istot­ne, że ana­lo­gicz­nie koń­czy się przy­pa­dek uży­cia (przy­po­mnę, że post con­di­tion” to sta­bil­ny stan sys­te­mu po wyko­na­niu operacji).

Popatrzmy teraz na poję­cie czyn­no­ści w BPMN:

Aktywność a czyn­ność: (BPMN, v.2.0) An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic (com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sec­tions will focus on the gra­phi­cal objects Sub-Process and Task. […] A Task is an ato­mic Activity within a Process flow. A Task is used when the work in the Process can­not be bro­ken down to a finer level of detail.

Tu zaczy­na się prag­ma­ty­ka biz­ne­so­wa, czy­li defi­ni­cja poję­cia pro­ces biz­ne­so­wy, któ­ra zakła­da, że pro­ces biz­ne­so­wy (tak­że ele­men­tar­ny, ato­mo­wy) to czyn­ność lub łań­cuch logicz­nie powią­za­nych czyn­no­ści (aktyw­ność), two­rzy pro­dukt mają­cy war­tość dla odbior­cy tego pro­duk­tu (pro­dukt musi się nada­wać do biz­ne­so­we­go wyko­rzy­sta­nia). Ta defi­ni­cja jest nie­mal­że kopia defi­ni­cji przy­pad­ku uży­cia. Procesem biz­ne­so­wym jest KAŻDA aktyw­ność wraz z jej samo­dziel­nie przy­dat­nym biz­ne­so­wo pro­duk­tem (para aktyw­ność i jej pro­dukt, dla­te­go w BPMN nie ma jed­nej iko­ny na pro­ces biz­ne­so­wy”). Jak widać, te trzy poję­cia: przy­pa­dek uży­cia apli­ka­cji, usłu­ga apli­ka­cji oraz ele­men­tar­ny pro­ces biz­ne­so­wy (pod­kre­ślam, że pro­jek­ty IT dla biz­ne­su mają biz­ne­so­wy kon­tekst co nada­je ści­ślej­sze zna­cze­nia tym trzem poję­ciom), mają nie­mal­że toż­sa­me defi­ni­cje (zresz­tą OMG dąży w tym wła­śnie kie­run­ku). Popatrzmy tu:

The majo­ri­ty of today­’s SOA design tech­ni­qu­es 1,2,3 are cen­te­red aro­und defi­ni­tion of servi­ces. They use 1se­rvi­ce-orien­ted decom­po­si­tion, based on the busi­ness pro­ces­ses, enter­pri­se business/functional model, requ­ired long term archi­tec­tu­ral goals and reu­se of the exi­sting enter­pri­se func­tio­na­li­ty. (Incorporating Enterprise Data into SOA).

Kluczem jest suge­stia (uzna­nie), że ele­men­tar­nym poję­ciem do dekom­po­zy­cji funk­cjo­nal­nej jest poję­cie ele­men­tar­nej (ato­mo­wej) usłu­gi (i nie jest nią jed­na linia pro­gra­mu!) będą­cej tak­że ele­men­tar­nym pro­ce­sem biz­ne­so­wym. Popatrzmy na dia­gram obra­zu­ją­cy archi­tek­tu­rę SOA (pocho­dzą­cy z tego same­go artykułu):

SOA implemetation

Mamy tu, mię­dzy inny­mi, trzy waż­ne war­stwy (tu dru­gą, trze­cią i czwar­tą od góry), są to odpo­wied­nio: pro­ce­sy biz­ne­so­we, usłu­gi apli­ka­cyj­ne (ta war­stwa to abs­trak­cja) oraz apli­ka­cje świad­czą­ce te usłu­gi. Mamy więc mapo­wa­nie ele­men­tar­nych ato­mo­wych pro­ce­sów (poje­dyn­czych czyn­no­ści) na ele­men­tar­ne usłu­gi apli­ka­cyj­ne. Usługi te, to nic inne­go jak przy­pad­ki uży­cia apli­ka­cji, czy­li każ­dą apli­ka­cję (jej uży­tecz­ność) moż­na opi­sać z pomo­cą jej przy­pad­ków uży­cia”, a te jak już wie­my, w UML słu­żą – jak widać słusz­nie – do spe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych. Tu uwa­ga, nie nale­ży tego mylić ze spo­ty­ka­ny­mi w lite­ra­tu­rze biz­ne­so­wy­mi przy­pad­ka­mi uży­cia” (nie ma taki w UML).

Konwencja biz­ne­so­wych przy­pad­ków uży­cia to relikt meto­dy RUP z lat 90’tych, kie­dy to nie było np. nota­cji BPMN, i tak zwa­ny biz­ne­so­wy dia­gram przy­pad­ków uży­cia” opi­sy­wał fir­mę, jej usłu­gi i klien­tów (akto­rów), a nie apli­ka­cję (do dzi­siaj jest to przy­czy­ną wie­lu nie­po­ro­zu­mień i powsta­wa­nia niskiej jako­ści nie­jed­no­znacz­nych dokumentacji). 

Tak więc, jak widać, moż­na uznać (przy­jąć), że przy­pa­dek uży­cia to usłu­ga apli­ka­cji, a ich gra­da­cję okre­śla pro­dukt jako uży­tecz­ność efek­tu. Co cie­ka­we, nie­któ­re narzę­dzia CASE wspie­ra­ją (uła­twia­ją) two­rze­nie (mapo­wa­nie) czyn­no­ści (ele­men­tar­nych pro­ce­sów biz­ne­so­wych) w pro­ce­sach (nota­cja BPMN) na przy­pad­ki uży­cia (nota­cja UML).

Taksonomia wyma­gań, w tym biz­ne­so­we i przy­pad­ki uży­cia oraz usłu­gi apli­ka­cyj­ne (Produkty w pro­ce­sie ana­li­zy wyma­gań):

Wymagania

Warto tu teraz zwró­cić uwa­gę, że wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne, jako­ścio­we i dzie­dzi­no­we oraz usłu­gi sys­te­mu to ele­men­ty abstrakcyjne.

Tak na praw­dę rze­czy­wi­ste są jedy­nie wyma­ga­nia biz­ne­so­we jako ocze­ki­wa­nia zama­wia­ją­ce­go wyra­żo­ne w jego języ­ku, oraz przy­pad­ki uży­cia i model dzie­dzi­ny, bo opi­su­ją rze­czy­wi­sty byt jakim jest (przy­szły) pro­dukt (apli­ka­cja).

CRUD, czym jest?

CRUD to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń). Są to czte­ry pod­sta­wo­we ope­ra­cje na tak zwa­nych kar­to­te­kach, obiek­tach słu­żą­cych do zapa­mię­ty­wa­nia infor­ma­cji czy­li poje­dyn­czych encji” (nie mylić z encja­mi w bazach rela­cyj­nych) lub ich agre­ga­tach. Obiektami odpo­wie­dzial­nym za ich prze­cho­wy­wa­nie są repo­zy­to­ria (Repository). Kluczowe czte­ry ope­ra­cje udo­stęp­nia­ne przez repo­zy­to­rium to wła­śnie CRUD. Pytanie brzmi: czym jest kar­to­te­ka? Jest zbio­rem kart (doku­men­tów) o jed­na­ko­wej (lub podob­nej) struk­tu­rze. Tak więc usłu­gą jest zarzą­dza­nie kar­ta­mi”, czy też odręb­ny­mi usłu­ga­mi są two­rze­nie kar­ty, czy­ta­nie, uzu­peł­nie­nie, usu­nię­cie? Popatrzmy na to z per­spek­ty­wy usłu­gi dla użyt­kow­ni­ka: ma sens posia­da­nie wygod­nej szu­fla­dy z kar­ta­mi w biblio­te­ce ale czy ma sens samo­dziel­na, wyję­ta z kon­tek­stu usłu­ga two­rze­nie nowych kart”? Można pole­mi­zo­wać, ale jeże­li chcieć utrzy­mać spój­ność poję­cio­wą i moż­li­wość kon­tro­li spój­no­ści i kom­plet­no­ści pro­jek­tu i jego zakre­su, lepiej uznać, że usłu­gą apli­ka­cyj­ną jest zarzą­dza­nie kar­ta­mi”. Po pierw­sze taka usłu­ga jest samo­wy­star­czal­na, zaś samo two­rze­nie kar­ty bez moż­li­wo­ści jej przy­wo­ła­nia nie ma sen­su, więc te czte­ry pro­ste czyn­no­ści są nie­ja­ko nie­ro­ze­rwal­nie zwią­za­ne, sta­no­wiąc jed­ną usłu­gę. Po dru­gie two­rze­nie nowe­go zapi­su, mody­fi­ko­wa­nie czy usu­wa­nie, to kon­tekst użyt­kow­ni­ka, w zasa­dzie każ­dą z czte­rech ope­ra­cji CRUD moż­na spro­wa­dzić do scenariusza:

  1. pokaż kar­tę (pusta to two­rze­nie nowe­go zapisu)
  2. zrób z tym coś (wpisz nowe, zmień, usuń) i potwierdź (zacho­waj skutek)

Dlatego są pod­sta­wy by uznać, że zarzą­dza­nie kar­ta­mi kata­lo­go­wy­mi” to jed­nak jeden przy­pa­dek uży­cia, a poszcze­gól­ne ope­ra­cje, to kon­tek­sto­we warian­ty sce­na­riu­sza wyni­ka­ją­ce z pro­ce­su czy­li chwi­lo­we­go celu użyt­kow­ni­ka (akto­ra). To podob­nie jak mło­tek (usłu­ga dostęp­na ze skrzyn­ki narzę­dzio­wej), to czło­wiek uży­wa młot­ka w kon­tek­ście wbi­ja­nie gwoź­dzia, zbi­ja­nia szy­by, roz­bi­ja­nia kamie­ni. Młotek w rękach czło­wie­ka po pro­stu słu­ży do ude­rza­nia, więc przy­pad­kiem uży­cia jest ude­rza­nie a nie czyn­ność w pro­ce­sie zbi­ja­nia budy dla psa jaką jest wbi­ja­nie gwoź­dzi w deski. Podejście takie wca­le nie jest nowe, w cie­ka­wy spo­sób opi­sał to autor tego artykułu:

If you have ever been wri­ting use cases for a data-orien­ted sys­tem (i.e. CMS), you have pro­ba­bly noti­ced that the­re is a pro­blem with the lar­ge num­ber of use cases like Add an artic­le”, Remove an artic­le” etc. If you have all CRUD ope­ra­tions ava­ila­ble for all objects in the sys­tem, you can finish with up to 4 x num­ber-of-objects of use cases. You can redu­ce this num­ber by intro­du­cing the CRUD pat­tern, which I would like to pre­sent you in this blog entry. (CRUD Pattern in Use Cases ? PUT Software Engineering Team).

Można takie podej­ście (wyni­ka­ją­ce nie­ja­ko wprost z defi­ni­cji przy­to­czo­nych pojęć), jak widać, nazwać wzor­cem pro­jek­to­wym :). Bardzo ład­nie prze­kła­da się to na archi­tek­tu­rę (model opar­ty o wzo­rzec BCE), ope­ru­ją­cą poję­cia­mi boun­da­ry (gra­ni­ca), con­troll ( ste­ro­wa­nie) i enti­ty (nośnik informacji):

Wzorzec BCE

Na powyż­szym dia­gra­mie mamy dwa przy­pad­ki uży­cia: gór­ny to typo­wy CRUD, dol­ny do usłu­ga, np. obli­cze­nio­wa. Przypadek pierw­szy (gór­ny) dodat­ko­wo korzy­sta z logi­ki Samodzielna logi­ka” tego dru­gie­go PU (inte­gra­cja dwóch aplikacji/komponentów).

Poniżej dwa cie­ka­we arty­ku­ły, roz­wi­ja­ją­ce powyż­sze. Pierwszy to tak zwa­ne mikro ser­wi­sy, wzo­rzec trak­tu­ją­cy każ­dą usłu­gę apli­ka­cyj­ną 9a tym samym przy­pa­dek uży­cia) jako odręb­ną apli­ka­cję, dru­gi poka­zu­je jak pro­jek­to­wać inter­fej­sy w takich przypadkach.

Microservices” – yet ano­ther new term on the crow­ded stre­ets of softwa­re archi­tec­tu­re. Although our natu­ral inc­li­na­tion is to pass such things by with a con­temp­tu­ous glan­ce, this bit of ter­mi­no­lo­gy descri­bes a sty­le of softwa­re sys­tems that we are fin­ding more and more appe­aling. We’ve seen many pro­jects use this sty­le in the last few years, and results so far have been posi­ti­ve, so much so that for many of our col­le­agu­es this is beco­ming the default sty­le for buil­ding enter­pri­se appli­ca­tions. Sadly, howe­ver, the­re­’s not much infor­ma­tion that outli­nes what the micro­se­rvi­ce sty­le is and how to do it. (Microservices).

Tell-Don’t-Ask is a prin­ci­ple that helps people remem­ber that object-orien­ta­tion is abo­ut bun­dling data with the func­tions that ope­ra­te on that data. It reminds us that rather than asking an object for data and acting on that data, we sho­uld inste­ad tell an object what to do. This enco­ura­ges to move beha­vior into an object to go with the data. (TellDontAsk).

Na zakończenie

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi… Zapraszam do lek­tu­ry kolej­ne­go arty­ku­łu o zarzą­dza­niu szcze­gó­ło­wo­ścią ana­li­zy..

Modelowanie obiektowe, procesy biznesowe, inżynieria oprogramowania

CASE czyli komputerowe wspomagania analizy i projektowania systemów

Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć co mamy” czy opi­sać wyma­ga­nia na to cze­go jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Model warstw AK

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my wymy­śla­ne” w celu jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Przykładowy proces biznesowy

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przypadki użycia aplikacji

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Czynność_4 - Scenariusz

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Macierz Procesy na uslugi

Macierz Uslugi na kommponenty

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

Czynność_4 Analiza wpływu

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).

Macierz RACI czyli jak nie zużyć hektara papieru

Kolejne prze­pro­wa­dzo­ne szko­le­nia za mną, kolej­na seria trud­nych pytań też. Na szko­le­niach z ana­li­zy biz­ne­so­wej poda­ję, poza opi­sem dobrych prak­tyk, tak­że anty-przy­kła­dy. Jednym z typo­wych anty-przy­kła­dów są dia­gra­my zbyt szcze­gó­ło­we, w szcze­gól­no­ści pró­by nary­so­wa­nia” kon­sul­ta­cji, serii zapę­tlo­nych zgła­sza­nych uwag do doku­men­tów i ich akcep­ta­cji, dzie­sią­tek prze­ka­zy­wa­nych komuś inne­mu infor­ma­cji. Diagram pro­ce­su BPMN nafa­sze­ro­wa­ny dzie­siąt­ka­mi rom­bów z wie­lo­ma wyj­ścia­mi w rodza­ju kto i w jakich warun­kach ma coś skon­tro­lo­wać, zaak­cep­to­wać, ode­słać do popra­wy itp. To mega dia­gra­my, nie­moż­li­we do zre­ali­zo­wa­nia pró­by algo­ryt­mi­za­cji pra­cy mode­lo­wa­nej fir­my (żad­na fir­ma nie jest deter­mi­ni­stycz­na). Przypomnę, że na pozio­mie pro­ce­sów biz­ne­so­wych (wewnętrz­ny łań­cuch war­to­ści) pętle wstecz” repre­zen­tu­ją cof­nię­cie się w cza­sie, a czy to fak­tycz­nie ma miejsce?

Szczytem tego zja­wi­ska, jakie swe­go cza­su widzia­łem, był dia­gram na któ­rym jego autor usi­ło­wał poka­zać pro­ces, w któ­rym Asystentka Zarządu pozy­ski­wa­ła trzy wyma­ga­ne do repre­zen­ta­cji pod­pi­sy pod umo­wa­mi, spo­śród pię­ciu moż­li­wych (trzech człon­ków zarzą­du i dwóch pro­ku­ren­tów wpi­sa­nych w KSR). Diagram zawie­rał pulę, sześć torów (powyż­sze oso­by) i zawi­ły pro­ces” pozy­ski­wa­nia trzech z pię­ciu moż­li­wych pod­pi­sów w posta­ci prze­pły­wów fru­wa­ją­cych” po tych sze­ściu torach. Innym przy­kła­dem tego maka­ro­ni­stycz­ne­go” (w lite­ra­tu­rze zachod­niej moż­na spo­tkać iro­nicz­ną nazwę tego podej­ścia: spa­ghet­ti mode­ling) podej­ścia to dia­gra­my poka­zu­ją­ce np. moc­no zapę­tlo­ne pro­ce­sy zawie­ra­ją­ce wszel­kie­go typu kon­sul­ta­cje i korek­ty dokumentów.

Więc jak, skoro nie tak?

Kilka lat temu wspo­mnia­łem o macie­rzy RACI pisząc o meto­dach” mode­lo­wa­nia pro­ce­sów. Tu kil­ka słów na temat tego jaką war­tość wno­si ta macierz do mode­lu. W arty­ku­le tym napi­sa­łem, że sama macierz RACI nie jest mode­lem pro­ce­su. Tu poka­że, że macierz ta jest (może być) jed­nak uzu­peł­nie­niem mode­lu pro­ce­su. Co ozna­cza­ją kolej­ne lite­ry skró­ty RACI? 

  • R – Responsible, to oso­ba odpo­wie­dzial­na za daną aktyw­ność (pro­ces) i rezul­tat (pro­dukt). Z regu­ły wyko­naw­ca pro­ce­su, jeże­li jest to ato­mo­wy pro­ces biz­ne­so­wy (aktyw­ność).
  • A – Accountable/Approver, to oso­ba odpo­wie­dzial­na za wery­fi­ka­cję i zatwier­dze­nie pro­duk­tu, roz­li­cza­na z uzy­ska­ne­go efek­tu, z regu­ły czyn­ność ta jest ostat­nią czyn­no­ścią pro­ce­du­ry danej aktywności.
  • C – Consulted, to oso­ba (jed­na lub wię­cej) posia­da­ją­ca wie­dzę wyma­ga­ną w toku reali­za­cji danej aktyw­no­ści, któ­ra na żąda­nie wyko­naw­cy udzie­la mu konsultacji.
  • I – Informed, to oso­ba (jed­na lub wię­cej), któ­ra jest infor­mo­wa­na o pro­duk­cie aktywności.
RACImatrix

(źr. https://​www​.youtu​be​.com/​w​a​t​c​h​?​v​=​r​W​p​L​e​2​3​p​i0g)

Kolejna waż­na rzecz: ludzie w fir­mach (ich sta­no­wi­ska, role itp.) poza tym, że są (nie raz) wyko­naw­ca­mi pro­ce­sów, są tak­że zaso­ba­mi fir­my! A na dia­gra­mach pro­ce­sów nie poka­zu­je­my zaso­bów, tyl­ko role i aktyw­no­ści za jakie te role odpo­wia­da­ją (wyko­nu­ją). Tak więc sprze­daw­ca, jako swój zasób, ma cen­nik, z któ­re­go korzy­sta pod­czas opra­co­wy­wa­nia ofert. Jednak w przy­pad­ku gdy nie ma cen­ni­ka, kon­sul­tu­je się z oso­bą, któ­ra zna ceny. Może to robić lub nie zależ­nie od sytu­acji. Czy to zna­czy, że mamy dwa róż­ne pro­ce­sy opra­co­wa­nia ofer­ty? Nie! Sprzedawca korzy­sta z cen­ni­ka dru­ko­wa­ne­go lub kon­sul­tu­je się (wie z kim powi­nien) z okre­ślo­nym spe­cja­li­stą w fir­mie. Ten spe­cja­li­sta, w tym przy­pad­ku, jest zaso­bem fir­my, z któ­re­go moż­na korzy­stać (z jego wiedzy).

Tak więc pro­ce­sy, ich mode­le, są (powin­ny być) rela­tyw­nie pro­ste. Ewentualna ich zło­żo­ność tkwi mię­dzy inny­mi w wyko­rzy­sta­niu (obli­ga­to­ryj­nym lub opcjo­nal­nym) zaso­bów, jaki­mi są mię­dzy inny­mi inni pra­cow­ni­cy (Prezes fir­my tak­że jest, w wie­lu pro­ce­sach, zaso­bem ludz­kim” fir­my, a nie wykonawcą). 

Macierz RACI to narzę­dzie poka­zu­ją­ce i doku­men­tu­ją­ce zara­zem, poza­pro­ce­so­we zależ­no­ści mię­dzy wyko­naw­ca­mi pro­ce­sów biz­ne­so­wych, bo na mode­lach pro­ce­sów biz­ne­so­wych poka­zu­je­my wyłącz­nie łań­cuch war­to­ści doda­nej (pro­ces biz­ne­so­wy two­rzy war­tość doda­ną). Reszta to zaso­by wyma­ga­ne w danym pro­ce­sie (kon­sul­tan­ci, akcep­tan­ci, infor­mo­wa­ni), któ­rych na mode­lu pro­ce­su nie ma, korzy­sta z nich rola” jako ten (ta), kto odpo­wia­da za wyko­na­nie danej pra­cy. Wtedy dia­gram pro­ce­su pozy­ska­nia wła­ści­wych pod­pi­sów pod umo­wą jest bar­dzo pro­sty: jed­na czyn­ność pozy­ska­nie pod­pi­sów”, sko­ja­rze­ni są z nią (macierz RACI jako uzu­peł­nie­nie dia­gra­mu z mode­lem pro­ce­su) akcep­tan­ci”, czy­li Ci, któ­rzy mogą się pod­pi­sać oraz regu­ła biz­ne­so­wa, mówią­ca, że mają być dwa podpisy. 

Na pew­nej dość cie­ka­wej stro­nie WWW moż­na zna­leźć taki cie­ka­wy diagram:

RACI stands for

Tak więc czte­ry role w macie­rzy RACI to: A – ktoś kto może wstrzy­mać pro­ces, R – wyko­naw­ca (reali­za­tor) pro­ce­su, C – kon­sul­tant (pętla kon­sul­ta­cji) oraz I czy­li ten kto cze­ka na infor­ma­cje o zakoń­cze­niu (sub­skry­bent). (źr. )

Polowanie na wykonawcę

Drugim przy­kła­dem wystę­po­wa­nia zja­wi­ska spa­ghet­ti mode­ling” są sytu­acje, w któ­rych np. fak­tu­rę może wysta­wić wię­cej niż jed­na oso­ba w fir­mie. Np. może to być głów­na księ­go­wa, spe­cja­li­sta ds. księ­go­wych i asy­stent sprze­da­ży. Widywałem dia­gra­my pro­ce­su sprze­da­ży, na któ­rych były tory wszyst­kich tych osób” oraz zło­żo­ny prze­pływ (masa bra­mek i nie­ja­snych kry­te­riów wybo­ru) poka­zu­ją­cy spo­sób wybo­ru, któ­ra z tych wymie­nio­nych osób, wysta­wi w danym przy­pad­ku tę fak­tu­rę. Diagram taki wyglą­da tro­chę jak polo­wa­nie na jele­nia” :).

Rzecz w tym, że w bar­dzo wie­lu przy­pad­kach okre­ślo­ne role (tu fak­tu­ro­wa­nie) mogą być przy­po­rząd­ko­wa­ne do kil­ku róż­nych sta­no­wisk w struk­tu­rze orga­ni­za­cyj­nej. Jak to poka­zać? Nie na mode­lu pro­ce­su. Informacje te są (powin­ny być) na mode­lu struk­tu­ry orga­ni­za­cyj­nej. Przyzwyczajeni jeste­śmy do struk­tu­ry orga­ni­za­cyj­nej w posta­ci drze­wa komór­ka orga­ni­za­cyj­na, prze­ło­żo­ny, pod­wład­ny”. Na potrze­by ana­li­zy potrzeb­ny jest nam jed­nak sfor­ma­li­zo­wa­ny model, w któ­rym nie koń­czy­my” na sta­no­wi­skach a na kom­pe­ten­cjach (rolach – funk­cjach biz­ne­so­wych). Na takim dia­gra­mie, poza sta­no­wi­ska­mi głów­na księ­go­wa, spe­cja­li­sta ds. księ­go­wych i asy­stent sprze­da­ży” poja­wi się przy każ­dym z nich blo­czek fak­tu­ro­wa­nie” (jako Funkcja biz­ne­so­wa). Do tej pory for­ma­li­za­cję struk­tu­ry orga­ni­za­cyj­nej robi­łem na wła­sna rękę”, ale na szczę­ście opra­co­wy­wa­ny jest już przez orga­ni­za­cję OMG model struk­tu­ry orga­ni­za­cyj­nej, któ­ry to (taki spo­sób mode­lo­wa­nia struk­tur orga­ni­za­cyj­nych) narzu­ca, w spo­sób prak­tycz­nie taki jak tu opi­sa­łem i sam stosuję.

Tak więc na mode­lu pro­ce­su sprze­da­ży, będzie czyn­ność wysta­wie­nia fak­tu­ry, wyko­naw­cą jest rola Fakturzysta”, a na struk­tu­rze orga­ni­za­cyj­nej, dodat­ko­wy blo­czek: Fakturzysta, będzie sko­ja­rzo­ny z głów­ną księ­go­wą, spe­cja­li­stą ds. księ­go­wych i asy­sten­tem sprze­da­ży. Model będzie pro­sty”.

Na zakoń­cze­nie. Trudność two­rze­nia mode­li pro­ce­sów biz­ne­so­wych pole­ga na wyłu­ska­niu isto­ty rze­czy a nie na umiesz­cze­niu na dia­gra­mach wszyst­kie­go tego, cze­go się dowie­my pod­czas wywia­dów. To dru­gie nazy­wa się raczej ste­no­gram”.

Analityk ma uogól­niać, ana­li­zo­wać i doku­men­to­wać (mode­lo­wać) sens i spo­sób dzia­ła­nia, jego cele. Nie jest rolą ana­li­ty­ka, pod­czas mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, zapi­sy­wa­nie w for­mie rysun­ku, wszyst­kie­go tego cze­go się dowiedział.

Model pro­ce­sów biz­ne­so­wych nie jest samo­wy­star­czal­ny”, musi być sko­ja­rzo­ny z wzo­ra­mi doku­men­tów, zakre­sa­mi obo­wiąz­ków czy wła­śnie macie­rza­mi RACI. Próba umiesz­cze­nia całej tej wie­dzy na dia­gra­mach, pro­wa­dzi do nie­czy­tel­nych, prze­ła­do­wa­nych szcze­gó­ła­mi, prak­tycz­nie nie­przy­dat­nych, diagramów.

Jeżeli więc ktoś Państwu zafun­du­je model (mapy) pro­ce­sów biz­ne­so­wych na set­kach dia­gra­mów, a na każ­dym dzie­siąt­ki blocz­ków, to nale­ży się zasta­no­wić nad tym, czym te dia­gra­my są i do cze­go mogą posłu­żyć (i czy w ogó­le mogą się na coś przy­dać). Chyba, że sami Państwo o takie dia­gra­my, tak szcze­gó­ło­we i w takiej ilo­ści, popro­si­li… tyl­ko, że ja zapy­tam: po co?

Przykład

Mam nadzie­ję, że powyż­sze daje do myśle­nia” i skło­ni do reflek­sji nad dostaw­ca­mi usług mode­lo­wa­nia pro­ce­sów biz­ne­so­wych”. Tu pro­sty przy­kład ilu­stru­ją­cy powyż­sze dobre praktyki.

Struktura orga­ni­za­cyj­na z nanie­sio­ną infor­ma­cją o funk­cjach biznesowych:

Model struktury organizacyjnej

Model pro­ce­su biz­ne­so­we­go, Funkcje biz­ne­so­we mapu­ją się 1:1 na role:

Model procesu

Lista doku­men­tów z koda­mi CRUD poka­zu­ją­ca dodat­ko­wo, co dzie­je się z doku­men­ta­mi w pro­ce­sach (doce­lo­wo mogą być mapo­wa­ne na przy­pad­ki użycia):

CRUDmatrix

oraz macierz RACI poka­zu­ją­ca pozo­sta­łe zada­nia” poszcze­gól­nych Ról w tym procesie:

RACImatrix

Proszę sobie wyobra­zić zło­żo­ność powyż­sze­go dia­gra­mu pro­ce­su, gdy­by sta­rać się na nie­go nanieść wszyst­kie infor­ma­cje z tych macierzy…

(mode­le wyko­na­ne z uży­ciem pakie­tu VP).

Cabanillas, C., Resinas, M. and Ruiz-Cortés, A. (2012) Automated Resource Assignment in BPMN Models Using RACI Matrices’, in R. Meersman et al. (eds) On the Move to Meaningful Internet Systems: OTM 2012. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 56 – 73. Available at: https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 33606-5_5.