Wprowadzenie

Od kil­ku już lat jestem, jako eks­pert, anga­żo­wa­ny jako rze­czo­znaw­ca do spo­rzą­dza­nia opi­nii na zle­ce­nie sądów (opi­nia bie­głe­go) lub jed­nej ze stron spo­ru (opi­nia pry­wat­na). Są to spo­ry doty­czą­ce nie­uda­nych dostaw i wdro­żeń opro­gra­mo­wa­nia, nie tyl­ko ERP, bar­dzo czę­sto tak­że dedykowanego. 

Po tych latach wyła­nia się pewien wspól­ny mia­now­nik, łączą­cy te poraż­ki scenariusz:

1. fir­ma dosta­je ofer­tę na dostar­cze­nie i wdro­że­nie oprogramowania,
2. ma miej­sce pre­zen­ta­cja pomy­słu, jakieś makie­ty, jakaś dzia­ła­ją­ca funkcjonalność,
3. przed­mio­tem ofer­ty jest pre­zen­to­wa­ne ist­nie­ją­ce opro­gra­mo­wa­nie z obiet­ni­cą jego dosto­so­wa­nia (kasto­mi­za­cji), lub ofer­ta wyko­na­nia dedy­ko­wa­ne­go oprogramowania,
4. pro­jekt przyj­mu­je for­mę umo­wy T&M, poda­ne są staw­ki wykonawcy,
5. pra­wa autor­skie (oso­bi­ste i mająt­ko­we) do tego co powsta­je w toku pro­jek­tu, są ​„z zasa­dy” należ­ne wyko­naw­cy, z moż­li­wo­ścią prze­ka­za­nia praw mająt­ko­wych zama­wia­ją­ce­mu (czę­sto za dodat­ko­wą opłatą),
6. praw­ni­cy obu stron nie mają do powyż­sze­go żad­nych zastrze­żeń, sku­pia­ją na for­mal­no­ściach: zawar­cie umo­wy, jej roz­wią­za­nie, prze­ka­za­nie praw mająt­ko­wych do kodu, warun­ki płat­no­ści itp… w zasa­dzie nic co doty­czy przed­mio­tu umo­wy, bo nie ist­nie­je opis przed­mio­tu umo­wy (nie licząc licen­cji na stan­dar­do­we opro­gra­mo­wa­nie i ogól­ne­go celu zamawiającego),
7. począ­tek pro­jek­tu, szyb­ko powsta­je (albo jest goto­we) tak zwa­ne MVP (Minimum Valuable Product), zama­wia­ją­cy nabie­ra zaufa­nia do dostaw­cy, uwie­rzył w zwin­ne projektowanie, 
8. kolej­ne funk­cjo­nal­no­ści zaczy­na­ją nastrę­czać pro­ble­mów, ale wszy­scy są dobrej myśli, zama­wia­ją­cy zaczy­na coraz czę­ściej sły­szeć, że to on jest pro­ble­mem bo zmie­nia wyma­ga­nia i wie­rzy, że to on jest powo­dem pro­ble­mów, dostaw­ca mówi że tak (dłu­go i dro­go) ma być to biz­nes się zmie­nia i trze­ba płacić,
9. zależ­nie od cier­pli­wo­ści zama­wia­ją­ce­go, zaczy­na sie eska­la­cja pro­ble­mu, w zasa­dzie nic nie jest tak jak powin­no być, zama­wia­ją­cy zaczy­na pono­sić straty, 
10. zama­wia­ją­cy wstrzy­mu­je płat­ność za ostat­nią fak­tu­rę (z powo­du umo­wy T&M, poprzed­nie są już w prak­tycz­nie nie­odzy­ski­wal­ne), zaczy­na sie spór, zaczy­na­ją zara­biać kan­ce­la­rie praw­ne, czę­sto te same, któ­re wspie­ra­ły pro­jekt na eta­pie zawie­ra­nia umowy. 

Mityczne MVP?

Co jest pro­ble­mem wie­lu firm? Zarząd, któ­ry nie ma pomy­słu na roz­wój. Czy musi go mieć? Nie, może zaan­ga­żo­wać ana­li­ty­ka, któ­ry opra­cu­je model dzia­ła­nia orga­ni­za­cji i wska­że na nim moż­li­we uspraw­nie­nia. Jednak wie­lu nie robi tego wie­rząc, że dobrym pomy­słem jest już samo roz­po­czę­cie meto­dą prób i błędów. 

Generalnie więc powo­dem pro­ble­mów jest zupeł­ny brak pomy­słu na to czym ma być roz­wią­za­nie, a sam pro­blem jest zary­so­wa­ny ogól­nie i czę­sto do koń­ca nie­zro­zu­mia­ny. Mimo to obie stro­ny – fir­ma i dewe­lo­per – są peł­ne zapału. 

Jednym z typo­wych argu­men­tów dewe­lo­pe­rów na eta­pie ofer­to­wa­nia i pre­zen­to­wa­nia ​„meto­dy­ki pra­cy” jest mitycz­ne MVP, czę­sto pre­zen­to­wa­ne jak poniżej:

Rysunek ten, w tej i podob­nych wer­sjach krą­ży po stro­nach WWW dewe­lo­pe­rów i jest chy­ba jed­nym naj­bar­dziej mani­pu­la­cyj­nych i nie­praw­dzi­wych sche­ma­tów. Deweloperzy czę­sto argu­men­tu­ją, że ścież­ka dol­na jest dłu­ga i kosz­tow­na, trze­ba pła­cić i dłu­go cze­kać na osta­tecz­ną wer­sję pro­duk­tu, bo naj­pierw trze­ba ponieść kosz­ty pro­jek­to­wa­nia, a do tego cza­su ​„nic nie ma”. Sugerują, że szyb­ko coś przy­dat­ne­go dostar­czą (MVP). W czym problem? 

W tym, że: 

1. fak­tycz­nie roz­wią­za­niem pro­ble­mu (potrze­ba biz­ne­so­wa) jest ostat­nia pozy­cja po prawej,
2. wszyst­kie kolej­ne pośred­nie urzą­dze­nia powsta­ją na koszt zama­wia­ją­ce­go, są odrzu­ca­ne (nie speł­nia­ją wyma­gań) a real­nie w niczym nie poma­ga­ją, no bo roz­wią­za­niem (potrze­bą) jest osta­tecz­ny produkt, 
3. zama­wia­ją­cy nie ma kom­pe­ten­cji (a nie raz nie ma dostę­pu do kodu) i nie wie, że real­nie pła­ci za kod, któ­ry jest zastę­po­wa­ny kolej­nym pomy­słem, i tak wie­le razy, cały czas na jego koszt,
4. dol­na ścież­ka real­nie, jest znacz­nie krót­sza, bo pro­jek­to­wa­nie pro­duk­tu na mode­lach jest co naj­mniej o rząd wiel­ko­ści tań­sze i znacz­nie szyb­sze, nie reali­zo­wa­ne zbęd­ne pra­ce na odrzu­ca­nych prototypach,
5. prak­ty­ka poka­zu­je, że w dniu pod­pi­sa­nia umo­wy zama­wia­ją­cy też nie wie (nie ma pomy­słu, kon­cep­cji) co ma osta­tecz­nie powstać, więc gene­ral­nie pro­jekt sie toczy bez żad­ne­go pla­nu i kon­tro­li kosztów, 
6. auto­rzy tego obraz­ka cał­ko­wi­cie pomi­nę­li fakt, że dzi­siej­sze apli­ka­cje, podob­nie jak ten samo­chód, w 90% powsta­ją z goto­wych i dostęp­nych na ryn­ku kom­po­nen­tów, więc real­nie raczej nie wymy­śla­my koła na nowo.

Tak więc cała powyż­sza ​„meto­da” to cał­ko­wi­cie nie­pla­no­wa­ny, bar­dzo kosz­tow­ny pro­ces z dużym ryzy­kiem, że nie powsta­nie nic war­to­ścio­we­go bo brak­nie cza­su i środ­ków. I tak wła­śnie wyglą­da­ją te spor­ne projekty. 

Troszkę teorii: Komponenty i Paradygmat Obiektowy

Paradygmat obiek­to­wy to her­me­ty­za­cja i wymia­na komu­ni­ka­tów, a nie ​„dzie­dzi­cze­nie i łącze­nie funk­cji i danych w obiek­ty”, któ­re jest cechą pierw­szych języ­ków obiek­to­wych i sto­so­wa­nych w nich wzor­cach (C++/Java). W zasa­dzie JavaEE/Spring to fra­me­work opar­ty na antyw­zor­cach (ane­micz­ny model dzie­dzi­ny, set/get, brak sepa­ra­cji logi­ki od bac­ken­du, patrz arty­kuł: Ten strasz­ny dia­gram klas).

Popatrzmy na to:

Diagram powy­żej poka­zu­je typo­wą mono­li­tycz­ną archi­tek­tu­rę po lewej stro­nie. Kluczowe cechy mono­li­tu to fakt, że każ­da zmia­na funk­cjo­nal­no­ści wyma­ga refac­to­rin­gu kodu i migra­cji danych do nowej, więk­szej bazy o nowej struk­tu­rze. Za każ­dym kolej­nym razem jest to trud­niej­sze i kosz­tow­niej­sze. Jeżeli zaś jest to np. kasto­mi­zo­wa­ny sys­tem ERP, to prak­tycz­nie na więk­szą ska­lę jest to nie­moż­li­we (dla­te­go pro­du­cen­ci tych sys­te­mów odra­dza­ją takie podej­ście, patrz arty­kuł: Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje).

Po pra­wej stro­nie mamy archi­tek­tu­rą kom­po­nen­to­wą, potocz­nie i powszech­nie okre­śla­ną jako mikro-ser­wi­sy, cza­sa­mi jako mikro-apli­ka­cje. Jest to tak na praw­de zna­na od lat 90-tych archi­tek­tu­ra kom­po­nen­to­wa , patrz tak­że .

Kluczową cechą tej archi­tek­tu­ry jest wza­jem­na komu­ni­ka­cja kom­po­nen­tów (inte­gra­cja) jako wymia­na komu­ni­ka­tów, a nie współ­dzie­le­nie jed­nej bazy danych (wte­dy real­nie nadal był­by to mono­lit). Ta komu­ni­ka­cja to na powyż­szym dia­gra­mie sza­re linie z gro­ta­mi. Integracje opi­sa­łem w arty­ku­le Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­wej. Projektowanie REST API i sce­na­riu­szy. Dzisiaj sku­pie się tu na wyja­śnie­niu jak komu­ni­ka­ty zastę­pu­ją cen­tral­ne współ­dzie­lo­ne bazy danych.

Podstawowym ele­men­tem komu­ni­ka­cji są komu­ni­ka­ty. Z uwa­gi na to, że orga­ni­za­cja to sys­tem komu­ni­ku­ją­cych się mię­dzy sobą ludzi, ludzi z kom­pu­te­ra­mi i kom­pu­te­rów mię­dzy sobą, poję­cia ​„doku­ment” i ​„komu­ni­kat” nale­ży uznać za toż­sa­me, gdyż komu­ni­ka­cja czło­wiek-czło­wiek, niczym się nie róż­ni od komu­ni­ka­cji czło­wiek-kom­pu­ter czy kom­po­ter-kom­pu­ter .

Powyższy sche­mat to przy­kład współ­pra­cy kil­ku kom­po­nen­tów: każ­dy z nich wyko­nu­je jakieś czyn­no­ści, są one ini­cjo­wa­ne otrzy­ma­nym komu­ni­ka­tem, wynik dzia­ła­nia tak­że jest prze­ka­zy­wa­ny jako komu­ni­kat. Każdy z tych kom­po­nen­tów może prze­cho­wy­wać histo­rie tych komu­ni­ka­tów (lokal­ne repo­zy­to­rium kom­po­nen­tu). Takie komu­ni­ka­ty mogą zawie­rać róż­ne tre­ści, nie raz nad­mia­ro­we z per­spek­ty­wy jed­ne­go kom­po­nen­tu, ale zawsze spój­ne kon­tek­sto­wo. Bardzo czę­sto w sys­te­mach wystę­pu­ją kom­po­nen­ty, któ­rych celem jest kolek­cjo­no­wa­nie danych, a odby­wa się to po pro­stu jako zbie­ra­nie okre­ślo­nych komu­ni­ka­tów (doku­men­tów).

Np. fak­tu­ra to dokument/komunikat nio­są­cy dane o doko­na­nej trans­ak­cji. Jest on nośni­kiem danych dla dzia­łu księ­go­wo­ści, dla klien­ta, na żąda­nie dla Urzędu Skarbowego, itp.. Mimo tego, że każ­dy z wymie­nio­nych korzy­sta tyl­ko z czę­ści tre­ści fak­tu­ry, prze­ka­zy­wa­na jest zawsze cała fak­tu­ra, bo to uprasz­cza cały system. 

Kluczem jest zro­zu­mie­nie tego, że kom­pu­te­ry prze­twa­rza­ją i wymie­nia­ją dane a ludzie prze­twa­rza­ją i wymie­nia­ją infor­ma­cje. Sztuką pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych jest dekom­po­zy­cja pro­ble­mu, pro­jek­to­wa­nie komu­ni­ka­tów (tre­ści doku­men­tów) oraz zro­zu­mie­nie i opi­sa­nie mecha­ni­zmów ich powsta­wia­nia i korzy­sta­nia z nich. Potem pozo­sta­je już tyl­ko imple­men­ta­cja: zbu­do­wa­nie sys­te­mu infor­ma­tycz­ne­go (patrz: Architektura infor­ma­cji, sys­tem infor­ma­cyj­ny a sys­tem infor­ma­tycz­ny w orga­ni­za­cji).

Powyższy dia­gram poka­zu­je tak­że, że pró­ba budo­wa­nia archi­tek­tu­ry, w któ­rej kil­ka, kil­ka­na­ście wymie­nia­nych komu­ni­ka­tów mia­ło by być zamie­nio­nych na jeden współ­dzie­lo­ny stos wszyst­kich danych, będzie bar­dzo trud­na do zbu­do­wa­nia i jesz­cze trud­niej­sza do wpro­wa­dza­nia w niej zmian. 

Podsumowując: każ­da orga­ni­za­cja i jej oto­cze­nie to ​„sys­tem wymia­ny danych” a nie ​„sys­tem współ­dzie­le­nia danych”. Dlatego świat od daw­na odcho­dzi od mono­li­tów na rzecz komu­ni­ku­ją­cych sie kom­po­nen­tów (mikro-ser­wi­sy, mikro-apli­ka­cje, kom­po­nen­ty). Budowanie wspól­ne­go, cen­tral­ne­go mode­lu danych dla wie­lo­mo­du­ło­wych sys­te­mów w zasa­dzie nigdy nie mia­ło sen­su ani szans powodzenia:

Dlaczego problemy pojawiają sie ​„dopiero później”, na początku było dobrze i klient był zadowolony

Paradoksalnie wyja­śnie­nie jest dość pro­ste: u dewe­lo­pe­rów nadal domi­nu­ją meto­dy opar­te o mono­li­tycz­ne archi­tek­tu­ry. Głoszenie sto­so­wa­nia ​„obiek­to­wych metod pro­gra­mo­wa­nia” ozna­cza tyl­ko tyle, że zasto­so­wa­no tak zwa­ny ​„obiek­to­wo zorien­to­wa­ny język pro­gra­mo­wa­nia”, co abso­lut­nie nie ozna­cza, że archi­tek­tu­ra tego co powsta­nie będzie nowo­cze­sna. Praktyka audy­tów poka­zu­je, że raczej będzie to skan­sen archi­tek­to­nicz­ny opar­ty o rela­cyj­ny model danych, wie­lo­po­zio­mo­we dzie­dzi­cze­nie i naj­gor­sze prak­ty­ki mode­lo­wa­nia danych jaki­mi są ane­micz­ny model dzie­dzi­ny i płyt­kie pła­skie kla­sy z ogrom­na licz­bą ope­ra­cji (w tym set/get dla każ­de­go atry­bu­tu klas repre­zen­tu­ją­cych tabe­le bazy danych, patrz arty­kuł: Ten strasz­ny dia­gram klas).

Dlatego ten sce­na­riusz czę­sto wyglą­da tak, że na począt­ku powsta­je opro­gra­mo­wa­nie reali­zu­ją­ce jed­ną okre­ślo­ną funk­cję, to czę­sto zaro­dek mono­li­tu. Wszystko ład­nie dzia­ła, klient się cie­szy, zawie­ra (prze­dłu­ża) umo­wę. Kolejne funk­cjo­nal­no­ści to począ­tek dra­ma­tu: roz­bu­do­wa mono­li­tycz­ne­go mode­lu danych, migra­cje ze sta­re­go mode­lu do nowe­go, nara­sta­ją­ce pro­ble­my mono­li­tycz­nej archi­tek­tu­ry: wszyst­ko się sypie bo wszyst­ko zale­ży od wszyst­kie­go, i nie wia­do­mo jak, bo nie ma żad­nej doku­men­ta­cji mecha­ni­zmu dzia­ła­nia apli­ka­cji, zaś kod od daw­na nie nada­je się już czy­ta­nia. Próba napra­wy tego też zaczy­nam być gonie­niem kró­licz­ka…. i jest spór.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem 

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Źródła