Bazy NoSQL jako implementacje wzorców struktur informacji

Dane nie­struk­tu­ral­ne sta­no­wią ponad 80% skła­do­wa­nych danych, to ozna­cza, że model rela­cyj­ny pozwa­la opi­sać i prze­twa­rzać tyl­ko uła­mek posia­da­nej infor­ma­cji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W pod­su­mo­wa­niu nie­daw­ne­go arty­ku­łu o NoSQL w chmu­rze, napisałem: 

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmu­rze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie wła­śnie uka­zał. We wstę­pie napisałem:

Dokumenty czę­sto zawie­ra­ją dużą ilość róż­nych danych two­rzą­cych wspól­nie wie­le kon­tek­sto­wych zbio­rów danych (agre­ga­tów). Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­za­cji takich danych pro­wa­dzi do wyge­ne­ro­wa­nia roz­bu­do­wa­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel, przy czym usu­nię­cie redun­dan­cji czę­sto powo­du­je utra­tę kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. Rodzi to koniecz­ność sto­so­wa­nia wyso­ce zło­żo­nych zapy­tań SQL, aby doku­men­ty te mogły być zapi­sy­wa­ne w tej bazie danych i z niej pobie­ra­ne. W ten spo­sób sama baza danych zawie­ra wyłącz­nie dane pozba­wio­ne kon­tek­stu obec­ne­go w tabe­lach, a nie dokumenty.

Wielu auto­rów zwra­ca­ło uwa­gę na pro­blem zło­żo­no­ści i utra­ty jed­no­li­te­go kon­tek­stu mode­lu rela­cyj­ne­go (Ślęzak i in., 2018). Autorzy ci suge­ro­wa­li, że kon­tek­sty powin­ny być sepa­ro­wa­ne w dużych rela­cyj­nych mode­lach danych. Jednak zale­ce­nie sepa­ra­cji kon­tek­stów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zacho­wa­niu mode­lu rela­cyj­ne­go, nie poma­ga w cał­ko­wi­tym roz­wią­za­niu pro­ble­mu (Awang et al., 2012, 2012, 2012).

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych (Danesi, 2004). Podejmowane pró­by zacho­wa­nia zna­cze­nia danych czę­sto pro­wa­dzą do two­rze­nia roz­bu­do­wa­nych rela­cyj­nych mode­li danych, gene­ru­jąc tym samym dodat­ko­we kosz­ty. Dlatego też wyko­rzy­sta­nie jed­ne­go rela­cyj­ne­go mode­lu danych do zapi­su zawar­to­ści wie­lu róż­nych doku­men­tów może uczy­nić z takie­go sys­te­mu ogrom­ny i nie­po­dziel­ny mono­lit, któ­ry jest kosz­tow­ny zarów­no w roz­wo­ju, jak i w utrzy­ma­niu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Rodzaje baz danych NoSQL na rynku

Praktyka poka­zu­je, że bazy te to odpo­wiedź na stan­dar­do­we obec­nie wyma­ga­nia wobec sys­te­mów infor­ma­cyj­nych, jaki­mi są zmien­ność struk­tur danych, ich ogra­ni­czo­na struk­tu­ra­li­za­cja lub nawet jej cał­ko­wi­ty brak .

Akronim NoSQL został po raz pierw­szy uży­ty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lek­kiej, open­so­ur­ce rela­cyj­nej” bazy danych, któ­ra nie uży­wa­ła SQL. Nazwa ta poja­wi­ła się ponow­nie w 2009 roku, kie­dy Eric Evans i Johan Oskarsson uży­li jej do opi­sa­nia nie­re­la­cyj­nych baz danych. Relacyjne bazy danych są czę­sto okre­śla­ne jako sys­te­my SQL. Termin NoSQL może ozna­czać zarów­no Nierelacyjna SQL” lub bar­dziej popu­lar­ne tłu­ma­cze­nie Nie tyl­ko SQL” (Not only SQL), aby pod­kre­ślić fakt, że nie­któ­re sys­te­my mogą obsłu­gi­wać języ­ki zapy­tań podob­ne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zda­niem cie­kaw­szych arty­ku­łów o NoSQL napi­sał Fowler 10 lat temu .

Bazy danych «key-value».

Bazy te są naj­prost­szym typem bazy NoSQL. Każdy ele­ment (wiersz) w takiej bazie to para klucz i war­tość (dane prze­cho­wy­wa­ne), tu zawar­tość (dane prze­cho­wy­wa­ne) to zawsze jakiś plik” (podob­nie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobra­na wyłącz­nie poprzez odwo­ła­nie się do jej iden­ty­fi­ka­to­ra (klu­cza) . Bazy te są dosko­na­łe do prze­cho­wy­wa­nia dużych ilo­ści róż­no­rod­nych danych, gdzie nie trze­ba prze­twa­rzać tre­ści tych danych w samej bazie (np. wyszu­ki­wa­nie zawar­to­ści na pod­sta­wie jej okre­ślo­nych cech). Służą one wyłącz­nie do zacho­wy­wa­nia i odzy­ski­wa­nia pli­ków. Praktycznie jest to pła­ski sys­tem plików. 

model repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 
meto­da zapi­su w repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 

Dokumentowe bazy danych. 

To odmia­na bazy key-value. Przechowuje dane w posta­ci okre­ślo­nej struk­tu­ral­nej tre­ści: doku­men­tów (np. JSON czy XML). Struktury te mają swo­je defi­ni­cje, a ich typów może być dowol­na licz­ba . Jedna baza może więc zawie­rać doku­men­ty o dowol­nie wybra­nej, okre­ślo­nej struk­tu­rze. Dostępne na ryn­ku bazy tego typu maja tak­że bar­dzo dobre i szyb­kie moto­ry zapy­tań, są coraz czę­ściej sto­so­wa­ne jako bazy danych ogól­ne­go przeznaczenia. 

Baza doku­men­to­wa. Dokument to czy­tel­na dla czło­wie­ka treść, w bazach doku­men­to­wych ma on okre­ślo­na ale nie sztyw­ną struk­tu­rę: może to być JSON, XML. Dokument (jego treść) jest prze­twa­rza­ny poza bazą danych (kom­po­nent Logika biz­ne­so­wa). (opra­co­wa­nie wła­sne autora) 

Bazy zmieno-kolumnowe.

Przechowują dane w posta­ci agre­ga­tów o zmien­nych liściach”. Bazy tego typu zapew­nia­ją dużą ela­stycz­ność w sto­sun­ku do rela­cyj­nych baz danych, ponie­waż nie jest wyma­ga­ne, aby każ­dy wiersz agre­gat posia­dał tyle samo i te same ele­men­ty (kolum­ny) . Bazy tego typu są powszech­nie sto­so­wa­ne do prze­cho­wy­wa­nia danych np. danych pro­fi­lo­wych użyt­kow­ni­ków. Są czę­sto opi­sy­wa­ne w poniż­szy sposób:

Diagram of a column family in a wide column store database.
Model archi­tek­tu­ry kom­po­nen­tu z bazą zmien­no-kolum­no­wą (powyż­sze wyra­żo­ne jako model dzie­dzi­ny kom­po­nen­tu z uży­ciem UML)

Jak widać, bazy te prze­cho­wu­ją agre­ga­ty. Nazwanie agre­ga­tu wier­szem” jest nie­for­tun­ne bo to jed­nak nie są pła­skie tabe­le, jed­nak poję­cia wier­szy i kolumn zrzu­cam tu jed­nak na karb ste­reo­ty­pu zaczerp­nię­te­go z mode­lu relacyjnego.

Grafowe bazy danych. 

Przechowują dane w posta­ci węzłów i kra­wę­dzi (aso­cja­cje mię­dzy węzła­mi). Węzły zazwy­czaj prze­cho­wu­ją infor­ma­cje o obiek­tach (ludzie, miej­sca, przed­mio­ty) kra­wę­dzie zaś prze­cho­wu­ją infor­ma­cje o moż­li­wych związ­kach mię­dzy węzła­mi . Grafowe bazy danych dosko­na­le spraw­dza­ją się w przy­pad­kach gdy trze­ba zapi­sy­wać i śle­dzić związ­ki mię­dzy obiek­ta­mi i ana­li­zo­wać je, np. sie­ci spo­łecz­no­ścio­we czy wykry­wa­nie oszustw. Tak są naj­czę­ściej opi­sy­wa­ne gra­fo­we bazy danych, a przed­sta­wia­ne są np. tak:

Uważam, że powyż­sze to try­wial­na i naiw­na meto­da przed­sta­wia­nia baz tego typu. Istotą sys­te­mu prze­twa­rza­nia infor­ma­cji jest tu (w takim mode­lu) jest prze­cho­wy­wa­nie infor­ma­cji o obiek­tach i o fak­tach je łączą­cych takich jak zda­rze­nia doty­czą­ce pary obiek­tów . Mogą to być typo­we fak­ty, np. Samochód miał koli­zje w Mieście, gdzie Samochód i Miasto to węzły, a koli­zja to zda­rze­nie. Ważne jest to, że Samochód i Miasto moż­na opi­sać okre­ślo­nym cech, sama koli­zje tak­że, waż­ne jest to, że fak­tów łączą­cych dwa obiek­ty może być wie­le (w czasie). 

Związki mię­dzy obiek­ta­mi opi­sy­wa­ne są też meto­dą RDF (Resource Description Framework) jako zda­nia: Subject – Predicate – Object .

O każ­dym obiek­cie będzie jeden rekord w bazie danych, o każ­dym fak­cie też, ale róż­nych fak­tów, któ­rych cecha­mi są te obiek­ty może być wie­le (cechą stłucz­ki jest mię­dzy inny­mi miej­sce stłucz­ki i samo­chód, któ­ry miał tę stłucz­kę). Cechami obiek­tów są nazwa, data powsta­nia i ewen­tu­al­na data usu­nię­cia (znisz­cze­nia), tak­że cechy defi­niu­ją­ce takie jak np. kolor, typ czy wyda­wa­ne dźwię­ki. Cechami fak­ty są czas zaist­nie­nia oraz obiek­ty (ich nazwy), któ­rych okre­ślo­ny fakt doty­czy. Ważne jest to, że poło­że­nie obiek­tu nie jest jego cechą defi­niu­ją­cą. Graf jest defi­nio­wa­ny jako nazwa­ne związ­ki mię­dzy obiek­ta­mi, są nimi wła­śnie fak­ty (a sze­rzej: pre­dy­ka­ty). Warto też zazna­czyć, że w kon­tek­ście np. zda­rzeń gospo­dar­czych, fak­tem jest fak­tu­ra opi­su­ją­ca trans­ak­cje do jakiej doszło. Jednak w archi­wum doku­men­tów fak­tu­ra jest obiek­tem archi­wal­nym .

Tak więc bar­dziej sfor­ma­li­zo­wa­na struk­tu­ra danych w bazie gra­fo­wej mogła by wyglą­dać tak:

Struktura infor­ma­cyj­na gra­fo­wej bazy danych: obiek­ty (nie­bie­skie) i związ­ki (żół­te) (opra­co­wa­nie wła­sne autora)

Diagram powyż­szy jest kolo­ro­wa­ny dla popra­wy czy­tel­no­ści. W tej posta­ci widać obiek­ty i łączą­ce je fak­ty: w bazach gra­fo­wych są to for­mal­nie tak zwa­ne związ­ki seman­tycz­ne (zna­cze­nio­we), ale jest to jed­nak duże uprosz­cze­nie. Systemy zapi­su infor­ma­cji w posta­ci tró­jek: poję­cie-pre­dy­kat-poję­cie mają szer­sze uza­sad­nie­nie (pla­nu­ję publi­ka­cję z wyni­ka­mi szer­szych badań). Metamodel sys­te­mu zapi­su infor­ma­cji o obiek­tach i związ­kach mię­dzy nimi wyglą­da tak:

Metamodel gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora) 

Warto zauwa­żyć, że zarów­no Obiekt jak i Związek seman­tycz­ny mogą być prze­cho­wy­wa­ne w bazie doku­men­to­wej lub kolumnowej…

Podsumowanie

To co dzi­siaj nazy­wa­my baza­mi danych NoSQL to tyl­ko natu­ral­ne mode­le infor­ma­cyj­ne. Kiedy odkry­te? Nie wiem, ale wiem, że w tym wszyst­kim naj­bar­dziej nie­na­tu­ral­ny jest model rela­cyj­ny. Dlaczego? Bo nie wystę­pu­je w natu­rze i spra­wia same pro­ble­my. Celowo zapre­zen­to­wa­łem sfor­ma­li­zo­wa­ne dia­gra­my UML dla każ­de­go typu, by poka­zać, że NoSQL to tyl­ko i aż mode­le infor­ma­cyj­ne spo­ty­ka­ne w rze­czy­wi­sto­ści życia czło­wie­ka. Konstrukcje jak te wyżej opi­sa­ne, to tak na praw­dę mode­le infor­ma­cji wyni­ka­ją­ce z dzie­dzi­ny pro­ble­mu, nie jest tak że są uży­wa­ne z powo­du wyna­le­zie­nia” baz NoSQL, jest dokład­nie odwrotnie. 

Obecne bazy NoSQL rozu­mia­ne jako moto­ry baz danych”, to imple­men­ta­cje infor­ma­cyj­nych wzor­ców pro­jek­to­wych. Diagramy UML powy­żej to meta­mo­de­le tych wzorców. 

Na temat baz danych i baz NoSQL pole­cam kom­plek­so­we opra­co­wa­nie Joe Celko: Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses .

Podsumowanie 2

Pojawiają się tezy że to się nie nada­je do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budo­wa­ne w opar­ciu o cen­tral­ne bazy danych RDBMS ewo­lu­ują­ce do chmu­ry są nie­ja­ko ska­za­ne na bazy NoSQL (zna­ko­mi­ta więk­szość chmu­ro­wych repo­zy­to­riów chmu­ro­wych to bazy NoSQL).

Ewolucja Architektury tak zwa­nych stan­dar­do­wych ERP 

Podstawowym pro­ble­mem sys­te­mów zbu­do­wa­nych w opar­ciu o bazy RDBMS/SQL jest to, że nie ma w nich doku­men­tów, a jedy­nie dane roz­ło­żo­ne w tabe­lach. Uzyskanie doku­men­tu (np. fak­tu­ry) wyma­ga każ­do­ra­zo­wo dyna­micz­ne­go zebra­nia danych z wie­lu tabel, ich złą­cze­nia i sfor­ma­to­wa­nia, czy­li uży­cia języ­ka SQL. Dlatego ewo­lu­cja nowo­cze­snych sys­te­mów ERP idzie w kie­run­ku sys­te­mów, w któ­rych funk­cje kal­ku­la­cyj­ne oraz doku­men­ty są roz­dzie­lo­ne, a doku­men­ty są prze­cho­wy­wa­ne w posta­ci zmaterializowanej: 

Zarządzanie doku­men­ta­mi w sys­te­mach ERP 

Podsumowanie 3

Od dłuż­sze­go cza­su sto­su­je w pro­jek­tach struk­tu­ry infor­ma­cyj­ne nazy­wa­ne NoSQL. Sa to prak­tycz­nie wszyst­kie opi­sa­ne wyżej struk­tu­ry. Projekt dla agen­cji foto­gra­ficz­nej BE&W (archi­wum zdjęć), pro­jekt dla Biura Polonii Kancelarii Senatu (obsłu­ga wnio­sków o dofi­nan­so­wa­nie o zmien­nej struk­tu­rze), pro­jekt dla Żandarmerii Wojskowej (zarzą­dza­nie spra­wa­mi docho­dze­nio­wo-śled­czy­mi w całej Polsce), pro­jekt dla KGHM (stan­da­ry­za­cja sys­te­mu utrzy­ma­nia ruchu, zarzą­dza­nie infra­struk­tu­rą produkcyjną).

Więcej już nie­dłu­go… Zachęcam do zada­wa­nia pytań o NoSQL pod tym wpisem. 

Źródła

Bouhali, R., & Laurent, A. (2015). Exploiting RDF Open Data Using NoSQL Graph Databases. In R. Chbeir, Y. Manolopoulos, I. Maglogiannis, & R. Alhajj (Eds.), Artificial Intelligence Applications and Innovations (Vol. 458, pp. 177 – 190). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 23868-5_13
Besta, M., Peter, E., Gerstenberger, R., Fischer, M., Podstawski, M., Barthels, C., Alonso, G., & Hoefler, T. (2020). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ArXiv:1910.09017 [Cs]. http://​arxiv​.org/​a​b​s​/​1​9​1​0​.​0​9​017
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902

Sami zbudujemy oprogramowanie…

Swego cza­su wpadł mi oczy nius”:

Tesla Motors CEO Elon Musk deci­ded that the com­pa­ny would build its own busi­ness softwa­re to run the com­pa­ny. CIO Jay Vijayan and his team built it in just four mon­ths. (How Tesla’s Elon Musk Approaches IT – The CIO Report – WSJ).

Nie znam szcze­gó­łów, ale domy­ślam się, że zre­zy­gno­wa­li z peł­ne­go zin­te­gro­wa­ne­go pakie­tu ERP” i to chy­ba z tego krót­kie­go tek­stu widać.

marzenia i realiaOd dłuż­sze­go cza­su nur­tu­je mnie czym kie­ru­ją się fir­my (ludzie) zawie­ra­ją­ce umo­wy na zakup peł­nych i zin­te­gro­wa­nych pakie­tów ERP mimo, że sta­ty­sty­ki poka­zu­ją, że to z regu­ły nie ma żad­ne­go sen­su. Praktycznie wszyst­kie te wdro­że­nia są po zakoń­cze­niu znacz­nie droż­sze niż pier­wot­ne ofer­ty, trwa­ją dłu­żej niż obie­ca­no, nie mała część koń­czy się fia­skiem i nawet kom­plet­ną rezy­gna­cją i odin­sta­lo­wa­niem (bywam w tych fir­mach i widzę od środ­ka róż­ni­cę pomię­dzy tym co piszą w gaze­tach dostaw­cy w swo­ich refe­ren­cjach a tym co fak­tycz­nie mia­ło miejsce).

Nie raz o tym tu pisa­łem więc nie będę się powta­rzał. Popatrzmy na poniż­sze statystyki:

W Polsce śred­ni koszt wdro­że­nia pro­jek­tu na kil­ka­dzie­siąt sta­no­wisk (40 – 80 licen­cji) wyno­si 200 – 300 tys. dola­rów (pra­wie milion zło­tych), a pro­jek­tu dla małej fir­my (20 – 30 licen­cji) 100 – 140 tys. dola­rów (nie­co ponad 400 tys. zł) . Proporcje pomię­dzy kosz­ta­mi sprzę­tu i opro­gra­mo­wa­nia utrzy­mu­ją się na pozio­mie pół na pół. Najdroższe są usłu­gi kon­sul­tin­go­we, ich koszt się­ga 50 proc. kosz­tów wdro­że­nia, choć zda­rza­ją się klien­ci, u któ­rych kosz­ty obsłu­gi przez kon­sul­tan­tów nie prze­kra­cza­ją 5 proc. Wówczas klient prak­tycz­nie doko­nu­je wdro­że­nia wła­sny­mi siła­mi, ze stro­ny dostaw­cy korzy­sta­jąc głów­nie z usług szko­le­nio­wych. (Zintegrowane wspo­ma­ga­nie zarzą­dza­nia przed­się­bior­stwem: Przyszłość sys­te­mów ERP – Bankier​.pl).

Tu mamy koszt ok. 400 tys. zł, czy­li jakieś 200 tys. na ana­li­zę, pro­jek­to­wa­nie i wyko­na­nie, to jest moż­li­we i nie jest to mało. Ostatni taki pro­jekt jaki mam w port­fo­lio trwał tyl­ko pół roku. Różnica jest taka, że za te pie­nią­dze klient nie robił prak­tycz­nie żad­nych kom­pro­mi­sów (kom­pro­mis kasto­mi­za­cji przy wdra­ża­niu goto­wych dużych pakie­tów), czas od roz­po­czę­cia do wdro­że­nia tyl­ko pół roku! To przy­kład takie­go same­go budże­tu ale pro­jekt nie był trywialny.

Swego cza­su robi­łem wyli­cze­nie pro­go­wych kosz­tów opła­cal­no­ści wytwo­rze­nia dedy­ko­wa­nej apli­ka­cji dzie­dzi­no­wej i wyszło mi, że za 75 tys. (podob­no poza Warszawą 50 tys.) już taka może powstać (przy zało­że­niu rze­tel­ne­go pro­jek­to­wa­nia a potem dopie­ro imple­men­ta­cji, wte­dy wycho­dzi za pierw­szym razem, mam takie w port­fo­lio). Przy obec­nej tech­no­lo­gii (fra­me­wor­ki dzie­dzi­no­we czy­li tak zwa­ne goto­we szkie­le­ty) od daw­na już nie pisze­my dłu­go i żmud­nie kosz­tow­ne­go opro­gra­mo­wa­nia od zera” (czym stra­szą dostaw­cy goto­we­go). Dedykowany pro­jekt do dobór wła­ści­wych ele­men­tów szkie­le­tu, ich kon­fi­gu­ra­cja, roz­wią­zy­wa­nie wie­lu pro­ble­mów poza funk­cjo­nal­nych (tech­nicz­nych), pra­ce pro­gra­mi­stycz­ne wykoń­cze­nio­we” i ser­ce sys­te­mu czy­li model jego dzie­dzi­ny (ok. 3% cało­ści kodu), któ­ry fak­tycz­nie powsta­je od zera”. Do tego docho­dzi coraz więk­sza otwar­tość na inte­gra­cję goto­we­go, dostęp­ne­go na ryn­ku opro­gra­mo­wa­nia reali­zu­ją­ce­go stan­dar­do­we usłu­gi, takie jak zarzą­dza­nie finan­sa­mi czy maga­zy­na­mi. To się kupu­je goto­we i łączy.

Piszę to na począt­ku roku, trak­tu­jąc jako wróż­bę, to okres na pro­gno­zy więc i ja pro­gno­zu­ję :). Myślę, że postę­py w inży­nie­rii opro­gra­mo­wa­nia, powol­ne odcho­dze­nie od mode­lu rela­cyj­ne­go danych (to wymu­sza bar­dzo sztyw­ną inte­gra­cję) i kolej­ne pro­jek­ty poka­zu­ją­ce, że zin­te­gro­wa­ny ERP to nie koniecz­nie mono­li­tycz­ny” ERP, dopro­wa­dzą do upad­ku” hege­mo­nii wiel­kich dostaw­ców ERP”. Okazuje sie, że moż­na taniej uzy­skać takie same, a nie raz lep­sze, efek­ty. Są już pierw­sze efek­ty: dostaw­cy dużych ERP ofe­ru­ją dość roz­bu­do­wa­ne i wygod­ne inter­fej­sy inte­gra­cyj­ne, sami zawie­ra­ją soju­sze z dostaw­ca­mi osob­nych kom­po­nen­tów (lub ich kupu­ją :)). Osobiście nie widzę sen­su, by każ­da zmia­na sytu­acji biz­ne­so­wej musia­ła wyma­gać wymia­ny lub mody­fi­ka­cji całe­go pakie­tu ERP, sko­ro moż­na poje­dyn­cze komponenty.

Biznes wychodzi z objęć systemu … monolitycznego ERP

Koniec roku się zbli­ża, czas na pod­su­mo­wa­nia i pro­gno­zy :), pierw­sze publi­ka­cje już są. Co się pisze o ERP:

Monolityczne roz­wią­za­nia wspie­ra­ją­ce zarzą­dza­nie to prze­szłość. Dziś liczą się: wszech­stron­ność, otwar­tość na zmia­ny, pro­sto­ta obsłu­gi, moż­li­wo­ści inte­gra­cyj­ne. Wybór naj­lep­sze­go sys­te­mu ERP sta­je się coraz trud­niej­szy. (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jak osią­gnąć wszech­stron­ność i otwar­tość na zmia­ny”? Na począ­tek może małe review moich wcze­śniej­szych tek­stów na ten temat:

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. […] Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić” koszt wspar­cia poje­dyn­cze­go pro­ce­su. (Marzec 2007, Czy to już nad­cho­dzą­cy koniec zin­te­gro­wa­nych ERP?)

Jeżeli dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Listopad 2009 Nigdy wię­cej ERP w jed­nym kawał­ku!).

Jak zacząć? Najpierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym i pozo­sta­łe, któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas. te dru­gie obsłuż­my po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrot­ne­go. (sier­pień 2010, Wymagania na opro­gra­mo­wa­nie ERP wspo­ma­ga­ją­ce zarzą­dza­nie: dwie kup­ki).

Nowe sys­te­my zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­ła nie na współ­dzie­le­niu danych, a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już ist­nie­ją­cych. (Styczeń 2011, Frameworks Introduction ? czy­li jak się psu­je dobre ERP).1

Bo nie­za­leż­nie od tego jak ?uni­wer­sal­ny? jest sys­tem ERP zawsze będzie gor­szy od kil­ku dobrze dobra­nych ale nie­za­leż­nych kom­po­nen­tów. Gorszy nie dla­te­go, że ?brzyd­szy? ale dla­te­go, że będzie kulą u nogi fir­my, któ­ra powin­na jed­nak reago­wać na zmia­ny na ryn­ku w cią­gu tygo­dni a nie lat? Po dru­gie mody­fi­ka­cja jakie­go­kol­wiek opro­gra­mo­wa­nia zawsze wyma­ga testo­wa­nia cało­ści, tak więc im mniej­sze kawał­ki mamy tym szyb­ciej i taniej wpro­wa­dza się do nich zmia­ny bo ich odda­nie do użyt­ku po mody­fi­ka­cji jest łatwiej­sze i szyb­sze zara­zem. Pamiętajmy pew­ną sta­rą rekla­mę: ?Banki od wszyst­kie­go są do nicze­go??. (Kwiecień 2011, Czego naj­bar­dziej bra­ku­je sys­te­mom kla­sy ERP?).

Od lat mówi się o SOA, jako o meto­dzie budo­wy i inte­gra­cji sys­te­mów (tu już mamy inte­gra­cję a nie tyl­ko zdal­ne uży­cie). Jednak poja­wia się tu potrze­ba two­rze­nia pośred­ni­czą­ce­go, kosz­tow­ne­go, ele­men­tu archi­tek­tu­ry (ESB) co sku­tecz­nie ogra­ni­czy­ło zasto­so­wa­nie tej meto­dy (a raczej tech­no­lo­gii) inte­gra­cji sys­te­mów. Cloud Computing to zupeł­nie inne podej­ście. To kom­po­nen­to­wa archi­tek­tu­ra zna­na od lat. (Październik 2011, Cloud Computing to archi­tek­tu­ra sys­te­mu).2

Pojawia się teza:

ERP jest dziś narzę­dziem do gro­ma­dze­nia i skła­do­wa­nia wszel­kich infor­ma­cji potrzeb­nych do podej­mo­wa­nia decy­zji w biz­ne­sie. Jako takie jest dziś waż­niej­sze niż kie­dy­kol­wiek wcze­śniej” – pod­kre­śla Nidal Haddad.3 (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jeżeli fak­tycz­nie tak dostaw­cy postrze­ga­ją sys­te­my ERP (co zresz­tą wyda­je się być wła­ści­we) to nie dzi­wi fakt, że np. zarzą­dza­nie doku­men­ta­mi, wspo­ma­ga­nie prze­pły­wu pra­cy (work­flow) czy wspo­ma­ga­nie podej­mo­wa­nia decy­zji (sys­te­my rapor­to­we, busi­ness inte­li­gen­ce) to coraz czę­ściej jed­nak odręb­ne, inte­gro­wa­ne pod­sys­te­my. Widać ten trend już na ryn­ku. Np. jeden z lide­rów ryn­ku ERP, fir­ma SAP, kupił pro­dukt (fir­mę) Business Object włą­cza­jąc go do swo­jej ofer­ty jako narzę­dzie BI,4 do zarzą­dza­nia doku­men­ta­mi i ich prze­pły­wem SAP pole­ca dedy­ko­wa­ny do tego celu sys­tem OpenText. 5SAP nie jest tu jedy­nym dostaw­cą ERP. Podobną stra­te­gię zaczy­na­ją pre­zen­to­wać i inni lide­rzy ryn­ku ERP. Tak więc już nie jeden ERP II… O czym to świad­czy? O roz­pa­dzie” idei sys­te­mu zintegrowanego:

Uniwersalność opro­gra­mo­wa­nia wspie­ra­ją­ce­go zarzą­dza­nie powo­du­je, że zacie­ra­ją się histo­rycz­ne podzia­ły bran­żo­we. Wcześniej myśla­no o sys­te­mach kla­sy ERP jako o narzę­dziach dają­cych prze­wa­gę kon­ku­ren­cyj­ną. Dzisiaj roz­wią­za­nia tego typu sta­ły się bar­dziej powszech­ne. Standaryzacja poprzez ERP nie daje prze­wa­gi nad kon­ku­ren­cją” – pod­kre­śla Tomasz Bejm, Technology Consulting Leader w fir­mie PrcewaterhouseCoopers.3.

I jak widać nie ja jeden tak uwa­żam, powie­la­nie roz­wią­zań nie daje prze­wa­gi a wręcz ją zabi­ja. wspo­mi­na­łem o tym już w 2007 roku (cytat na począt­ku tekstu).

Pora na Cloud Computing:

Analitycy są zgod­ni, że szcze­gól­ną rolę w zakre­sie roz­wo­ju opro­gra­mo­wa­nia biz­ne­so­we­go odgry­wać będzie tech­no­lo­gia Cloud Computing. W mia­rę roz­wo­ju tech­no­lo­gii inter­ne­to­wych spo­dzie­wać się moż­na wzro­stu uży­tecz­no­ści opro­gra­mo­wa­nia biz­ne­so­we­go ofe­ro­wa­ne­go w mode­lu usłu­go­wym.3 .

Jednak tu nale­ży się pew­ne wyja­śnie­nie. Cloud Computing (CC) to nie zwy­kły out­so­ur­cing opro­gra­mo­wa­nia w posta­ci zna­nej od ponad 10 lat jako ASP czy ostat­nie SaaS (oso­bi­ście nie widzę róż­ni­cy poza tech­no­lo­gią). CC to roz­bu­do­wa­ne, ofe­ro­wa­ne na ryn­ku, goto­we do uży­cia kom­po­nen­ty. Moim zda­niem poda­wa­nie jako przy­kła­du CC roz­wią­zań, któ­rych uży­wa się jak innych apli­ka­cji jest błę­dem. CC to coś do posze­rza moż­li­wo­ści posia­da­ne­go opro­gra­mo­wa­nia ale w tle:

Moim zda­niem każ­dy, chcą­cy liczyć się na ryn­ku dostaw­ca ERP, w zasa­dzie musi się z tym pogo­dzić lub wypad­nie z ryn­ku. Najpierw rynek zmu­sił dostaw­ców ERP do udo­stęp­nia­nie inter­fej­sów inte­gra­cyj­nych, tak zwa­nych API (ang. appli­ca­tion pro­gam­ming inter­fejs) , choć nadal są opor­tu­ni­ści wśród dostaw­ców tych sys­te­mów. Teraz pora pogo­dzić się z tym, że powsta­ją (będą) kom­po­nen­ty roz­sze­rza­ją­ce funk­cjo­nal­no­ści pod­sta­wo­wych wer­sji ERP a koszt udo­stęp­nie­nia API (licen­cjo­no­wa­nie) będzie spa­dał. Możliwości udo­stęp­nia­ne przez te API od pew­ne­go cza­su pozwa­la­ją już na budo­wa­nie ?chmur?6.

Podsumowanie

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go super sys­te­mu” ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci goto­wej” tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nazwę je zapóź­nio­ne”, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne [[API, Application Programming Interface]]) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing). Przyszłość to komponenty…

(J.Ż. 2011)

Rok 2018

Polskie fir­my odcho­dzą od wdra­ża­nia sys­te­mów mono­li­tycz­nych. W cza­sach cyfro­wej trans­for­ma­cji i dyna­micz­nych zmian na ryn­ku trwa­ją­ce ponad rok wdro­że­nia mono­li­tycz­nych sys­te­mów ERP nie zapew­nia­ją dosta­tecz­nej ela­stycz­no­ści. Długotrwałe, czę­sto kasto­mi­zo­wa­ne roz­wią­za­nia prak­tycz­nie unie­moż­li­wia­ją wpro­wa­dza­nie nowych funk­cji czy zmia­nę logi­ki sys­te­mu w trak­cie wdro­że­nia. Oznacza to duże ryzy­ko utra­ty jego zasad­no­ści przed zakoń­cze­niem prac, a jesz­cze więk­sze, zanim zaku­pio­ny sprzęt czy licen­cje zosta­ną zamor­ty­zo­wa­ne. Monolityczne sys­te­my wią­żą przed­się­bior­stwo z okre­ślo­nym dostaw­cą, co w śred­niej i dłu­giej per­spek­ty­wie cza­so­wej utrud­nia wpro­wa­dza­nie zmian i zwięk­sza kosz­ty. 7

Przypisy

1.
Frameworks… IT​-Consulting​.pl. https://it-consulting.pl//index.php/2011/02/03/frameworks-introduction-czyli-jak-sie-psuje-dobre-erp/. Published April 17, 2018. Accessed April 17, 2018.
2.
Cloud Computing. IT-Consulting. https://it-consulting.pl//index.php/2011/10/11/cloud-computing-to-architektura-systemu/. Published April 17, 2018. Accessed April 17, 2018.
4.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
5.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
6.
Zelinski J. Cloud com­pu­ting – czy aby na pew­no nowin­ka… | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//index.php/2010/11/25/cloud-computing-czy-aby-na-pewno-nowinka/. Published November 25, 2010. Accessed April 17, 2018.

Cloud Computing to architektura systemu

Wczoraj mia­ła miej­sce, zapo­wia­da­na na blo­gu, kon­fe­ren­cja na temat Cloud Computing (CC). Nie będę tu powta­rzał całe­go refe­ra­tu, więc zyska­li Ci któ­rzy byli na kon­fe­ren­cji :). Tu napi­sze kil­ka słów o CC w kon­tek­ście tego co było głów­nym prze­sła­niem moje­go referatu:

Cloud Computing to prak­ty­ka reali­za­cji kom­po­nen­to­wej archi­tek­tu­ry sys­te­mu a nie kolej­na odsło­na dzier­ża­wy oprogramowania

O CC czę­sto mówi się jako o cudzych apli­ka­cjach dostęp­nych w sie­ci. Mówi się o Saleforce, Zoho i innych podob­nych, ale to są sys­te­my dostęp­ne zdal­nie i licen­cjo­no­wa­ne (nie ma tu zna­cze­nia to, czy licen­cje są płat­ne czy nie). To jest sta­re i zna­ne [[ASP]] czy [[SaaS]].

Od lat mówi się o SOA, jako o meto­dzie budo­wy i inte­gra­cji sys­te­mów (tu już mamy inte­gra­cję a nie tyl­ko zdal­ne uży­cie). Jednak poja­wia się tu potrze­ba two­rze­nia pośred­ni­czą­ce­go, kosz­tow­ne­go, ele­men­tu archi­tek­tu­ry ([[ESB]]) co sku­tecz­nie ogra­ni­czy­ło zasto­so­wa­nie tej meto­dy (a raczej tech­no­lo­gii) inte­gra­cji sys­te­mów. Czytaj dalej… Cloud Computing to archi­tek­tu­ra sys­te­mu”

Dostosowanie oprogramowania: kiedy?

Problem dosto­so­wy­wa­nia (tak zwa­nej kasto­mi­za­cji) goto­we­go opro­gra­mo­wa­nia nie od dziś jest dys­ku­to­wa­ny. Jak wspo­mnia­łem w arty­ku­le o psu­ciu sys­te­mów ERP, fir­my wdra­ża­ją­ce naj­czę­ściej pre­fe­ru­ją dosto­so­wy­wa­nie (tak zwa­na [[kasto­mi­za­cja]]), pro­du­cen­ci tego opro­gra­mo­wa­nia dla odmia­ny, odra­dza­ją tę ścież­kę. Popatrzmy co na to Martin Fowler, zna­ny w bran­ży IT doświad­czo­ny pro­jek­tant i deve­lo­per, czło­wiek zna­ny z tego że napi­sał napraw­dę dużo biz­ne­so­we­go kodu:

A com­mon question in IT depart­ments is whe­ther to pro­vi­de a capa­bi­li­ty by buil­ding custom softwa­re or by buy­ing a pac­ka­ge. For lon­ger than I’ve been pro­gram­ming the deba­te has raged abo­ut how to make that cho­ice. My base posi­tion on this is foun­ded on the UtilityVsStrategicDichotomy. Boiled down this means that if the busi­ness pro­cess you are sup­por­ting is part of your com­pe­ti­ti­ve advan­ta­ge you sho­uld build custom softwa­re, if not you sho­uld buy a pac­ka­ge and adjust your busi­ness pro­cess to fit the way the pac­ka­ge works. (źr. PackageCustomization).

Fowler pyta o to, o co wie­lu wie­lu infor­ma­ty­ków: czy dostar­cze­nie fir­mie kolej­nych nowych moż­li­wo­ści, powin­no się reali­zo­wać poprzez napi­sa­nie (two­rząc dedy­ko­wa­ne) potrzeb­ne nowe opro­gra­mo­wa­nie, czy poprzez zakup goto­we­go opro­gra­mo­wa­nia. Ogólnie opi­nia, zale­ca­ne podej­ście przez Fowlera to: jeże­li pro­ces wyma­ga­ją­cy wspar­cia nowym opro­gra­mo­wa­niem, to pro­ces klu­czo­wy dla utrzy­ma­nia kon­ku­ren­cyj­no­ści lepiej stwo­rzyć opro­gra­mo­wa­nie dedy­ko­wa­ne do tego pro­ce­su. Jeżeli to jeden z pro­ce­sów pomoc­ni­czych, efek­tyw­niej będzie kupić goto­we opro­gra­mo­wa­nie i dosto­so­wa­nie do nie­go pro­ce­su w fir­mie. Co cie­ka­we, podob­nie jak ja, zale­ca w przy­pad­ku goto­we­go opro­gra­mo­wa­nia dosto­so­wa­nie się do nie­go a nie dosto­so­wy­wa­nie opro­gra­mo­wa­nia do siebie.

Z mojej stro­ny dodam, że to kolej­na opi­nia bar­dzo doświad­czo­nej oso­by, z któ­rej wyni­ka, że sys­tem ERP raczej nale­ży trak­to­wać jako fede­ra­cję zin­te­gro­wa­nych pro­gra­mów dzie­dzi­no­wych, a nie jako jeden zin­te­gro­wa­ny pakiet opro­gra­mo­wa­nia. Ten ostat­ni zawsze w jakimś obsza­rze będzie kula u nogi.