Temat clo­ud com­pu­ting jest coraz goręt­szy. Z jed­nej stro­ny pod­grze­wa­ją atmos­fe­rę fir­my ofe­ru­ją­ce róż­ne for­my dzier­ża­wy zaso­bów a z dru­giej tech­no­lo­gie i archi­tek­tu­ry zwa­ne ​„chmu­ro­wy­mi”, pro­wa­dzą do sta­le male­ją­cych kosz­tów inte­gra­cji (chmu­ra prywatna).

Tak zwa­ne tech­no­lo­gie webo­we (np. RESTful/REST API itp.) doty­czą­ce inte­gra­cji, powsta­ły co praw­da już nawet w 2000 roku, jed­nak dopie­ro teraz moż­na mówić o dostęp­nych, prze­te­sto­wa­nych biblio­te­kach, czy­nią­cych tego rodza­ju pro­jek­ty tań­szy­mi, np. oma­wia­ne w arty­ku­le ​„Wymagania poza­funk­cjo­nal­ne ? inte­gra­cja” inte­gra­cja z pomo­cą API to dzi­siaj już taki sam koszt jak ​„spa­wa­nie” z pomo­cą SQL, wystar­czy, że zatrud­ni­my kogoś (fir­mę) kto potra­fi, a nie kogoś kto za nasze pie­nią­dze będzie się dopie­ro zwin­nie uczył, skła­da­jąc ofer­tę mimo bra­ku kom­pe­ten­cji. Opór wie­lu firm przed przed tymi roz­wią­za­nia­mi, z moje­go doświad­cze­nia, wyni­ka z: bra­ku wie­dzy i kom­pe­ten­cji (wie­le zna­nych firm IT nadal ope­ru­je meto­da­mi i tech­no­lo­gia­mi z przed nawet 30 lat!), kur­czo­we­go trzy­ma­nia się mode­lu biz­ne­so­we­go ​„dostar­cza­my jeden mono­li­tycz­ny sys­tem”, któ­ry sil­nie uza­leż­nia klien­ta od dostawcy.

No i sto­so­wa­nie metod opar­tych o tak zwa­ne usłu­gi ​„webse­rvis”, wyma­ga cał­ko­wi­te­go odej­ścia od metod struk­tu­ral­nych pro­jek­to­wa­nia (jed­no­li­te bazy danych w mode­lu rela­cyj­nym i ster­ta funk­cji) na rzecz metod obiek­to­wych i kom­po­nen­to­wych (Large sys­tem archi­tec­tu­re).

Znamienne jest to, że gdy np. prze­szu­ka­my Internet pod kątem SOA, zoba­czy­my, iż w ostat­nich kil­ku latach spo­ro publi­ka­cji poświę­co­no odej­ściu od tra­dy­cyj­ne­go spo­so­bu roz­wo­ju sys­te­mów infor­ma­tycz­nych ? od roz­bu­do­wa­nych roz­wią­zań auto­no­micz­nych do struk­tur zło­żo­nych z róż­ne­go rodza­ju roz­pro­szo­nych usług, ukie­run­ko­wa­nych na obsłu­gę wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań. Równolegle, za Oceanem dyna­micz­nie roz­wi­ja się Cloud Computing. Czymże innym jest to zja­wi­sko, jak nie moż­li­wo­ścią dobie­ra­nia do orga­ni­za­cji (infra­struk­tu­ry IT i mode­lu biz­ne­so­we­go) usług, któ­re są nie­zbęd­ne do efek­tyw­niej­szej pra­cy (?do obsłu­gi wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań?). I tak jak w ostat­nich latach szy­ny inte­gra­cyj­ne słu­ży­ły inte­gro­wa­niu wewnętrz­nej infra­struk­tu­ry IT, tak w naj­bliż­szej przy­szło­ści będą się roz­wi­jać do łącze­nia rów­nież zewnętrz­nych usług z Chmury. (INTEGRACJA ROZWIĄZAŃ Z CHMURY TO WYZWANIE?).

Ja pisa­łem o tym już w 2011 roku (Biznes wycho­dzi .…).

Osobiście nie demo­ni­zo­wał bym koniecz­no­ści posia­da­nia ​„szy­ny inte­gra­cyj­nej”, jak auto­rzy cyto­wa­ne­go powy­żej arty­ku­łu (fir­ma TIBCO jest dostaw­cą takie­go pro­duk­tu), jed­nak trend w kie­run­ku rezy­gna­cji z mono­li­tycz­nych apli­ka­cji już się zazna­cza, a to czy taka ​„szy­na” będzie, raczej jest kon­se­kwen­cją archi­tek­tu­ry. Dobrze zapro­jek­to­wa­na archi­tek­tu­ra całe­go sys­te­mu apli­ka­cji (kom­po­nen­tów) to struk­tu­ra hie­rar­chicz­na: tak zwa­ny ​„front end” to apli­ka­cje, któ­rych odpo­wie­dzial­no­ścią jest zarzą­dza­nie pro­ce­sa­mi, prze­pły­wem pra­cy (wpro­wa­dza­nie danych i korzy­sta­nie z nich). Głębiej są dzie­dzi­no­we apli­ka­cje sta­no­wią­ce refe­ren­cyj­ne skła­dy i źró­dła danych. W takiej archi­tek­tu­rze komu­ni­ka­cja (wywo­ła­nia) jest jed­no­stron­na (zawsze mamy jasny podział usłu­go­bior­ca-usłu­go­daw­ca. Szyny inte­gra­cyj­nej, jako dodat­ko­we­go kom­po­nen­tu, wyma­ga­ją skom­pli­ko­wa­ne sys­te­my i raczej doty­czy to więk­szych kor­po­ra­cji, fir­my nasze­go sek­to­ra MSP rzad­ko kiedy.

Internetowe meto­dy inte­gra­cji (np. wspo­mnia­ny REST) to wymia­na pole­ceń i obiek­tów a nie ​„funk­cja vs. baza danych” (patrz wspo­mnia­ny arty­kuł o inte­gra­cji, dzi­wią mnie deve­lo­pe­rzy narze­ka­ją­cy np. na ​„skom­pli­ko­wa­ne mapo­wa­nie obiek­to­wo-rela­cyj­ne”, bo ono nie ma pra­wa być skom­pli­ko­wa­ne, a jeże­li jest, to jest to pierw­szy sygnał, że to zły projekt!).

Tak więc chmu­ry owszem, to chy­ba przy­szłość, bez wni­ka­nia w to czy to chmu­ry publicz­ne czy pry­wat­ne. Autonomiczne, duże sys­te­my ERP? Nie wró­żę im karie­ry, w obec­nej posta­ci mega-apli­ka­cje umrą, odwle­ka­nie tej śmier­ci z pomo­cą per­swa­zyj­nych reklam i kam­pa­nii dużych kor­po­ra­cji i ich sprze­daw­ców, to tyl­ko sztucz­ne prze­dłu­ża­nie życia inwe­sty­cji w duże ERP, przez pro­du­cen­tów tych roz­wią­zań, dawa­nie sobie cza­su na (mam nadzie­ję) ich refak­to­ring. Mamy np. takie kolo­sy jak Google czy Amazon, któ­re poka­zu­ją, że chmu­ro­we, wyso­ce ska­lo­wal­ne archi­tek­tu­ry zaso­bo­we mają sens. Systemy ERP opar­te na rela­cyj­nych bazach danych i ich wewnętrz­na inte­gra­cja poprzez współ­dzie­le­nie danych, nie mają nawet szan­sy z tego skorzystać.

Jarosław Żeliński

BIO: Od roku 1991 roku, nie­prze­rwa­nie, reali­zu­ję pro­jek­ty z zakre­su ana­liz i pro­jek­to­wa­nia sys­te­mów, dla urzę­dów, firm i orga­ni­za­cji. Od 1998 roku pro­wa­dzę tak­że samo­dziel­ne stu­dia i pra­ce badaw­cze z obsza­ru ana­li­zy sys­te­mo­wej i mode­lo­wa­nia (mode­le jako przed­miot badań: ORCID). Od 2005 roku, jako nie­eta­to­wy wykła­dow­ca aka­de­mic­ki, pro­wa­dzę wykła­dy i labo­ra­to­ria (onto­lo­gie i mode­lo­wa­nie sys­te­mów infor­ma­cyj­nych, aktu­al­nie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspi­cja­mi Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje bada­nia i publi­ka­cje nie mają finan­so­wa­nia z zewnątrz, jako ich autor dekla­ru­ję brak kon­flik­tu interesów.

it​-con​sul​ting​.pl/​f​i​r​m​a​-​i​t​-​c​o​n​s​u​l​t​i​n​g​-​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​k​i​/​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​ki/