Architekt danych ? czy na pewno zawód przyszłości?

Rola archi­tek­tu­ry danych zna­la­zła tak­że odzwier­cie­dle­nie w zarob­kach archi­tek­tów danych. Diagram 3 przed­sta­wia śred­nie zarob­ki rocz­ne archi­tek­tów róż­nych spe­cjal­no­ści w tysią­cach USD (dla porów­na­nia doda­no tak­że inne spe­cjal­no­ści z obsza­ru IT). Widać wyraź­nie, że archi­tek­ci danych są wśród naj­wy­żej opła­ca­nych spe­cja­li­stów. (źr. Architekt danych ? zawód przyszłości?).

ja obser­wu­je coś obok”, otóż dane są wtór­ne w sto­sun­ku do fak­tów, obec­ne sys­te­my raczej odcho­dzą od jed­no­li­tych współ­dzie­lo­nych baz danych”, i nie dla­te­go, że RDBMS są nie­mod­ne”, a dla­te­go, że same dane pozba­wio­ne kon­tek­stu, są mało war­to­ścio­we (do tego nor­ma­li­za­cja mode­li danych to pro­ces strat­ny), w moich oczach ma war­tość np. fak­tu­ra jako zapis fak­tu do jakiej trans­ak­cji doszło, zaś roz­dzie­le­nie danych z fak­tu­ry na kil­ka tabel, czy­ni każ­dą z nich z osob­na mało war­to­ścio­wą albo i bez­war­to­ścio­wą… To, że archi­tek­tu­ra danych ma dziś naj­niż­szy słu­pek nie koniecz­nie zna­czy, że ktoś to będzie nad­ra­biał (słyn­ne dywa­ga­cje o tym, czy cho­dzą­cy boso miesz­kań­cy Afryki wró­żą mega rynek na obu­wie), war­to pamię­tać o tym, że inte­gra­cja pomię­dzy sys­te­ma­mi coraz czę­ściej odby­wa się na pozio­mie logi­ki biz­ne­so­wej, poprzez wymia­nę obiek­tów opi­su­ją­cych zda­rze­nia i byty rze­czy­wi­ste, a nie poprzez współ­dzie­le­nie (baz) danych, cze­go się zresz­tą nie da robić w sie­ciach roz­pro­szo­nych takich jak chmu­ry… Osobiście wró­żę karie­rę ana­li­ty­kom, potra­fią­cym cało­ścio­wo (holi­stycz­nie ;)) patrzeć na orga­ni­za­cje, rośnie zło­żo­ność orga­ni­za­cji, co w toku ana­liz i mode­lo­wa­nia, zmu­sza do abs­tra­ho­wa­nia od pew­nych szcze­gó­łów, tu wra­ca do łask ana­li­za sys­te­mo­wa … (nie mylić z ana­li­za sys­te­mów IT). Pamiętajmy, że:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. New York: Prentice Hall. 

[2021 – 09-07]

No cóż, mamy już BigData, bazy NoSQL, i ogrom­ne roz­pro­sze­nie danych. pro­gno­zy zda­ją sie potwier­dzać: co opi­sa­łem w arty­ku­le Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

SQL albo NoSQL, oto jest pytanie

Tym razem zno­wu obiek­to­we ana­li­za i pro­jek­to­wa­nie. Na stro­nie SQL albo NoSQL, oto jest pyta­nie poja­wi­ła się cie­ka­wa wypo­wiedź. Jako, że oso­bi­ście idę w kie­run­ku” obiek­to­wych sys­te­mów gdzie dane są indy­wi­du­al­ną cechą obiek­tów a nie super-cen­tral­nym skła­do­wi­skiem pozwo­lę sobie na dywa­ga­cje. Proszę ich nie trak­to­wać jako praw­dę w moim wyda­niu”, jest to raczej moje obec­ne postrze­ga­nie tego zagad­nie­nia. Wypowiedzi auto­ra wska­za­ne­go tek­stu wcięte.

No dobra, korzy­sta­jąc z baz NoSQL zysku­je­my lep­szą ska­lo­wal­ność, brak sztyw­ne­go sche­ma­tu bazy danych, spo­rą ela­stycz­ność, mniej pro­ble­mów z mapo­wa­niem danych w bazie do obiek­tów zde­fi­nio­wa­nych w kodzie i pew­nie jesz­cze kil­ka rze­czy, o któ­rych nie mam poję­cia. Ale poja­wia­ją się ogra­ni­cze­nia. Czasem bar­dzo istot­ne. Po pierw­sze bazy NoSQL nie są rela­cyj­ne. Może i jest to oczy­wi­ste, ale chy­ba nie wszy­scy tak do koń­ca zda­ją sobie spra­wę, co to tak na praw­dę ozna­cza. Całą obsłu­gę rela­cyj­no­ści pomię­dzy dany­mi (jeśli jest nam potrzeb­na) trze­ba emu­lo­wać w kodzie apli­ka­cji, na wbu­do­wa­ne w bazę danych roz­wią­za­nia nie ma co liczyć.

Zarzut, że bazy NoSQL nie są rela­cyj­ne jest dla tych baz raczej kom­ple­men­tem. Kluczowym tu stwier­dze­niem tor­pe­du­ją­cym w moich oczach wywód jest uzna­nie fak­tu, że rela­cyj­ność może nie być potrzeb­na. Owszem, dodam nawet, że nie raz po pro­stu cią­ży. Po dru­gie moim zda­niem błęd­ne jest stwier­dze­nie, że rela­cyj­ność nale­ży emu­lo­wać w kodzie. Otóż nie, bo może być po pro­stu niepotrzebna!.

Po dru­gie czę­sto brak JOINów. […] Potrafi to bar­dzo utrud­nić pisa­nie wydaj­nych zapy­tań, a prze­cież roz­li­cza­ny jestem z każ­dej mili­se­kun­dy pra­cy procesora.

Kolejny moim zda­niem błąd w myśle­niu: dłu­gie, wyma­ga­ją­ce opty­ma­li­za­cji, skom­pli­ko­wa­ne zapy­ta­nia są wła­śnie cechą zapy­tań do baz rela­cyj­nych. Bazy rela­cyj­ne, po doko­na­niu nor­ma­li­za­cji, w zasa­dzie żad­nej infor­ma­cji nie trzy­ma­ją w jed­nym kawał­ku, wszyst­ko wyma­ga poskle­ja­nia przed uży­ciem. Pozyskanie tre­ści zwy­kłej fak­tu­ry z takiej bazy, wyma­ga poskle­ja­nia jej z dzie­sią­tek skła­do­wych tablic i słow­ni­ków, wyma­ga to fak­tycz­nie nie lada sztu­ki w napi­sa­niu zapy­ta­nia do bazy a co dopie­ro taki raport fak­tur sprze­da­ży z poprzed­nich okresów.

Dlaczego o tym piszę? Otóż jed­nym z więk­szych, w moich oczach, pro­ble­mów jest wykształ­ce­nie pro­jek­tan­tów i pro­gra­mi­stów. Nie, nie. Nie twier­dze że jest złe, po pro­tu nadal na wyż­szych uczel­niach na kie­run­kach infor­ma­ty­ki przed­mio­ty takie jak ana­li­za i mode­lo­wa­nie obiek­to­we w rela­cji do kla­sycz­nych zajęć w rodza­ju pro­gra­mo­wa­nie w Pascalu, C++ i mode­lo­wa­nie rela­cyj­nych baz danych to pyłek w pro­gra­mie nauczania.

Troszkę wyjaśnień

Relacyjne bazy danych (RDBMS) to w ogól­nym sen­sie, po ludz­ku, dane upo­rząd­ko­wa­ne w powta­rza­ją­ce się struk­tu­ry trwa­le z sobą powią­za­ne. Jedna z defi­ni­cji spo­ty­ka­nych w sieci:

W naj­prost­szym uję­ciu w mode­lu rela­cyj­nym dane gru­po­wa­ne są w rela­cje, któ­re repre­zen­to­wa­ne są przez tabli­ce. Relacje są pew­nym zbio­rem rekor­dów o iden­tycz­nej struk­tu­rze wewnętrz­nie powią­za­nych za pomo­cą związ­ków zacho­dzą­cych pomię­dzy dany­mi. Relacje zgru­po­wa­ne są w tzw. sche­ma­ty bazy danych. Relacją może być tabe­la zawie­ra­ją­ca dane tele­adre­so­we pra­cow­ni­ków, zaś sche­mat może zawie­rać wszyst­kie dane doty­czą­ce fir­my. Takie podej­ście w porów­na­niu do innych mode­li danych uła­twia wpro­wa­dza­nia zmian, zmniej­sze­nie moż­li­wość pomy­łek, ale dzie­je się to kosz­tem wydaj­no­ści. (źr. http://​pl​.wiki​pe​dia​.org/​w​i​k​i​/​M​o​d​e​l​_​r​e​l​a​c​y​jny)

Jak to wyglą­da w prak­ty­ce. Postaram się to poka­zać na nas samych. Wyobraźmy sobie struk­tu­rę orga­ni­za­cyj­ną fir­my i jej pra­cow­ni­ków. Normalną rze­czą jest, że każ­dy z nas zna Nazwisko prze­ło­żo­ne­go, wie jakich ma (jeśli ma) pod­wład­nych, zna nazwę swo­je­go sta­no­wi­ska, zna nazwę dzia­łu, w któ­rym pra­cu­je i pamię­ta nazwę fir­my, któ­ra go zatrud­nia. Ogólnie mamy te dane w gło­wie (prę­dzej czy póź­niej się tego nauczy­li­śmy). Niewątpliwie jeże­li ktoś ma dzie­się­cio­ro pod­wład­nych, to każ­dy z nich ma w gło­wie (w pamię­ci) kom­plet tych danych, zosta­ły więc powie­lo­ne 10-krot­nie. Marnotrawstwo kory mózgo­wej zespo­łu?!. Nie, po pro­stu ewo­lu­cja daw­no temu odkry­ła, że pew­ne dane nale­ży mieć do uży­cia ad-hoc u sie­bie bo w natu­rze liczy się natych­mia­sto­wy dostęp do tych danych (infor­ma­cji) a nie oszczęd­ność sza­rych komó­rek danej populacji.

Tak więc nazwi­sko pod­wład­ne­go znam na pamięć, a co gdy potrze­bu­je jego adres? Czy muszę wku­wać to wszyst­ko na pamięć? Nie, bo rzad­ko z tego korzy­stam! Muszę tyl­ko wie­dzieć tyl­ko gdzie jest dział kadr, tam są kar­to­te­ki pra­cow­ni­ków. Idę do Pani/Pana i pro­szę o tecz­kę per­so­nal­ną oso­by XXX i dosta­ję, a tam mam wszyst­ko. Przepisuje (powie­lam!) na koper­tę adres do kore­spon­den­cji, odda­ję tecz­kę per­so­nal­ną i wra­cam do swo­je­go biur­ka, pisze list, zakle­jam koper­tę i wysy­łam. To model obiek­to­wy świa­ta, dane – wyłącz­nie nie­zbęd­ne – są prze­cho­wy­wa­ne w naszych gło­wach nie­re­la­cyj­nie, resz­ta ma swo­je miej­sca, wystar­czy że wiem gdzie są, w razie potrze­by o nie poproszę.

A teraz inny model. Jedyne co wie­my o sobie to to, że jeste­śmy na tym świe­cie (zna­my tyl­ko swo­je nazwi­sko i imię), wszyst­ko inne: nasi pod­wład­ni, prze­ło­że­ni, nazwy depar­ta­men­tów, itp. to tyl­ko nitecz­ki pro­wa­dzą­ce do zapi­sów o nich. Nie wiem nic o sobie, jak ktoś zapy­ta kto jest moim sze­fem muszę zła­pać za nitecz­kę o nazwie prze­ło­żo­ny i zoba­czyć co jest na jej koń­cu. Jak mnie ktoś zapy­ta kto jest moim pre­ze­sem, po tych nitecz­kach, jak domi­no, będą brnę­li moi prze­ło­że­ni aż na szczyt hie­rar­chii zatrud­nie­nia i powie­dzą mi, dopie­ro kto jest moim pre­ze­sem. Jeżeli jestem sze­fem, to mam dodat­ko­wo tyle nite­czek do paska ilu mam pod­wład­nych, nie znam żad­ne­go z nich, za każ­dym razem by wska­zać któ­re­go­kol­wiek muszę pocią­gnąć za wszyst­kie nitecz­ki, wybrać jed­ne­go z nich i dopie­ro dać mu robo­tę. Tak wyglą­da model rela­cyj­ny. Tak zwa­na nor­ma­li­za­cja danych pole­ga na tym, że jeże­li jaka­kol­wiek infor­ma­cja mia­ła by się powtó­rzyć w czy­jejś gło­wie, to odbie­ra­my mu te infor­ma­cję, two­rzy­my kar­tecz­kę, na któ­rej ją zapi­su­je­my i nitecz­ka­mi te kar­tecz­kę pod­pi­na­my do każ­de­go komu te infor­ma­cje ode­bra­li­śmy. Każda taka kar­tecz­ka to pro­sty słow­ni­czek gdzie każ­dy zapis jest powią­za­ny nitecz­ką ze wszyst­kim cze­go doty­czy. Tak więc jak mnie ktoś zapy­ta gdzie pra­cu­ję to zamiast z gło­wy natych­miast odpo­wie­dzieć muszę pocią­gnąć za nitecz­kę Pracodawca i zoba­czyć co tam jest napi­sa­ne przy mojej nitecz­ce (a jest ich tam nie mało). Owszem, nazwa pra­co­daw­cy będzie tyl­ko raz zapi­sa­na, praw­do­po­dob­nie uzy­ska­my ogrom­ne oszczęd­no­ści miej­sca na zapi­sy ale też ogrom­nie skom­pli­ku­je­my i wydłu­ży­my dostęp do informacji.

Jak widać, pozy­ska­nie jakiej­kol­wiek infor­ma­cji z rela­cyj­ne­go repo­zy­to­rium to dość kar­ko­łom­ny zabieg. Do tego taki sys­tem ma jesz­cze jed­ną wadę: jak już raz wymy­śli­my jakie to mają być kar­tecz­ki, jak je ze sobą pospi­na­my nitecz­ka­mi, zapi­sze­my je, i nazbie­ra się nam tego, to sys­tem sta­je w zasa­dzie już nie­mo­dy­fi­ko­wal­ny. Jak się przy­tra­fi sytu­acja, w któ­rej dosta­nie­my jakieś infor­ma­cje ze źró­dła, w któ­rym te kar­tecz­ki choć trosz­kę ina­czej zosta­ły wymy­ślo­ne (co jest pra­wie pew­ne) to mamy poważ­ny pro­blem. Nie da się tego zapi­sać w naszym sys­te­mie wprost, musi­my poskle­jać tę cudza wie­dzę i na nowo roze­brać na małe kar­tecz­ki ale już po naszemu.

Po co więc wymy­ślo­no te rela­cyj­ne bazy? To były cza­sy gdy pamięć była naj­kosz­tow­niej­szym zaso­bem kom­pu­te­ra zaś dane mię­dzy sys­te­ma­mi w zasa­dzie nie były wymie­nia­ne! Było kil­ka zalet, np. brak błę­dów nazew­nic­twa itp. wię­cej o nich w sie­ci moż­na poczy­tać, jed­nak moim zda­niem baza danych będą­ca imple­men­ta­cją tak zwa­nych związ­ków poję­cio­wych (tym są rela­cyj­ne mode­le danych) nie spraw­dza się bo nie mode­lu­je obiek­tów świa­ta rze­czy­wi­ste­go a jedy­nie ich nazwy i powią­za­nia mię­dzy nimi a to ogrom­na różnica.

A co dzisiaj mamy

Dzisiaj mamy: wie­le róż­nych sys­te­mów w każ­dej fir­mie, powszech­ną wymia­nę danych wewnątrz fir­my i mię­dzy fir­ma­mi oraz naj­gor­sze czy­li zmien­ność śro­do­wi­ska biz­ne­so­we­go. Co mogę poradzić?

Jeżeli pla­nu­jesz wdro­że­nie goto­we­go sys­te­mu opar­te­go na rela­cyj­nej bazie pamię­taj, że:

- etap jego wdra­ża­nia i para­me­try­za­cji to ostat­ni moment na decy­zje o struk­tu­rze infor­ma­cji, potem prak­tycz­nie już nie da się tego zmienić

- jeże­li w trak­cie ana­li­zy wykry­jesz w swo­jej fir­mie jakieś szyb­ko­zmien­ne obsza­ry, zamiast inwe­sto­wać w kolej­ny moduł duże­go sys­te­mu ERP, zleć napi­sa­nie dedy­ko­wa­ne­go pod­sys­te­mu w now­szej tech­no­lo­gii i zin­te­gruj go z tym ERP

- jeże­li dostaw­ca ERP powie Ci, że inte­gra­cja cze­go­kol­wiek z tym sys­tem wyma­ga dużej i kosz­tow­nej pra­cy nie kupuj tego systemu.

Tak wiec zanim wybie­rze­my sys­tem ERP wyobraź­my sobie, że wdro­że­nie zmu­si nas do prze­nie­sie­nia naszej wie­dzy z głów na małe kar­tecz­ki, zmu­si nas do powią­za­nia tego wszyst­kie­go set­ka­mi nite­czek, pogo­dze­nia się z tym, że dopó­ki będzie­my mie­li ten sys­tem nie­wie­le będzie­my mogli póź­niej w tym wszyst­kim cokol­wiek zmie­nić. Jedną z poważ­niej­szych wad sys­te­mów zin­te­gro­wa­nych jest to, że są zin­te­gro­wa­ne gdyż nadal więk­szość z nich to inte­gra­cja poprzez współ­dzie­le­nie danych.

Co robić? Moim zda­niem war­to po pro­stu dobrze się nad tym wszyst­kim zasta­no­wić, oce­nić róż­ne warian­ty i na koń­cu dopie­ro wybrać sys­tem ERP i jego dostaw­cę. Raczej złą kolej­no­ścią jest kolej­ność odwrotna.

[2012]

Na kon­fe­ren­cji GOTO wystą­pił Martin Fowler, któ­ry tak widzi wpo­wyż­sze problemy:

Zarządzanie IT w czasach nowych wyzwań rynkowych

Diagnoza sta­nu obec­ne­go i nie­da­le­kiej historii. 

Kryzys na ryn­ku opro­gra­mo­wa­nia to naj­więk­szy pro­blem z jakie­go się wydo­sta­ją zarów­no twór­cy i dosta­wy opro­gra­mo­wa­nia jak i jego odbiorcy.

Odbiorcy bory­ka­ją się z nie­uda­ny­mi wdro­że­nia­mi, mniej­szą od ocze­ki­wa­nej wydaj­no­ścią kadr korzy­sta­ją­cych z zaku­pio­ne­go opro­gra­mo­wa­nia. Dostawcy cier­pią z powo­du rosną­cej nie­chę­ci do pono­sze­nia przez kupu­ją­cych ogrom­nych kosz­tów wdro­żeń i bra­nia całe­go ryzy­ka na sie­bie. Poniższy dia­gram obra­zu­je wizję pro­ce­su ewo­lu­cji opro­gra­mo­wa­nia wraz z pro­gno­zą na naj­bliż­sze lata.

Ewolucja opro­gra­mo­wa­nia to natu­ral­ny pro­ces roz­wo­ju usług na ryn­ku IT. Długoterminowo to odbior­cy tych tech­no­lo­gii mają decy­du­ją­cy wpływ na kształt i funk­cjo­nal­ność tech­no­lo­gii IT gdyż tak na praw­dę to oni są głów­ny­mi inwe­sto­ra­mi w fir­my inte­gra­tor­skie. Każdy duży pro­jekt infor­ma­tycz­ny to tak napraw­dę pro­jekt inwe­sto­wa­nia w fir­mę wdra­ża­ją­cą przez odbior­cę wdra­ża­ne­go roz­wią­za­nia. Mając to na uwa­dze łatwo zro­zu­mieć dla­cze­go nowe tren­dy wyge­ne­ro­wa­ne przez inno­wa­cyj­ne fir­my nie zawsze znaj­du­ją swój dal­szy ciąg. Bywa, że poja­wia­ją się za wcze­śnie a bywa, że tak na praw­dę potrze­ba wykre­owa­na przez taką inno­wa­cyj­na fir­mę jest fał­szy­wą potrze­bą. To zna­czy, potrze­ba ist­nie­je ale jej zaspo­ko­je­nie przy­no­si efek­ty dale­ko mniej­sze od ofe­ro­wa­nych. Tak było z dotcomm?ami, w dużym stop­niu tak­że z sys­te­ma­mi MRP/ERP czy CRM (kil­ka firm w Polsce zban­kru­to­wa­ło z powo­du bra­ku ocze­ki­wa­ne­go zwro­tu z inwe­sty­cji w sys­tem infor­ma­tycz­ny). Jednym z pod­sta­wo­wych mier­ni­ków oce­ny takich inwe­sty­cji sta­ją się TCO, ROI, bench­mar­king. Jeżeli trud­no jest oce­nić zwrot z inwe­sty­cji (ROI) moż­na porów­nać (bench­mar­king) swój pro­jekt z inny­mi spraw­dzo­ny­mi w innych podob­nych fir­mach. Przed zaku­pem oce­nić kosz­ty posia­da­nia (TCO) sys­te­mu infor­ma­tycz­ne­go obec­nie eks­plo­ato­wa­ne­go i pla­no­wa­ne­go do wdrożenia.

Koszty sys­te­mów infor­ma­tycz­nych są bar­dzo duże, dla­te­go fir­my two­rzą­ce opro­gra­mo­wa­nie poświę­ca­ją nie mało środ­ków na to, by ich pro­duk­ty były tań­sze we wdro­że­niach i w eks­plo­ata­cji. Największe kosz­ty pono­szo­ne były swe­go cza­su na zapew­nie­nie wymia­ny danych pomię­dzy użyt­ko­wa­ny­mi sys­te­ma­mi pocho­dzą­cy­mi od róż­nych pro­du­cen­tów. Systemy pośred­ni­czą­ce w wymia­nie danych pomię­dzy apli­ka­cja­mi nie­jed­no­krot­nie były droż­sze od tych apli­ka­cji. Dlatego ewo­lu­cja opro­gra­mo­wa­nia zmie­rza w stro­ną total­nej kom­pa­ty­bil­no­ści. Obserwujemy rosną­cą popu­lar­ność tech­no­lo­gii XML (uni­wer­sal­ne inter­fej­sy do wymia­ny danych), sys­te­my SAN i NAS czy­li współ­dzie­lo­nych zaso­bów pamię­ci maso­wych. Motory baz danych (RDBMS) już są na tyle uni­wer­sal­ne, ze więk­szość apli­ka­cji może korzy­stać z dowol­ne­go, dostęp­ne­go na ryn­ku pro­duk­tu tego typu. W efek­cie sys­te­my infor­ma­tycz­ne jako zaso­by będą na tyle uni­wer­sal­ne i kom­pa­ty­bil­ne mie­dzy sobą, że poszcze­gól­ne typy zaso­bów będą w danym sys­te­mie wystę­po­wa­ły tyl­ko raz i będą dostęp­ne dla każ­dej potrze­bu­ją­cej ich aplikacji.

Największy boom cze­ka roz­wią­za­nia bazu­ją­ce na inter­fej­sie WWW. Jest to obec­nie naj­bar­dziej uni­wer­sal­ny inter­fejs za pomo­cą któ­re­go może­my mieć dostęp do potrzeb­nych apli­ka­cji. Jak już wyżej napi­sa­łem, użyt­kow­ni­cy pre­fe­ru­ją pła­ce­nia za to co przy­no­si bez­po­śred­nie korzy­ści. Dlatego pro­ces two­rze­nia i roz­wo­ju sys­te­mów sta­je się wła­sno­ścią dostaw­cy opro­gra­mo­wa­nia. Nadwieszą war­tość ma sama apli­ka­cja a tak na praw­dę funk­cjo­nal­ność jaką ofe­ru­ję. Drugim waż­nym czyn­ni­kiem jest bez­pie­czeń­stwo prze­twa­rza­nych danych. Udział pozo­sta­łych kosz­tów jest powo­li mar­gi­na­li­zo­wa­ny u kupu­ją­cych. W efek­cie daje się zaob­ser­wo­wać to o czym wspo­mnia­łem: inwe­stor bie­rze na sie­bie ryzy­ko przy­dat­no­ści i póź­niej­sze­go użyt­ko­wa­nia sys­te­mu infor­ma­tycz­ne­go, ryzy­ko two­rze­nia i roz­wo­ju pozo­sta­je po stro­nie dostaw­cy. Poniższy dia­gram obra­zu­je pro­ces rosną­ce­go zna­cze­nia jako­ści apli­ka­cji (wytwo­rzo­nej war­to­ści) nad pra­cą jaką poświę­ca na to jej dostawca.

Kolejną tech­no­lo­gią prze­zy­wa­ją­cą boom jest są bez­prze­wo­do­we sys­te­my dostę­po­we. Zdalny dostęp a w kon­se­kwen­cji peł­na mobil­ność to pod­sta­wo­we cechy nowo­cze­sne­go sys­te­mu infor­ma­tycz­ne­go. Podstawowe korzy­ści jakie nie­sie ze sobą mobil­ność to łatwość wyko­na­nia potrzeb­nej pra­cy w dowol­nym miej­scu. Rzecz w tym, że pro­ce­sy biz­ne­so­we wspo­ma­ga­ne przez tech­no­lo­gie IT były do tej pory zwią­za­ne z zaso­ba­mi infor­ma­tycz­ny­mi, któ­re je wspie­ra­ły. W efek­cie wydaj­ność pra­cy nie zawsze mogła rosnąć lub kosz­ty nie­któ­rych pro­ce­sów były wie­sze. Podstawowym pro­ble­mem jest dostęp do infor­ma­cji i jej aktu­al­ność. Wielu pra­cow­ni­ków firm znacz­ną część cza­su prze­by­wa poza fir­mą, w miej­scach gdzie tra­dy­cyj­ny dostęp do zaso­bów IT macie­rzy­stej fir­my jest nie­moż­li­wy. Pierwszym ele­men­tem roz­wią­zu­ją­cym ten pro­blem w czę­ści jest sieć Internet, dzię­ki któ­rej może­my mieć dostęp do zaso­bów fir­my z każ­de­go miej­sca w któ­rym jest dostęp do sie­ci Internet. Jednak te wła­śnie miej­sca do tej pory były zwią­za­ne fizycz­nie z punk­tem ich insta­la­cji (biu­ra innych firm, kawia­ren­ki inter­ne­to­we itp.). Technologie bez­prze­wo­do­we uwal­nia­ją nas od tych ogra­ni­czeń. Przemieszczanie się z kom­pu­te­rem w ręku prze­sta­je ozna­czać brak dostę­pu do fir­mo­wej sie­ci. Rozwój tele­fo­nii komór­ko­wej i sprzę­tu prze­no­śne­go powo­li pro­wa­dzi do uwol­nie­nia zależ­no­ści tech­no­lo­gii infor­ma­tycz­nych od miej­sca pobytu.

Podsumowanie

Systemy infor­ma­tycz­ne sta­ją się coraz bar­dziej uni­wer­sal­ne patrząc na nie od stro­ny kom­pa­ty­bil­no­ści baz danych czy miejsc ich skła­do­wa­nia. W efek­cie moż­na już je podzie­lić na nie­za­leż­ne zbio­ry prze­twa­rza­nych danych oraz apli­ka­cje słu­żą­ce do wpro­wa­dza­nia, prze­twa­rza­nia i wypro­wa­dza­nia tych danych.

Firmy infor­ma­tycz­ne, szcze­gól­ne twór­cy opro­gra­mo­wa­nia muszą zacząć szcze­gól­nie dbać o jakoś dostar­cza­nych pro­duk­tów, gdyż ryzy­ko wyni­ka­ją­ce z ich jako­ści i przy­dat­no­ści coraz czę­ściej jest zrzu­ca­ne wła­śnie na nich. Odbiorcy sys­te­mów (spon­so­rzy pro­jek­tów) zaczy­na­ją wymu­szać w umo­wach rów­no­mier­ne roz­kła­da­nie ryzy­ka na obie stro­ny kontraktu.

Jednym z efek­tów tego pro­ce­su jest coraz czę­ściej spo­ty­ka­na meto­da opłat za roz­wią­za­nia infor­ma­tycz­ne na zasa­dzie ?za zuży­cie? a nie jako zakup na wła­sność. Jednym z tych tren­dów jest out­so­ur­cing. Opłacalny jest szcze­gól­nie tam, gdzie zaso­by infor­ma­tycz­ne są wyko­rzy­sty­wa­ne w spo­sób trud­ny do szcze­gó­ło­we­go zapla­no­wa­na albo w spo­sób bar­dzo nie­rów­no­mier­ny w cza­sie (np. wydru­ki fak­tur na koniec okre­su roz­li­cze­nio­we­go). Obserwujemy zarów­no zmia­ny w sys­te­mach opłat licen­cyj­nych za opro­gra­mo­wa­nie (cyklicz­ne opła­ty za okres użyt­ko­wa­nia opro­gra­mo­wa­nia zamiast jed­no­ra­zo­wej przy zaku­pie) jak i w sys­te­mach opłat za usłu­gi kon­sul­tin­go­we (poja­wia się skład­nik par­ty­cy­pa­cji finan­so­wej w efek­tach takiej pracy).

? Jarosław Żeliński (Źródło dia­gra­mów: mate­ria­ły kon­fe­ren­cyj­ne IDC., kon­fe­ren­cja odbę­dzie się w dniach 29 i 30 Września 2003. Koszt Udziału to 1.940 EUR w przy­pad­ku reje­stra­cji do koń­ca Lipca, 2.300 EUR po tym ter­mi­nie, szcze­gó­ły i for­mu­larz reje­stra­cyj­ny na stro­nach Konferencja Managing IT in Challenging Times).

Notatka: IDC orga­ni­zu­je w dniach 29 – 30 Września 2003r. corocz­ne spo­tka­nie dla CEO/CIO. W tym roku poświę­co­ne ono będzie temu jak tech­no­lo­gie IT mogą pomóc oso­bom zarzą­dza­ją­cym w cza­sie nowych ryn­ko­wych wyzwań.

Trzy pod­sta­wo­we tema­ty zosta­ły potrak­to­wa­ne jako priorytety:
– zasto­so­wa­nia tech­no­lo­gii IT
– sys­te­my pra­cu­ją­ce w opar­ciu o WWW
– sys­te­my mobil­ne i bezprzewodowe