Osobiście zasta­na­wiam się nad ​„ryn­ko­wym” poję­ciem ​„chmur­ki”, bo to nie takie ​„nowe roz­wią­za­nie”. Dla mnie owa chmu­ra (opor­tu­ni­sta jed­nak jestem) to zna­ne od daw­na, kom­po­nen­to­we, obiek­to­we sys­te­my, pro­jek­to­wa­ne obiek­to­wy­mi meto­da­mi zorien­to­wa­ny­mi na tak zwa­ny kon­trakt (obiekt lub kom­po­nent świad­czy okre­ślo­ne usłu­gi wysta­wia­jąc sto­sow­ny, udo­ku­men­to­wa­ny interfejs).

Cloud com­pu­ting, to moim zda­niem kolej­ny ryn­ko­wy buz­zword. Metodą tą, świad­cze­nie usług zdal­ne­go prze­twa­rza­nia poprzez udo­stęp­nio­ne inter­fej­sy, od lat pra­cu­je poprzez sieć wie­le rodza­jów opro­gra­mo­wa­nia OpenSource, a tak­że komer­cyj­ne­go. Przeciętny CMS (Content Management System, ang. System zarzą­dza­nia tre­ścią, są to pro­gra­my uży­wa­ne do zarzą­dza­nia zaawan­so­wa­ny­mi ser­wi­sa­mi WWW) czy blog (odmia­na CMS) potra­fi użyć, auto­ma­tycz­nie zain­sta­lo­wać (użyć) plug-in (wtycz­ka roz­sze­rza­ją­ca moż­li­wo­ści) do zre­ali­zo­wa­nia nowej funk­cjo­nal­no­ści, lokal­nie lub zdal­ne (np. popu­lar­ne od lat sys­te­my two­rze­nia sta­ty­styk ruchu dla stron WWW). Z punk­tu widze­nia samej apli­ka­cji nie ma zna­cze­nia czy kod reali­zu­ją­cy daną funk­cjo­nal­ność jest uru­cha­mia­ny lokal­nie czy poprzez sieć (to cecha sys­te­mów o obiek­to­wej konstrukcji).

Uogólniając (dia­gram powy­żej, źr. WIKI), poszcze­gól­ne wyma­ga­ne funk­cjo­nal­no­ści reali­zo­wa­ne przez opro­gra­mo­wa­nie mogą być zle­ca­ne innym pakie­tom opro­gra­mo­wa­nia, jeże­li te tyl­ko udo­stęp­nia­ją sto­sow­ny inter­fejs. Nic nie stoi więc na prze­szko­dzie by np. pakiet SaleForce wysy­łał dane ze sprze­da­ży do zaksię­go­wa­nia do pakie­tu Microsoft DynamixXL i pobie­rał dane do wyli­cze­nia pro­wi­zji dla sprze­daw­ców. Takich połą­czeń moż­na zbu­do­wać wię­cej jeśli tyl­ko te pakie­ty opro­gra­mo­wa­na będą otwar­te na taką współ­pra­cę (inter­fej­sy). Taki spo­sób pra­cy jest wyko­rzy­sty­wa­ny od lat w wie­lu roz­wią­za­niach opensource.

Wygląda więc na to, że clo­ud com­pu­ting to kolej­ny przy­kład komer­cyj­nej adap­ta­cji pomy­słów śro­do­wisk open­so­ur­ce­’o­wych, któ­re jako spo­łecz­no­ści ska­za­ne są na pra­cę roz­pro­szo­ną i taka archi­tek­tu­ra nie­ja­ko musia­ła powstać.

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”.

Osobiście widzę to tak, że w przy­szło­ści będą na ryn­ku sys­te­my z pod­sta­wo­wy­mi modu­ła­mi wyma­ga­ny­mi prze­pi­sa­mi zbu­do­wa­ny­mi wokół pod­sta­wo­we­go modu­łu finan­so­we­go (cho­dzi o księ­go­wa­nie kon­to­we). Do tego będą opcjo­nal­ne ​„plug-iny” typu maga­zyn, pro­duk­cja, kon­takt­ma­na­ger itp. i tu będzie na ryn­ku kon­ku­ren­cja. Wykształci się rynek firm spe­cja­li­zu­ją­cych się we wdra­ża­niu kon­kret­nych ERP i kon­kret­nych ​„plug-in’ów”. Jest bar­dzo praw­do­po­dob­ne, że inter­fej­sy API ule­gną pew­nej stan­da­ry­za­cji i wie­le kom­po­nen­tów będzie współ­pra­co­wa­ło z wie­lo­ma sys­te­mi ERP. Uważam, że pro­du­cent ERP, któ­ry nie otwo­rzy się na świat z dobrze udo­ku­men­to­wa­nym API z cza­sem ryn­ko­wo umrze.

Jeżeli miał bym coś pole­cić tym, któ­rzy patrzą na clo­ud com­pu­ting jak na poten­cjal­ne narzę­dzie uzy­ska­nia prze­wa­gi kon­ku­ren­cyj­nej, to suge­ru­ję po zana­li­zo­wa­niu potrzeb i wyspe­cy­fi­ko­wa­niu wyma­gań, doko­na­nie oce­ny któ­re wyma­ga­ne funk­cjo­nal­no­ści są biz­ne­so­wo ryzy­kow­ne, oce­nę na ile moż­na je zdo­być na ryn­ku w posta­ci usług innych apli­ka­cji. W zasa­dzie jest to model SaaS (Software as a Service) ale tu mamy do czy­nie­nia z dedy­ko­wa­ny­mi usłu­ga­mi a nie kom­plet­nym, zdal­nie uży­wa­nym oprogramowaniem.

„W poprzed­niej epo­ce fir­my wią­za­ły się na wie­le lat z jed­nym dostaw­cą sys­te­mów IT, roz­prze­strze­nia­jąc wybra­ne sys­te­my w całej orga­ni­za­cji, cze­go efek­tem było czę­sto powsta­nie trud­no zarzą­dzal­nej, sztyw­nej infra­struk­tu­ry, w nie­wiel­kim stop­niu podat­nej na zmia­ny. Analitycy Gartnera są zda­nia, że roz­po­czę­ła się epo­ka pro­jek­tów, któ­re trze­ba będzie roz­po­czy­nać bez zna­jo­mo­ści wszyst­kich wyma­gań użyt­kow­ni­ka, aby nie spóź­nić się na rynek z nowym pro­duk­tem i wyko­rzy­stać spo­sob­ną chwi­lę, któ­ra może się nie powtó­rzyć. Przed nami epo­ka sys­te­mów, któ­re budo­wa­ne są z myślą o ich usta­wicz­nych mody­fi­ka­cjach w odpo­wie­dzi na zmie­nia­ją­cą się sytu­ację ryn­ko­wą.” (źr. Gartner/ERPStandart)