Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam ​„biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo ​„takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

• nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
• w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
• two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
• „seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich ​„kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? ​„Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li ​„co i po co” a nie ​„jak”. Owo ​„jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem ​„pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
3. Procesy biz­ne­so­we,
4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je ​„zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia ​„komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

Notacje, któ­re ​„wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści ​„pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su ​„wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce ​„współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we ​„repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da ​„od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia ​„opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).