15
ERP vs. SOA ili Cloud Computing Ivan Pogarčić, Vlatka Davidović, Ida Panev Poslovni odjel, Studij informatike, Veleučilište u Rijeci, Trpimirova 2/V, 51000 Rijeka, Hrvatska { pogarcic , vdavid, ipanev}@veleri.hr Sažetak: Brzina razvoja hardvera i softvera je, najvećim dijelom, posljedica zahtjeva iz okruženja u kojem se koristi oprema ili implementira odreĎeno softversko rješenje. Kako su zahtjevi postajali sofisticiraniji tako je i teorijski ali i praktični pristup njihovom rješavanju bivao sofisticiraniji. S druge strane informatika kao znanost nije oblikovala svoje jezgro upravo zbog kratkog vremena i brzih promjena. Promjene su se očitovale u pragmatičkim zaokretima ili pomacima koji su ostavljali neugodan dojam nesnalaženja u novo nastalim okolnostima svih koji su povezani na bilo koji način. Dok je otvorenost oblikovanja i primjene na nivou hardvera bio (i ostao) veliki napreda k u području softvera i posebno organizacijskim oblicima njegove primjene svaka inovacija znači i temeljito preispitivanje cjelokupnih odnosa. Outsourc ing IT odjela u poslovnim sustavima je jedna od značajnijih promjena nastala kao posljedica svih navedenih promjena. ERP kao način integracije, kontrole i upravljanja informacijama i općenito resursima poslovnog sustava može biti realiziran na različite načine uz primjenu različitih metodologija. Recentni oblici organizacije, SOA i Cloud Computing preferiraju arhitekturu informacijskog sustava kao glavni problem. Rad se bavi problematikom ERP sa stanovišta SOA i Cloud Computinga. Summary: The velocity of developing hardware and software is, usually, a consequence of demands put by the environment which uses that equipment or implements a certain software solution. As the requirements have becoming more sophisticated so has theoretical and practical approach to their solutions. On the other hand, Information Science hasn’t shaped its core precisely due to short time and fast modifications. Modifications have been reflected in pragmatic twists or shifts that have left awkward impression of not recognizing newly developed circumstances of all mutually involved subjects. While openness of forming and applying at the level of hardware has been (and still is) a huge improvement in the field of software and especially among organisation forms of its application, every innovation also implies a thorough re-questioning of all relationships. Outsourcing of IT department in business systems is one of the most important changes made as a consequence of all the mentioned modifications. ERP as way of integration, control and management of information and business resources in general, can be realised in different ways and through different methodologies. The recent forms of organisation, SOA and Cloud Computing, prefer architecture of information system as main problem. Paper researches the issues of ERP from stand point of SOA and Cloud Computing Uvod Kad treba dati odgovor na pitanje postoji li metoda izgradnje informacijskog sustava koju se može smatrati standardnom teško je dati pouzdan i jednoznačan odgovor. Više je razloga tome. Navedimo neke. Osnovni razlog je činjenica da se često ,namjerno ili nenamjerno, informacijski sustav poistovjećuje s aplikativnim rješenjima koja podržavaju funkcioniranje informacijskog sustava u cjelini. Drugi je razlog zanemarivanje stvarne povezanosti i nedjeljivosti poslovnog sustava od njegovog informacijskog sustava. Treći je pak neprimjerenost aplikativnih rješenja potrebama informacijskog sustava i poslovnog sustava u konačnici. Nužno je uzeti u obzir i tretman informacijskog sustava kroz sve faze njegovog životnog ciklusa a posebno kroz fazu operativne uporabe i potreba za modifikacijama i eventualnim migracijama ili integracijama u druge sustave. Ako se informacijski sustav veže za tehnička sredstva i odgovarajuću tehnologiju koja zahtjeva takvu podršku onda se nužno moraju uzeti u obzir svi utjecaji koje je tehnika (hardver) i tehnologija (primijenjeni softver na odabranom hardveru) imaju na proces razvoja i operativnog djelovanja konkretnog informacijskog sustava. Kako su se i hardver i softver razvijali vremenom, doduše s različitim dinamikama tako su i utjecali na oblikovanje tehnika, metoda, tehnologija i metodologija razvoja informacijskog sustava. MeĎutim taj utjecaj nije bio jednosmjeran. Informacijski je sustav dinamička pojavnost s konstantnim promjenama koje su posljedica promjena u pripadnom poslovnom sustavu, preciznije posljedica djelovanja korisnika informacijskog sustava kroz poslovne procese i procese obrade potrebnih informacija. Upravo je korisnik središnji element koji odreĎuje sve druge okolnosti i procese koji se odvijaju tijekom čitavog životnog ciklusa. Pozicija korisnika, njegova involviranost i angažiranost u

ERP vs. SOA ili Cloud Computing

Embed Size (px)

Citation preview

Page 1: ERP vs. SOA ili Cloud Computing

ERP vs SOA ili Cloud Computing

Ivan Pogarčić Vlatka Davidović Ida Panev

Poslovni odjel Studij informatike Veleučilište u Rijeci Trpimirova 2V 51000 Rijeka Hrvatska

pogarcic vdavid ipanevvelerihr

Sažetak Brzina razvoja hardvera i softvera je najvećim dijelom posljedica zahtjeva iz okruženja u kojem se koristi oprema ili implementira odreĎeno softversko rješenje Kako su zahtjevi postajali sofisticiraniji tako je i teorijski ali i praktični pristup njihovom rješavanju bivao sofisticiraniji S druge strane informatika kao znanost nije oblikovala svoje jezgro upravo zbog kratkog vremena i brzih promjena Promjene su se očitovale u pragmatičkim zaokretima ili pomacima koji su ostavljali neugodan dojam nesnalaženja u novo nastalim okolnostima svih koji su povezani na bilo koji način Dok je otvorenost oblikovanja i primjene na nivou hardvera bio (i ostao) veliki napreda k u području softvera i posebno organizacijskim oblicima njegove primjene svaka inovacija znači i temeljito preispitivanje cjelokupnih odnosa Outsourcing IT odjela u poslovnim sustavima je jedna od značajnijih promjena nastala kao posljedica svih navedenih promjena ERP kao način integracije kontrole i upravljanja informacijama i općenito resursima poslovnog sustava može biti realiziran na različite načine uz primjenu različitih metodologija Recentni oblici organizacije SOA i Cloud Computing preferiraju arhitekturu informacijskog sustava kao glavni problem Rad se bavi problematikom ERP sa stanovišta SOA i Cloud Computinga Summary The velocity of developing hardware and software is usually a consequence of demands put by the environment which uses that equipment or implements a certain software solution As the requirements have becoming more sophisticated so has theoretical and practical approach to their solutions On the other hand Information Science hasnrsquot shaped its core precisely due to short time and fast modifications Modifications have been reflected in pragmatic twists or shifts that have left awkward impression of not recognizing newly developed circumstances of all mutually involved subjects While openness of forming and applying at the level of hardware has been (and still is) a huge improvement in the field of software and especially among organisation forms of its application every innovation also implies a thorough re-questioning of all relationships Outsourcing of IT department in business systems is one of the most important changes made as a consequence of all the mentioned modifications ERP as way of integration control and management of information and business resources in general can be realised in different ways and through different methodologies The recent forms of organisation SOA and Cloud Computing prefer architecture of information system as main problem Paper researches the issues of ERP from stand point of SOA and Cloud Computing

Uvod

Kad treba dati odgovor na pitanje postoji li metoda izgradnje informacijskog sustava koju se može smatrati standardnom teško je dati pouzdan i jednoznačan odgovor Više je razloga tome Navedimo

neke Osnovni razlog je činjenica da se često namjerno ili nenamjerno informacijski sustav poistovjećuje s aplikativnim rješenjima koja podržavaju funkcioniranje informacijskog sustava u cjelini Drugi je razlog zanemarivanje stvarne povezanosti i nedjeljivosti poslovnog sustava od njegovog

informacijskog sustava Treći je pak neprimjerenost aplikativnih rješenja potrebama informacijskog sustava i poslovnog sustava u konačnici Nužno je uzeti u obzir i tretman informacijskog sustava kroz sve faze njegovog životnog ciklusa a posebno kroz fazu operativne uporabe i potreba za

modifikacijama i eventualnim migracijama ili integracijama u druge sustave Ako se informacijski sustav veže za tehnička sredstva i odgovarajuću tehnologiju koja zahtjeva takvu podršku onda se nužno moraju uzeti u obzir svi utjecaji koje je tehnika (hardver) i tehnologija

(primijenjeni softver na odabranom hardveru) imaju na proces razvoja i operativnog djelovanja konkretnog informacijskog sustava Kako su se i hardver i softver razvijali vremenom doduše s različitim dinamikama tako su i utjecali na oblikovanje tehnika metoda tehnologija i metodologija

razvoja informacijskog sustava MeĎutim taj utjecaj nije bio jednosmjeran Informacijski je sustav dinamička pojavnost s konstantnim promjenama koje su posljedica promjena u pripadnom poslovnom sustavu preciznije posljedica

djelovanja korisnika informacijskog sustava kroz poslovne procese i procese obrade potrebnih informacija Upravo je korisnik središnji element koji odreĎuje sve druge okolnosti i procese koji se odvijaju tijekom čitavog životnog ciklusa Pozicija korisnika njegova involviranost i angažiranost u

procesu razvoja i implementacije aplikativnih rješenja kao alata kojeg će kasnije koristiti je zasigurno

jedan od čimbenika koji utječe na konačan uspjeh projekta Ovim se radom nastojalo prikazati autorsko viĎenje spomenute problematike kroz usporednu analizu pristupa razvoju uz odgovarajuću ilustraciju i tretiranje najvažnijih pojmova i činjenica koje zahtijevaju

primjereno tretiranje i u teoriji i u praksi Neki problemi od temeljne važnosti hellip

Osnovni problem informacijskih znanosti je relativna mladost posebno ako ih se veže uz računala kao pojavnost Upravo takvo povezivanje naglašava pragmatičku komponentu kod ustanovljavanja

metoda tehnika i općenito metodologija Premda informatika ima svoj osnovni predmet istraživanja ndash informaciju ndash metode koje se koriste u istraživanju i oblikovanju metodologija najčešće su posuĎene iz drugih znanosti Zato je povezanost informacijske znanosti sa semiotikom od posebne važnosti o

čemu će biti govora malo kasnije Od tud proizlaze i problemi u pojmovnom i terminološkom smislu U različitim područjima i različitim jezicima izraz informacijskae znanosti se koriste s različitim namjenama i značenjima Tako na francuskom području informatika (information+automatique)

(TuĎman prema Dreyfus 1972) jest sinonim za automatsku obradu podataka a u njemačkoj za znanost o računalima Ruska predodžba informacijskih znanosti je najšira i predstavlja integralnu znanost o informacijama(TuĎman prema Temnikov1973) izraz informatika označava integralnu

znanost o informacijama Čak što više (TuĎman prema MihajlovampGiljarevski 1967) definiraju informacijsku znanost kao disciplinu koja proučava strukturu i svojstva znanstvenih informacija kao zakonitosti u informacijsko-dokumentacijskoj djelatnosti Pri tome sadržaj informacija nema važnost

Informacijska znanost u najširem smislu je kao znanost definirana na engleskom govornom području (eng information science usvojen 1961) Šira je od ruskog poimanja jer ne tretira samo znanstvene informacije nego informacije iz svih područja ljudskih djelatnosti Uz termine informatika i informacijska

znanost javlja se i termin informatologija koji označava teoriju i praksu emisije transmisije akumulacije selekcije i apsorpcije informacija tzv e-t-ak-s-a kompleks (B Težak 1969) Dakle osnovni je problem artikulacija znanstvene jezgre unutar informacijske znanosti

1 Pojam

informacije je apstraktan sam po sebi ukoliko nije naznačen pragmatički aspekt Iz toga proizlazi činjenica da informacijski sustav egzistira tek u trenutku kad je odreĎena njegova svrha odnosno realni djelatni sustav čije funkcioniranje podržava Naravno da je i takav sustav realan tek onda kad se u

njemu naĎe aktivni korisnik(Kroenke 2008)(OBrien 2003) Posljedično su time odreĎene i metode koje će se primjenjivati u razvoju informacijskog sustava i aplikativnih rješenja koja će ga podržavati Stoga je nužno u svakom informacijskom sustavu uvažavati i tehničku i korisničku komponentu time

da se prednost u tretmanu pojedine komponente prilagoĎava konkretnim situacijama U situacijama kad doĎe do poistovjećivanja informacijskog sustava i aplikativnog rješenja dolazi do svojevrsnog sažimanja u metodologiji razvoja informacijskog sustava Nitko u današnjim uvjetima

globalnog poslovanja i globalne umreženosti ne dovodi u pitanje uporabu računala i računalnih programa ali potrebna brzina izrade novih i prilagoĎavanja postojećih rješenja uvjetuje izbor primjerene metodologije U trenutku kad se korisnik odlučuje o načinu izgradnje i implementacije

aplikativnog rješenja nije nužno da poznaje metodologiju MeĎutim razvoj nije moguć bez korisnika koji poznaje poslovni sustav i stvarne potrebe za informacijama Ako se odluči za bdquokonfekcijsku varijantu― glavninu poslova prepušta dobavljaču koji bira metodologiju koju je koristio pri razvoju

proizvoda (ili njoj sličnu) kojeg prodaje Time pojam standard gubi na svom značenju jer je daljnji razvoj uvjetovan prihvaćanjem te i takve metodologije Nerijetko su proizvoĎači i dobavljači razvijali svoje vlastite metodologije koje se na bilo koji način manje ili više umotavaju u one koje bi trebale biti

opće prihvaćene pa time i standardne Sretna je okolnost standardizacija u pojedinim dijelovima i područjima kojima je naloženo i prihvaćeno jednoobrazno ponašanje Otvorene plat forme su značile veliki preokret ili bolje napredak s kojim je i veći dio metodoloških principa i postavki odreĎen prilično

jednoznačno pa time i neformalno standardiziran Činjenica je da je time odreĎeni monopol velikih proizvoĎača djelomično maknut u stranu doduše prividno jer su zapravo manji proizvoĎači jednostavno bili progutani od strane većih Stoga se danas popis značajnih proizvoĎača softvera može

staviti na prste jedne ruke Time je monopol samo promijenio ruho Priča o kvaliteti i uspjehu

1 Neozbiljnost je očita i na web-u gdje npr postoji slijedeći nonsens Informacijske znanosti je polje

primjenjene znanosti koja se bavi izučavanjem informacija ili znanja i obično a ne eksluzivno uči se kao grana računarstva i informacijske tehnologije (httphrwikipediaorgwikiInformacijske_znanosti 26travnja 2012) Gdje je očita i jezička i pojmovna zbrka kao i gramatičke nesuvislosti izazvane

Google prevoditeljem

proizvoda je obično potpomognuta značajnim referencama ali ne garantira izostanak neuspjeha ili

znatno produženje vremena implementacije Jednako tako je danas skoro nezamisliv poslovni sustav koji nema poslovne i informacijske procese potpomognute računalima i računalnim rješenjima Na taj su način i životni ciklusi oba sustava

informacijskog i poslovnog u sinergijskoj vezi Pače dijele istu sudbinu ndash promjene i modifikacije jednog nužno zahtijevaju promjene i modifikacije drugog Modificiranje informacijskog sustava u skladu s potrebama poslovnog sustava kontinuirani je proces

koji količinom potrebnih aktivnosti varira s mogućnošću dosezanja kritiče mase nakon čega je nužna jedna od tri mogućnosti migracija integracija ili alternacija Teorijski je moguće da tijekom životnog ciklusa informacijskog sustava do potrebe za migracijom ne mora doći Druga je krajnost potreba za

više migracija tijekom životnog ciklusa Dodatni je problem nužnost uvažavanja specifičnosti informacijskih sustava pri pojedinim slučajevima migracije koju svaki od realnih slučajeva čine zasebnim fenomenom Standardizacija metodološkog okvira je tada moguća samo na vrlo visokom

stupnju apstrakcije Nužna je i konkretizacija zahtijeva uvažavanje specifičnosti tijekom migracije i prilagoĎavanje okolnostima bdquou hodu― što lako dovodi do neželjenih okolnosti i neodgovarajućih rezultata U ovakvim se okolnostima informacijski sustav može promatrati kao pojavnost unutar koje

se dešavaju promjene koje mogu imati uvjetno rečeno evolucijski ili revolucijski karakter Uvjetno zbog činjenice da je vrijeme u životu informacijskog sustava kad je vezan za tehničko -tehnološke promjene vrlo relativan činilac Brzina promjena na tom području sve promjene u informacijskom

sustavu čini revolucionarnima ali način odvijanja i slijedna povezanost ima evolutivni karakter (vidi sliku 1)

Slika 1 Operativne aktivnosti kao pokazatelj intenziteta promjena (Bisbal et al 1997)

I kod migracije je problem kojeg se često zanemaruje namjerni ili nenamjerni naglašeni tretman tehničke komponente Posebno kad je jedan od razloga modificiranja moderniziranje u području hardvera Ovakve se situacije očituju u prepuštanju izbora metodologije migracije proizvoĎaču ili

dobavljaču softvera bez prethodne adekvatne provjere njezine kvalitete Pogotovo je to slučaj kad proizvoĎač softvera preferira odreĎena tehnička rješenja u području hardvera ProizvoĎač obično nudi kao dokaz o kvaliteti reference na lokacije i sustave u kojima su primijenjena rješenja koja nudi i

gdje funkcioniraju Naravno da je provjera i povratna informacija s takvih pozicija moguća ali obično zahtijeva dodatno vrijeme i novac što se nastoji izbjeći i s aspekta korisnika i s aspekta dobavljača U ranijim rješenjima je ovo bio trenutak kad se donosila odluka o kupnji ili vlastitoj izgradnji informacijskih

sustava formiranju računskih centara i ekipa zaduženih za pojedine poslove i aktivnosti U današnjim okolnostima s proklamiranjem SOA rješenja i Cloud Computinga takve dileme ne postoje Naravno pod uvjetom da poslovni sustav prihvati takav način izgradnje informacijskog sustava Premda

metodologije izgradnje pa posljedično i promjena u strukturi informacijskih sustava na taj način mogu biti znanstveno upitne i teško provjerljive posjeduju odreĎena empirijska svojstva Svaki ozbiljniji proizvoĎač softvera svakom novom instalacijom stječe iskustvo koje može biti sistematizirano i može

biti osnova za definiranje metodološkog okvira Ukoliko pri tome slijede odreĎene znanstvene stavove ta osnova može biti pouzdana kod definiranja metodologija koje time imaju znanstveni karakter Slijedeća bitna činjenica u izgradnji i promjenama unutar informacijskog sustava je projektni pristup i

timska realizacija projekta Izgradnja je proces i sačinjena je od niza aktivnosti koje zahtijevaju i

Operativne aktivnosti

wrapping

Revolucija sustava Evolucija sustava

(-) Utjecaj na sustav (+)

Broj promjena

u naslijeđu

održavanje migracija daljnji razvoj

planiranje i kontrolu pri realizaciji ali i okupiraju odreĎene resurse u prvom redu meĎu korisnicima koji

dolaze iz poslovnog okruženja Svaki integralni oblik informacijskog sustava unutra nekog poslovnog sustava je skup automatiziranih procesa obrada informacija koje dolazeodlaze izu različitih poslovnih aktivnosti To nužno podrazumijeva tim sastavljen od pojedinaca različitih profila i različitih znanja i

mogućnosti Podrazumijevano je uspjeh realizacije vezan za timsku sposobnost a ova je zavisna od sposobnosti svakog člana pojedinačno Stoga se u ozbiljnijoj literaturi koja tretira ovakvu problematika kao osnovni uvjet postavlja postojanje paradigme koju prihvaća i primjenjuje tim koji realizira projekt

Kroz kratku povijest razvoja računala i računalnih aplikacija ndash softvera ndash upravo je paradigma bila presudna za promjene u poimanjima i pristupu izgradnji ili modifikaciji informacijskog sustava

Pojmovna nedefiniranosti ili namjerna pojmovna zbrka U svrhu ovog razmatranja se potrebno odrediti prema nekim osnovnim pojmovima u okviru

informacijskih znanosti To su

Informacijski sustav

Korisnik

Paradigma

Struktura informacijskog sustava

Arhitektura informacijskog sustava Vjerojatno broj definicija informacijskog sustava skoro bijekcijski korespondira broju objavljenih radova

vezanih za ovu problematiku Stoga je već u početku mogućnost neprikladne definicije problem koji može inicirati kasnije veće i teže probleme Definicija informacijskog sustava najčešće uključuje pragmatičku stranu i ukazuje na korisne aspekte informacijskog sustava kao po javnosti Pojmovno ali

i djelatno informacijski sustav jest sveukupno područje informacijske djelatnosti koje tvori organiziranu cjelinu sustav (TuĎman at al 2012) Djelatno je svaki informacijski sustav odreĎen nizom aktivnosti koje uključuju prikupljanje sortiranje obradu pa opet eventualno sortiranje spremanje i čuvanje te

dijeljenje prema korisnicima kojima su namijenjene Očigledno je vezivanje definicije za korisnika što nužno zahtijeva definiciju tog nezaobilaznog činitelja Povijesno pojam korisnika u informacijskom sustavu je konstanta kojoj se u raznim fazama razvoja informacijskih sustava pridjeljuje različit simbo l

oznaka i naziv Obzirom na temeljno značenje korisnika u životu informacijskog svako nijansiranje bilo u značenju bilo u označavanju predstavlja problem na bilo koji način Ako se informacijski sustav svede na okvire aplikativnog softvera koji podržava informacijske procese

u nekom poslovnom sustavu tada se s pravom postavlja pitanje nedvosmislenosti kod definiranja korisnika informacijskog sustava U takvim okvirima postoje dvije vrste korisnika korisnik usluga informacijskog sustava ili uživalac beneficija i produkata informacijskih procesa koji se odvijaju u

takvom sustavu ali i aktivni djelatnik zadužen za nesmetanu i valjanu funkcionalnost tog i takvog sustava Potonji se može prepoznati u različitim ulogama i zaduženjima koja se grupiraju u informatičke djelatnosti dakle informatičar na ovaj ili onaj način

Osim precizne definicije sustava i korisnika koji su rudiment i osnovna pokretačka os informaci jskog sustav nužno je precizno odreĎenje i pojma paradigma Naime svaka pojavnost ima fizičku komponentu realiziranu na odreĎeni način Premda je uz pojam informacija i informacijski sustav

najčešće vezano (ili grublje prikačeno) i puno pojmova koji se proglašavaju na bilo koji način najčešće olako virtualnima potreba za njihovom povremenom fizičkom realizacijom je dodatni osjetljivi moment u realizaciji i funkciji informacijskog sustava Kad se nešto u takvom okruženju može smatrati

virtualnim nije pitanje realizacije koliko sveukupnog poimanja potreba Takva potreba može biti konstanta jednako kao i izolirana elementarna situacija u funkcioniranju sustava u cijelosti Paradigma je u razvoju dijela informacijskih znanosti od izuzetne važnosti iz više razloga Ako se

pogleda definicija paradigme u smisli kako je definirana (Kuhn 1996) da se ne ide do starogrčkih filozofa bit će očito da je za njezinu realizaciju ili provedbu nužno propitivanje stavova svih učesnika u razvoju informacijskih sustava

Logično je da realizacija projekta ovisi u prvom redu od nositelja realizacije Tako realizacija informacijskog sustava kao softverskog rješenja ili u cjelini zavisi od nositelja aktivnosti MeĎutim u realizaciji bilo kakvog rješenja učestvuje tim a ne pojedinac pa je uspjeh projekta zavisan ne od stava

i aktivnosti pojedinca nego od ukupnog stava i ukupne aktivnosti tima UsklaĎenost stavova i mišljenja je nužna da bi se mogla definirati politika ili pristup tima konkretnom poslu Iz pristupa nužno proizlazi dinamika kao najvažniji element realizacije projekta

Zašto inzistirati na pojmovnom čistunstvu Ako se zna da samo 20 informacijskih sustava u svijetu pokazuje učinkovitost da 40 ostvaruje marginalnu dobit a preostalih 40 predstavlja promašaj onda vjerojatno dio neuspjeha jest u rudimentu cijele priče Čisto deduktivno ako se svi članovi tima

uključujući korisnike (benefita) ne razumiju ili ne govore istim jezikom neuspjeh je sasvim izvjestan

Osnovi je cilj ovog rada pokazati kroz povijesne promjene terminologije metodologije i primjenjivih

tehnika razvoja u informacijskim znanostima kako je pojmovna neodreĎenost i zbrka osnovni razlog svih neuspjeha koji su najbolje objedinjeni u Solow-ljevu paradoksu

2 a odražavaju gore navedeni

raster

Prije kratkog pregleda bdquopovijesnih― promjena u navedenim područjima nužno je napomenuti i definirati pojmove strukture informacijskih sustava i arhitekture informacijskih sustava to više što su ova dva pojma usko vezana za paradigmu (pristup realizaciji informacijskog sustava) i odreĎuju osnovne

postavke i razvoja i implementacije aplikativnih rješenja kao osnovne podrške informacijskim procesima Kako će biti kasnije pokazano pomicanje težišta osnovnog problema izgradnje informacijskog sustava od strukture prema arhitekturi izazvat će bdquopotrese― koje sveukupno okruženje

često teško a ponekad nikako ne amortizira Po pojmom strukture informacijskog sustava podrazumijevamo unutrašnji raspored elemenata koji ga čine njihov sastav poredak i sveukupne odnose u informacijskom sustavu(TuĎman at al 2012)

Činitelji strukture su informacijski subjekti informacijska kultura oprema tehnološka osnovica (uključujući softver) i okruženje u kojem se informacijski sustav realizira Opis strukture implicitno pokazuje ono što čini sustav konfiguraciju elemenata način kao su povezani ili kako meĎusobno

suraĎuju te da li postoji strukturna organiziranost u smislu hijerarhije ili slično Nakon jedne od izmjena paradigme u izgradnji informacijskih sustava se počelo govoriti o arhitekturi informacijskih sustava Premda su pojmovi struktura i arhitektura u većini odrednica bliski razlika je u

ovom području od bitne važnosti Ako se arhitekturu promatra kao stil i način projektiranja neke pojavnosti onda je jasno da se mora nužno odvojiti od pojma strukture Naime ista arhitektura može biti način realizacije različitih struktura U trenutku kad se u organizaciji informacijskih sustava počine

preferirati pojam arhitekture struktura se počinje gurati u drugi plan i postavljati u nadležnost korisnika koji nužno ne moraju poznavati procese metode i metodologije izgradnje informacijskog sustava Iz tih okvira izvire jedan novi Solow koji zahtjeva ponovno propitivanje odnosa svih učesnika u izgradnji

informacijskog sustava Kako i zašto slijedi u nastavku Od monolita do CC i dalje hellip

Praktična i smislena uporaba računala uključuje odreĎenu programsku podršku koja podrazumijeva postojanje podataka Podatci se obraĎuju u skladu s tom podrškom a prema algoritmima koje sadrže

aplikativni programi Realizacija obrade se ostvaruje kroz odreĎeni oblik komunikacije korisnik ndash računalo Kad su korisnik računalo i podatci na istom mjestu govori se o monolitnim aplikacijama (slika 1) Premda se ovakav oblik aplikacija smatra početcima računalne podrške

monolitne aplikacije nisu čista povijest jer i danas specifični sustavi mogu zahtijevati ovakvo rješenje Najčešće su to aplikacije specifične namjene pa su i korisnici specijalizirani i specifični Monolitnost pretpostavlja koegzistiranje sustava i korisnika u istom okruženju najčešće bez česte potrebe za

komunikacijom s okolinom Monolitnost za posljedicu ima čvrstu strukturu pa time i arhitekturu sustava Još je jedno svojstvo monolitnih aplikacija izraženo a to je visoka rutiniranost u obradi podataka

(BatiniampScannapieca 2006) definiraju prostor u kojem su smješteni svi informacijski sustavi prema

svojoj strukturi i arhitekturi Prostor je odreĎen koordinatama potpunost (totally ) heterogenost (heterogeneity) i distribuiranost (distribution)

Uvažavajući ova tri svojstva po mjerivom intenzitetu monolitni su sustavi postavljeni u ishodište koordinatnog sustava Dakle klasificirani su kao

homogeni nisu distribuirani i specijalizirani su U dijagonalnoj točki prostora autori smještaju tzv P2P informacijske sustave Sustavi tipa peer_to_peer se

deklariraju kao autonomni i nezavisni od računala

poslužitelja odnosno sve tri komponente imaju maksimalan intenzitet Prema strukturi se ovakvi

2 Više tehnologije u školi može imat i štetan utjecaj na obrazovanje a računala kod kuće mogu naškoditi učenju

ili bdquoMožete osjetiti eru računala posvuda ovih dana osim u statistici produktivnosti su izjave nobelovca

Roberta Solow doduše izrečene 1987 godine Pokušaj rev izije stava Arnold King tvrdnjom da se to promijenilo i

da možda vrijed i za Evropu ko ja drugačije koristi računala od USA

Slika 2 Monolitna aplikacija (izvor httprubyonrailslinkblogspotcom201009single-tier-architecturehtml 10 Travnja 2012

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 2: ERP vs. SOA ili Cloud Computing

procesu razvoja i implementacije aplikativnih rješenja kao alata kojeg će kasnije koristiti je zasigurno

jedan od čimbenika koji utječe na konačan uspjeh projekta Ovim se radom nastojalo prikazati autorsko viĎenje spomenute problematike kroz usporednu analizu pristupa razvoju uz odgovarajuću ilustraciju i tretiranje najvažnijih pojmova i činjenica koje zahtijevaju

primjereno tretiranje i u teoriji i u praksi Neki problemi od temeljne važnosti hellip

Osnovni problem informacijskih znanosti je relativna mladost posebno ako ih se veže uz računala kao pojavnost Upravo takvo povezivanje naglašava pragmatičku komponentu kod ustanovljavanja

metoda tehnika i općenito metodologija Premda informatika ima svoj osnovni predmet istraživanja ndash informaciju ndash metode koje se koriste u istraživanju i oblikovanju metodologija najčešće su posuĎene iz drugih znanosti Zato je povezanost informacijske znanosti sa semiotikom od posebne važnosti o

čemu će biti govora malo kasnije Od tud proizlaze i problemi u pojmovnom i terminološkom smislu U različitim područjima i različitim jezicima izraz informacijskae znanosti se koriste s različitim namjenama i značenjima Tako na francuskom području informatika (information+automatique)

(TuĎman prema Dreyfus 1972) jest sinonim za automatsku obradu podataka a u njemačkoj za znanost o računalima Ruska predodžba informacijskih znanosti je najšira i predstavlja integralnu znanost o informacijama(TuĎman prema Temnikov1973) izraz informatika označava integralnu

znanost o informacijama Čak što više (TuĎman prema MihajlovampGiljarevski 1967) definiraju informacijsku znanost kao disciplinu koja proučava strukturu i svojstva znanstvenih informacija kao zakonitosti u informacijsko-dokumentacijskoj djelatnosti Pri tome sadržaj informacija nema važnost

Informacijska znanost u najširem smislu je kao znanost definirana na engleskom govornom području (eng information science usvojen 1961) Šira je od ruskog poimanja jer ne tretira samo znanstvene informacije nego informacije iz svih područja ljudskih djelatnosti Uz termine informatika i informacijska

znanost javlja se i termin informatologija koji označava teoriju i praksu emisije transmisije akumulacije selekcije i apsorpcije informacija tzv e-t-ak-s-a kompleks (B Težak 1969) Dakle osnovni je problem artikulacija znanstvene jezgre unutar informacijske znanosti

1 Pojam

informacije je apstraktan sam po sebi ukoliko nije naznačen pragmatički aspekt Iz toga proizlazi činjenica da informacijski sustav egzistira tek u trenutku kad je odreĎena njegova svrha odnosno realni djelatni sustav čije funkcioniranje podržava Naravno da je i takav sustav realan tek onda kad se u

njemu naĎe aktivni korisnik(Kroenke 2008)(OBrien 2003) Posljedično su time odreĎene i metode koje će se primjenjivati u razvoju informacijskog sustava i aplikativnih rješenja koja će ga podržavati Stoga je nužno u svakom informacijskom sustavu uvažavati i tehničku i korisničku komponentu time

da se prednost u tretmanu pojedine komponente prilagoĎava konkretnim situacijama U situacijama kad doĎe do poistovjećivanja informacijskog sustava i aplikativnog rješenja dolazi do svojevrsnog sažimanja u metodologiji razvoja informacijskog sustava Nitko u današnjim uvjetima

globalnog poslovanja i globalne umreženosti ne dovodi u pitanje uporabu računala i računalnih programa ali potrebna brzina izrade novih i prilagoĎavanja postojećih rješenja uvjetuje izbor primjerene metodologije U trenutku kad se korisnik odlučuje o načinu izgradnje i implementacije

aplikativnog rješenja nije nužno da poznaje metodologiju MeĎutim razvoj nije moguć bez korisnika koji poznaje poslovni sustav i stvarne potrebe za informacijama Ako se odluči za bdquokonfekcijsku varijantu― glavninu poslova prepušta dobavljaču koji bira metodologiju koju je koristio pri razvoju

proizvoda (ili njoj sličnu) kojeg prodaje Time pojam standard gubi na svom značenju jer je daljnji razvoj uvjetovan prihvaćanjem te i takve metodologije Nerijetko su proizvoĎači i dobavljači razvijali svoje vlastite metodologije koje se na bilo koji način manje ili više umotavaju u one koje bi trebale biti

opće prihvaćene pa time i standardne Sretna je okolnost standardizacija u pojedinim dijelovima i područjima kojima je naloženo i prihvaćeno jednoobrazno ponašanje Otvorene plat forme su značile veliki preokret ili bolje napredak s kojim je i veći dio metodoloških principa i postavki odreĎen prilično

jednoznačno pa time i neformalno standardiziran Činjenica je da je time odreĎeni monopol velikih proizvoĎača djelomično maknut u stranu doduše prividno jer su zapravo manji proizvoĎači jednostavno bili progutani od strane većih Stoga se danas popis značajnih proizvoĎača softvera može

staviti na prste jedne ruke Time je monopol samo promijenio ruho Priča o kvaliteti i uspjehu

1 Neozbiljnost je očita i na web-u gdje npr postoji slijedeći nonsens Informacijske znanosti je polje

primjenjene znanosti koja se bavi izučavanjem informacija ili znanja i obično a ne eksluzivno uči se kao grana računarstva i informacijske tehnologije (httphrwikipediaorgwikiInformacijske_znanosti 26travnja 2012) Gdje je očita i jezička i pojmovna zbrka kao i gramatičke nesuvislosti izazvane

Google prevoditeljem

proizvoda je obično potpomognuta značajnim referencama ali ne garantira izostanak neuspjeha ili

znatno produženje vremena implementacije Jednako tako je danas skoro nezamisliv poslovni sustav koji nema poslovne i informacijske procese potpomognute računalima i računalnim rješenjima Na taj su način i životni ciklusi oba sustava

informacijskog i poslovnog u sinergijskoj vezi Pače dijele istu sudbinu ndash promjene i modifikacije jednog nužno zahtijevaju promjene i modifikacije drugog Modificiranje informacijskog sustava u skladu s potrebama poslovnog sustava kontinuirani je proces

koji količinom potrebnih aktivnosti varira s mogućnošću dosezanja kritiče mase nakon čega je nužna jedna od tri mogućnosti migracija integracija ili alternacija Teorijski je moguće da tijekom životnog ciklusa informacijskog sustava do potrebe za migracijom ne mora doći Druga je krajnost potreba za

više migracija tijekom životnog ciklusa Dodatni je problem nužnost uvažavanja specifičnosti informacijskih sustava pri pojedinim slučajevima migracije koju svaki od realnih slučajeva čine zasebnim fenomenom Standardizacija metodološkog okvira je tada moguća samo na vrlo visokom

stupnju apstrakcije Nužna je i konkretizacija zahtijeva uvažavanje specifičnosti tijekom migracije i prilagoĎavanje okolnostima bdquou hodu― što lako dovodi do neželjenih okolnosti i neodgovarajućih rezultata U ovakvim se okolnostima informacijski sustav može promatrati kao pojavnost unutar koje

se dešavaju promjene koje mogu imati uvjetno rečeno evolucijski ili revolucijski karakter Uvjetno zbog činjenice da je vrijeme u životu informacijskog sustava kad je vezan za tehničko -tehnološke promjene vrlo relativan činilac Brzina promjena na tom području sve promjene u informacijskom

sustavu čini revolucionarnima ali način odvijanja i slijedna povezanost ima evolutivni karakter (vidi sliku 1)

Slika 1 Operativne aktivnosti kao pokazatelj intenziteta promjena (Bisbal et al 1997)

I kod migracije je problem kojeg se često zanemaruje namjerni ili nenamjerni naglašeni tretman tehničke komponente Posebno kad je jedan od razloga modificiranja moderniziranje u području hardvera Ovakve se situacije očituju u prepuštanju izbora metodologije migracije proizvoĎaču ili

dobavljaču softvera bez prethodne adekvatne provjere njezine kvalitete Pogotovo je to slučaj kad proizvoĎač softvera preferira odreĎena tehnička rješenja u području hardvera ProizvoĎač obično nudi kao dokaz o kvaliteti reference na lokacije i sustave u kojima su primijenjena rješenja koja nudi i

gdje funkcioniraju Naravno da je provjera i povratna informacija s takvih pozicija moguća ali obično zahtijeva dodatno vrijeme i novac što se nastoji izbjeći i s aspekta korisnika i s aspekta dobavljača U ranijim rješenjima je ovo bio trenutak kad se donosila odluka o kupnji ili vlastitoj izgradnji informacijskih

sustava formiranju računskih centara i ekipa zaduženih za pojedine poslove i aktivnosti U današnjim okolnostima s proklamiranjem SOA rješenja i Cloud Computinga takve dileme ne postoje Naravno pod uvjetom da poslovni sustav prihvati takav način izgradnje informacijskog sustava Premda

metodologije izgradnje pa posljedično i promjena u strukturi informacijskih sustava na taj način mogu biti znanstveno upitne i teško provjerljive posjeduju odreĎena empirijska svojstva Svaki ozbiljniji proizvoĎač softvera svakom novom instalacijom stječe iskustvo koje može biti sistematizirano i može

biti osnova za definiranje metodološkog okvira Ukoliko pri tome slijede odreĎene znanstvene stavove ta osnova može biti pouzdana kod definiranja metodologija koje time imaju znanstveni karakter Slijedeća bitna činjenica u izgradnji i promjenama unutar informacijskog sustava je projektni pristup i

timska realizacija projekta Izgradnja je proces i sačinjena je od niza aktivnosti koje zahtijevaju i

Operativne aktivnosti

wrapping

Revolucija sustava Evolucija sustava

(-) Utjecaj na sustav (+)

Broj promjena

u naslijeđu

održavanje migracija daljnji razvoj

planiranje i kontrolu pri realizaciji ali i okupiraju odreĎene resurse u prvom redu meĎu korisnicima koji

dolaze iz poslovnog okruženja Svaki integralni oblik informacijskog sustava unutra nekog poslovnog sustava je skup automatiziranih procesa obrada informacija koje dolazeodlaze izu različitih poslovnih aktivnosti To nužno podrazumijeva tim sastavljen od pojedinaca različitih profila i različitih znanja i

mogućnosti Podrazumijevano je uspjeh realizacije vezan za timsku sposobnost a ova je zavisna od sposobnosti svakog člana pojedinačno Stoga se u ozbiljnijoj literaturi koja tretira ovakvu problematika kao osnovni uvjet postavlja postojanje paradigme koju prihvaća i primjenjuje tim koji realizira projekt

Kroz kratku povijest razvoja računala i računalnih aplikacija ndash softvera ndash upravo je paradigma bila presudna za promjene u poimanjima i pristupu izgradnji ili modifikaciji informacijskog sustava

Pojmovna nedefiniranosti ili namjerna pojmovna zbrka U svrhu ovog razmatranja se potrebno odrediti prema nekim osnovnim pojmovima u okviru

informacijskih znanosti To su

Informacijski sustav

Korisnik

Paradigma

Struktura informacijskog sustava

Arhitektura informacijskog sustava Vjerojatno broj definicija informacijskog sustava skoro bijekcijski korespondira broju objavljenih radova

vezanih za ovu problematiku Stoga je već u početku mogućnost neprikladne definicije problem koji može inicirati kasnije veće i teže probleme Definicija informacijskog sustava najčešće uključuje pragmatičku stranu i ukazuje na korisne aspekte informacijskog sustava kao po javnosti Pojmovno ali

i djelatno informacijski sustav jest sveukupno područje informacijske djelatnosti koje tvori organiziranu cjelinu sustav (TuĎman at al 2012) Djelatno je svaki informacijski sustav odreĎen nizom aktivnosti koje uključuju prikupljanje sortiranje obradu pa opet eventualno sortiranje spremanje i čuvanje te

dijeljenje prema korisnicima kojima su namijenjene Očigledno je vezivanje definicije za korisnika što nužno zahtijeva definiciju tog nezaobilaznog činitelja Povijesno pojam korisnika u informacijskom sustavu je konstanta kojoj se u raznim fazama razvoja informacijskih sustava pridjeljuje različit simbo l

oznaka i naziv Obzirom na temeljno značenje korisnika u životu informacijskog svako nijansiranje bilo u značenju bilo u označavanju predstavlja problem na bilo koji način Ako se informacijski sustav svede na okvire aplikativnog softvera koji podržava informacijske procese

u nekom poslovnom sustavu tada se s pravom postavlja pitanje nedvosmislenosti kod definiranja korisnika informacijskog sustava U takvim okvirima postoje dvije vrste korisnika korisnik usluga informacijskog sustava ili uživalac beneficija i produkata informacijskih procesa koji se odvijaju u

takvom sustavu ali i aktivni djelatnik zadužen za nesmetanu i valjanu funkcionalnost tog i takvog sustava Potonji se može prepoznati u različitim ulogama i zaduženjima koja se grupiraju u informatičke djelatnosti dakle informatičar na ovaj ili onaj način

Osim precizne definicije sustava i korisnika koji su rudiment i osnovna pokretačka os informaci jskog sustav nužno je precizno odreĎenje i pojma paradigma Naime svaka pojavnost ima fizičku komponentu realiziranu na odreĎeni način Premda je uz pojam informacija i informacijski sustav

najčešće vezano (ili grublje prikačeno) i puno pojmova koji se proglašavaju na bilo koji način najčešće olako virtualnima potreba za njihovom povremenom fizičkom realizacijom je dodatni osjetljivi moment u realizaciji i funkciji informacijskog sustava Kad se nešto u takvom okruženju može smatrati

virtualnim nije pitanje realizacije koliko sveukupnog poimanja potreba Takva potreba može biti konstanta jednako kao i izolirana elementarna situacija u funkcioniranju sustava u cijelosti Paradigma je u razvoju dijela informacijskih znanosti od izuzetne važnosti iz više razloga Ako se

pogleda definicija paradigme u smisli kako je definirana (Kuhn 1996) da se ne ide do starogrčkih filozofa bit će očito da je za njezinu realizaciju ili provedbu nužno propitivanje stavova svih učesnika u razvoju informacijskih sustava

Logično je da realizacija projekta ovisi u prvom redu od nositelja realizacije Tako realizacija informacijskog sustava kao softverskog rješenja ili u cjelini zavisi od nositelja aktivnosti MeĎutim u realizaciji bilo kakvog rješenja učestvuje tim a ne pojedinac pa je uspjeh projekta zavisan ne od stava

i aktivnosti pojedinca nego od ukupnog stava i ukupne aktivnosti tima UsklaĎenost stavova i mišljenja je nužna da bi se mogla definirati politika ili pristup tima konkretnom poslu Iz pristupa nužno proizlazi dinamika kao najvažniji element realizacije projekta

Zašto inzistirati na pojmovnom čistunstvu Ako se zna da samo 20 informacijskih sustava u svijetu pokazuje učinkovitost da 40 ostvaruje marginalnu dobit a preostalih 40 predstavlja promašaj onda vjerojatno dio neuspjeha jest u rudimentu cijele priče Čisto deduktivno ako se svi članovi tima

uključujući korisnike (benefita) ne razumiju ili ne govore istim jezikom neuspjeh je sasvim izvjestan

Osnovi je cilj ovog rada pokazati kroz povijesne promjene terminologije metodologije i primjenjivih

tehnika razvoja u informacijskim znanostima kako je pojmovna neodreĎenost i zbrka osnovni razlog svih neuspjeha koji su najbolje objedinjeni u Solow-ljevu paradoksu

2 a odražavaju gore navedeni

raster

Prije kratkog pregleda bdquopovijesnih― promjena u navedenim područjima nužno je napomenuti i definirati pojmove strukture informacijskih sustava i arhitekture informacijskih sustava to više što su ova dva pojma usko vezana za paradigmu (pristup realizaciji informacijskog sustava) i odreĎuju osnovne

postavke i razvoja i implementacije aplikativnih rješenja kao osnovne podrške informacijskim procesima Kako će biti kasnije pokazano pomicanje težišta osnovnog problema izgradnje informacijskog sustava od strukture prema arhitekturi izazvat će bdquopotrese― koje sveukupno okruženje

često teško a ponekad nikako ne amortizira Po pojmom strukture informacijskog sustava podrazumijevamo unutrašnji raspored elemenata koji ga čine njihov sastav poredak i sveukupne odnose u informacijskom sustavu(TuĎman at al 2012)

Činitelji strukture su informacijski subjekti informacijska kultura oprema tehnološka osnovica (uključujući softver) i okruženje u kojem se informacijski sustav realizira Opis strukture implicitno pokazuje ono što čini sustav konfiguraciju elemenata način kao su povezani ili kako meĎusobno

suraĎuju te da li postoji strukturna organiziranost u smislu hijerarhije ili slično Nakon jedne od izmjena paradigme u izgradnji informacijskih sustava se počelo govoriti o arhitekturi informacijskih sustava Premda su pojmovi struktura i arhitektura u većini odrednica bliski razlika je u

ovom području od bitne važnosti Ako se arhitekturu promatra kao stil i način projektiranja neke pojavnosti onda je jasno da se mora nužno odvojiti od pojma strukture Naime ista arhitektura može biti način realizacije različitih struktura U trenutku kad se u organizaciji informacijskih sustava počine

preferirati pojam arhitekture struktura se počinje gurati u drugi plan i postavljati u nadležnost korisnika koji nužno ne moraju poznavati procese metode i metodologije izgradnje informacijskog sustava Iz tih okvira izvire jedan novi Solow koji zahtjeva ponovno propitivanje odnosa svih učesnika u izgradnji

informacijskog sustava Kako i zašto slijedi u nastavku Od monolita do CC i dalje hellip

Praktična i smislena uporaba računala uključuje odreĎenu programsku podršku koja podrazumijeva postojanje podataka Podatci se obraĎuju u skladu s tom podrškom a prema algoritmima koje sadrže

aplikativni programi Realizacija obrade se ostvaruje kroz odreĎeni oblik komunikacije korisnik ndash računalo Kad su korisnik računalo i podatci na istom mjestu govori se o monolitnim aplikacijama (slika 1) Premda se ovakav oblik aplikacija smatra početcima računalne podrške

monolitne aplikacije nisu čista povijest jer i danas specifični sustavi mogu zahtijevati ovakvo rješenje Najčešće su to aplikacije specifične namjene pa su i korisnici specijalizirani i specifični Monolitnost pretpostavlja koegzistiranje sustava i korisnika u istom okruženju najčešće bez česte potrebe za

komunikacijom s okolinom Monolitnost za posljedicu ima čvrstu strukturu pa time i arhitekturu sustava Još je jedno svojstvo monolitnih aplikacija izraženo a to je visoka rutiniranost u obradi podataka

(BatiniampScannapieca 2006) definiraju prostor u kojem su smješteni svi informacijski sustavi prema

svojoj strukturi i arhitekturi Prostor je odreĎen koordinatama potpunost (totally ) heterogenost (heterogeneity) i distribuiranost (distribution)

Uvažavajući ova tri svojstva po mjerivom intenzitetu monolitni su sustavi postavljeni u ishodište koordinatnog sustava Dakle klasificirani su kao

homogeni nisu distribuirani i specijalizirani su U dijagonalnoj točki prostora autori smještaju tzv P2P informacijske sustave Sustavi tipa peer_to_peer se

deklariraju kao autonomni i nezavisni od računala

poslužitelja odnosno sve tri komponente imaju maksimalan intenzitet Prema strukturi se ovakvi

2 Više tehnologije u školi može imat i štetan utjecaj na obrazovanje a računala kod kuće mogu naškoditi učenju

ili bdquoMožete osjetiti eru računala posvuda ovih dana osim u statistici produktivnosti su izjave nobelovca

Roberta Solow doduše izrečene 1987 godine Pokušaj rev izije stava Arnold King tvrdnjom da se to promijenilo i

da možda vrijed i za Evropu ko ja drugačije koristi računala od USA

Slika 2 Monolitna aplikacija (izvor httprubyonrailslinkblogspotcom201009single-tier-architecturehtml 10 Travnja 2012

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 3: ERP vs. SOA ili Cloud Computing

proizvoda je obično potpomognuta značajnim referencama ali ne garantira izostanak neuspjeha ili

znatno produženje vremena implementacije Jednako tako je danas skoro nezamisliv poslovni sustav koji nema poslovne i informacijske procese potpomognute računalima i računalnim rješenjima Na taj su način i životni ciklusi oba sustava

informacijskog i poslovnog u sinergijskoj vezi Pače dijele istu sudbinu ndash promjene i modifikacije jednog nužno zahtijevaju promjene i modifikacije drugog Modificiranje informacijskog sustava u skladu s potrebama poslovnog sustava kontinuirani je proces

koji količinom potrebnih aktivnosti varira s mogućnošću dosezanja kritiče mase nakon čega je nužna jedna od tri mogućnosti migracija integracija ili alternacija Teorijski je moguće da tijekom životnog ciklusa informacijskog sustava do potrebe za migracijom ne mora doći Druga je krajnost potreba za

više migracija tijekom životnog ciklusa Dodatni je problem nužnost uvažavanja specifičnosti informacijskih sustava pri pojedinim slučajevima migracije koju svaki od realnih slučajeva čine zasebnim fenomenom Standardizacija metodološkog okvira je tada moguća samo na vrlo visokom

stupnju apstrakcije Nužna je i konkretizacija zahtijeva uvažavanje specifičnosti tijekom migracije i prilagoĎavanje okolnostima bdquou hodu― što lako dovodi do neželjenih okolnosti i neodgovarajućih rezultata U ovakvim se okolnostima informacijski sustav može promatrati kao pojavnost unutar koje

se dešavaju promjene koje mogu imati uvjetno rečeno evolucijski ili revolucijski karakter Uvjetno zbog činjenice da je vrijeme u životu informacijskog sustava kad je vezan za tehničko -tehnološke promjene vrlo relativan činilac Brzina promjena na tom području sve promjene u informacijskom

sustavu čini revolucionarnima ali način odvijanja i slijedna povezanost ima evolutivni karakter (vidi sliku 1)

Slika 1 Operativne aktivnosti kao pokazatelj intenziteta promjena (Bisbal et al 1997)

I kod migracije je problem kojeg se često zanemaruje namjerni ili nenamjerni naglašeni tretman tehničke komponente Posebno kad je jedan od razloga modificiranja moderniziranje u području hardvera Ovakve se situacije očituju u prepuštanju izbora metodologije migracije proizvoĎaču ili

dobavljaču softvera bez prethodne adekvatne provjere njezine kvalitete Pogotovo je to slučaj kad proizvoĎač softvera preferira odreĎena tehnička rješenja u području hardvera ProizvoĎač obično nudi kao dokaz o kvaliteti reference na lokacije i sustave u kojima su primijenjena rješenja koja nudi i

gdje funkcioniraju Naravno da je provjera i povratna informacija s takvih pozicija moguća ali obično zahtijeva dodatno vrijeme i novac što se nastoji izbjeći i s aspekta korisnika i s aspekta dobavljača U ranijim rješenjima je ovo bio trenutak kad se donosila odluka o kupnji ili vlastitoj izgradnji informacijskih

sustava formiranju računskih centara i ekipa zaduženih za pojedine poslove i aktivnosti U današnjim okolnostima s proklamiranjem SOA rješenja i Cloud Computinga takve dileme ne postoje Naravno pod uvjetom da poslovni sustav prihvati takav način izgradnje informacijskog sustava Premda

metodologije izgradnje pa posljedično i promjena u strukturi informacijskih sustava na taj način mogu biti znanstveno upitne i teško provjerljive posjeduju odreĎena empirijska svojstva Svaki ozbiljniji proizvoĎač softvera svakom novom instalacijom stječe iskustvo koje može biti sistematizirano i može

biti osnova za definiranje metodološkog okvira Ukoliko pri tome slijede odreĎene znanstvene stavove ta osnova može biti pouzdana kod definiranja metodologija koje time imaju znanstveni karakter Slijedeća bitna činjenica u izgradnji i promjenama unutar informacijskog sustava je projektni pristup i

timska realizacija projekta Izgradnja je proces i sačinjena je od niza aktivnosti koje zahtijevaju i

Operativne aktivnosti

wrapping

Revolucija sustava Evolucija sustava

(-) Utjecaj na sustav (+)

Broj promjena

u naslijeđu

održavanje migracija daljnji razvoj

planiranje i kontrolu pri realizaciji ali i okupiraju odreĎene resurse u prvom redu meĎu korisnicima koji

dolaze iz poslovnog okruženja Svaki integralni oblik informacijskog sustava unutra nekog poslovnog sustava je skup automatiziranih procesa obrada informacija koje dolazeodlaze izu različitih poslovnih aktivnosti To nužno podrazumijeva tim sastavljen od pojedinaca različitih profila i različitih znanja i

mogućnosti Podrazumijevano je uspjeh realizacije vezan za timsku sposobnost a ova je zavisna od sposobnosti svakog člana pojedinačno Stoga se u ozbiljnijoj literaturi koja tretira ovakvu problematika kao osnovni uvjet postavlja postojanje paradigme koju prihvaća i primjenjuje tim koji realizira projekt

Kroz kratku povijest razvoja računala i računalnih aplikacija ndash softvera ndash upravo je paradigma bila presudna za promjene u poimanjima i pristupu izgradnji ili modifikaciji informacijskog sustava

Pojmovna nedefiniranosti ili namjerna pojmovna zbrka U svrhu ovog razmatranja se potrebno odrediti prema nekim osnovnim pojmovima u okviru

informacijskih znanosti To su

Informacijski sustav

Korisnik

Paradigma

Struktura informacijskog sustava

Arhitektura informacijskog sustava Vjerojatno broj definicija informacijskog sustava skoro bijekcijski korespondira broju objavljenih radova

vezanih za ovu problematiku Stoga je već u početku mogućnost neprikladne definicije problem koji može inicirati kasnije veće i teže probleme Definicija informacijskog sustava najčešće uključuje pragmatičku stranu i ukazuje na korisne aspekte informacijskog sustava kao po javnosti Pojmovno ali

i djelatno informacijski sustav jest sveukupno područje informacijske djelatnosti koje tvori organiziranu cjelinu sustav (TuĎman at al 2012) Djelatno je svaki informacijski sustav odreĎen nizom aktivnosti koje uključuju prikupljanje sortiranje obradu pa opet eventualno sortiranje spremanje i čuvanje te

dijeljenje prema korisnicima kojima su namijenjene Očigledno je vezivanje definicije za korisnika što nužno zahtijeva definiciju tog nezaobilaznog činitelja Povijesno pojam korisnika u informacijskom sustavu je konstanta kojoj se u raznim fazama razvoja informacijskih sustava pridjeljuje različit simbo l

oznaka i naziv Obzirom na temeljno značenje korisnika u životu informacijskog svako nijansiranje bilo u značenju bilo u označavanju predstavlja problem na bilo koji način Ako se informacijski sustav svede na okvire aplikativnog softvera koji podržava informacijske procese

u nekom poslovnom sustavu tada se s pravom postavlja pitanje nedvosmislenosti kod definiranja korisnika informacijskog sustava U takvim okvirima postoje dvije vrste korisnika korisnik usluga informacijskog sustava ili uživalac beneficija i produkata informacijskih procesa koji se odvijaju u

takvom sustavu ali i aktivni djelatnik zadužen za nesmetanu i valjanu funkcionalnost tog i takvog sustava Potonji se može prepoznati u različitim ulogama i zaduženjima koja se grupiraju u informatičke djelatnosti dakle informatičar na ovaj ili onaj način

Osim precizne definicije sustava i korisnika koji su rudiment i osnovna pokretačka os informaci jskog sustav nužno je precizno odreĎenje i pojma paradigma Naime svaka pojavnost ima fizičku komponentu realiziranu na odreĎeni način Premda je uz pojam informacija i informacijski sustav

najčešće vezano (ili grublje prikačeno) i puno pojmova koji se proglašavaju na bilo koji način najčešće olako virtualnima potreba za njihovom povremenom fizičkom realizacijom je dodatni osjetljivi moment u realizaciji i funkciji informacijskog sustava Kad se nešto u takvom okruženju može smatrati

virtualnim nije pitanje realizacije koliko sveukupnog poimanja potreba Takva potreba može biti konstanta jednako kao i izolirana elementarna situacija u funkcioniranju sustava u cijelosti Paradigma je u razvoju dijela informacijskih znanosti od izuzetne važnosti iz više razloga Ako se

pogleda definicija paradigme u smisli kako je definirana (Kuhn 1996) da se ne ide do starogrčkih filozofa bit će očito da je za njezinu realizaciju ili provedbu nužno propitivanje stavova svih učesnika u razvoju informacijskih sustava

Logično je da realizacija projekta ovisi u prvom redu od nositelja realizacije Tako realizacija informacijskog sustava kao softverskog rješenja ili u cjelini zavisi od nositelja aktivnosti MeĎutim u realizaciji bilo kakvog rješenja učestvuje tim a ne pojedinac pa je uspjeh projekta zavisan ne od stava

i aktivnosti pojedinca nego od ukupnog stava i ukupne aktivnosti tima UsklaĎenost stavova i mišljenja je nužna da bi se mogla definirati politika ili pristup tima konkretnom poslu Iz pristupa nužno proizlazi dinamika kao najvažniji element realizacije projekta

Zašto inzistirati na pojmovnom čistunstvu Ako se zna da samo 20 informacijskih sustava u svijetu pokazuje učinkovitost da 40 ostvaruje marginalnu dobit a preostalih 40 predstavlja promašaj onda vjerojatno dio neuspjeha jest u rudimentu cijele priče Čisto deduktivno ako se svi članovi tima

uključujući korisnike (benefita) ne razumiju ili ne govore istim jezikom neuspjeh je sasvim izvjestan

Osnovi je cilj ovog rada pokazati kroz povijesne promjene terminologije metodologije i primjenjivih

tehnika razvoja u informacijskim znanostima kako je pojmovna neodreĎenost i zbrka osnovni razlog svih neuspjeha koji su najbolje objedinjeni u Solow-ljevu paradoksu

2 a odražavaju gore navedeni

raster

Prije kratkog pregleda bdquopovijesnih― promjena u navedenim područjima nužno je napomenuti i definirati pojmove strukture informacijskih sustava i arhitekture informacijskih sustava to više što su ova dva pojma usko vezana za paradigmu (pristup realizaciji informacijskog sustava) i odreĎuju osnovne

postavke i razvoja i implementacije aplikativnih rješenja kao osnovne podrške informacijskim procesima Kako će biti kasnije pokazano pomicanje težišta osnovnog problema izgradnje informacijskog sustava od strukture prema arhitekturi izazvat će bdquopotrese― koje sveukupno okruženje

često teško a ponekad nikako ne amortizira Po pojmom strukture informacijskog sustava podrazumijevamo unutrašnji raspored elemenata koji ga čine njihov sastav poredak i sveukupne odnose u informacijskom sustavu(TuĎman at al 2012)

Činitelji strukture su informacijski subjekti informacijska kultura oprema tehnološka osnovica (uključujući softver) i okruženje u kojem se informacijski sustav realizira Opis strukture implicitno pokazuje ono što čini sustav konfiguraciju elemenata način kao su povezani ili kako meĎusobno

suraĎuju te da li postoji strukturna organiziranost u smislu hijerarhije ili slično Nakon jedne od izmjena paradigme u izgradnji informacijskih sustava se počelo govoriti o arhitekturi informacijskih sustava Premda su pojmovi struktura i arhitektura u većini odrednica bliski razlika je u

ovom području od bitne važnosti Ako se arhitekturu promatra kao stil i način projektiranja neke pojavnosti onda je jasno da se mora nužno odvojiti od pojma strukture Naime ista arhitektura može biti način realizacije različitih struktura U trenutku kad se u organizaciji informacijskih sustava počine

preferirati pojam arhitekture struktura se počinje gurati u drugi plan i postavljati u nadležnost korisnika koji nužno ne moraju poznavati procese metode i metodologije izgradnje informacijskog sustava Iz tih okvira izvire jedan novi Solow koji zahtjeva ponovno propitivanje odnosa svih učesnika u izgradnji

informacijskog sustava Kako i zašto slijedi u nastavku Od monolita do CC i dalje hellip

Praktična i smislena uporaba računala uključuje odreĎenu programsku podršku koja podrazumijeva postojanje podataka Podatci se obraĎuju u skladu s tom podrškom a prema algoritmima koje sadrže

aplikativni programi Realizacija obrade se ostvaruje kroz odreĎeni oblik komunikacije korisnik ndash računalo Kad su korisnik računalo i podatci na istom mjestu govori se o monolitnim aplikacijama (slika 1) Premda se ovakav oblik aplikacija smatra početcima računalne podrške

monolitne aplikacije nisu čista povijest jer i danas specifični sustavi mogu zahtijevati ovakvo rješenje Najčešće su to aplikacije specifične namjene pa su i korisnici specijalizirani i specifični Monolitnost pretpostavlja koegzistiranje sustava i korisnika u istom okruženju najčešće bez česte potrebe za

komunikacijom s okolinom Monolitnost za posljedicu ima čvrstu strukturu pa time i arhitekturu sustava Još je jedno svojstvo monolitnih aplikacija izraženo a to je visoka rutiniranost u obradi podataka

(BatiniampScannapieca 2006) definiraju prostor u kojem su smješteni svi informacijski sustavi prema

svojoj strukturi i arhitekturi Prostor je odreĎen koordinatama potpunost (totally ) heterogenost (heterogeneity) i distribuiranost (distribution)

Uvažavajući ova tri svojstva po mjerivom intenzitetu monolitni su sustavi postavljeni u ishodište koordinatnog sustava Dakle klasificirani su kao

homogeni nisu distribuirani i specijalizirani su U dijagonalnoj točki prostora autori smještaju tzv P2P informacijske sustave Sustavi tipa peer_to_peer se

deklariraju kao autonomni i nezavisni od računala

poslužitelja odnosno sve tri komponente imaju maksimalan intenzitet Prema strukturi se ovakvi

2 Više tehnologije u školi može imat i štetan utjecaj na obrazovanje a računala kod kuće mogu naškoditi učenju

ili bdquoMožete osjetiti eru računala posvuda ovih dana osim u statistici produktivnosti su izjave nobelovca

Roberta Solow doduše izrečene 1987 godine Pokušaj rev izije stava Arnold King tvrdnjom da se to promijenilo i

da možda vrijed i za Evropu ko ja drugačije koristi računala od USA

Slika 2 Monolitna aplikacija (izvor httprubyonrailslinkblogspotcom201009single-tier-architecturehtml 10 Travnja 2012

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 4: ERP vs. SOA ili Cloud Computing

planiranje i kontrolu pri realizaciji ali i okupiraju odreĎene resurse u prvom redu meĎu korisnicima koji

dolaze iz poslovnog okruženja Svaki integralni oblik informacijskog sustava unutra nekog poslovnog sustava je skup automatiziranih procesa obrada informacija koje dolazeodlaze izu različitih poslovnih aktivnosti To nužno podrazumijeva tim sastavljen od pojedinaca različitih profila i različitih znanja i

mogućnosti Podrazumijevano je uspjeh realizacije vezan za timsku sposobnost a ova je zavisna od sposobnosti svakog člana pojedinačno Stoga se u ozbiljnijoj literaturi koja tretira ovakvu problematika kao osnovni uvjet postavlja postojanje paradigme koju prihvaća i primjenjuje tim koji realizira projekt

Kroz kratku povijest razvoja računala i računalnih aplikacija ndash softvera ndash upravo je paradigma bila presudna za promjene u poimanjima i pristupu izgradnji ili modifikaciji informacijskog sustava

Pojmovna nedefiniranosti ili namjerna pojmovna zbrka U svrhu ovog razmatranja se potrebno odrediti prema nekim osnovnim pojmovima u okviru

informacijskih znanosti To su

Informacijski sustav

Korisnik

Paradigma

Struktura informacijskog sustava

Arhitektura informacijskog sustava Vjerojatno broj definicija informacijskog sustava skoro bijekcijski korespondira broju objavljenih radova

vezanih za ovu problematiku Stoga je već u početku mogućnost neprikladne definicije problem koji može inicirati kasnije veće i teže probleme Definicija informacijskog sustava najčešće uključuje pragmatičku stranu i ukazuje na korisne aspekte informacijskog sustava kao po javnosti Pojmovno ali

i djelatno informacijski sustav jest sveukupno područje informacijske djelatnosti koje tvori organiziranu cjelinu sustav (TuĎman at al 2012) Djelatno je svaki informacijski sustav odreĎen nizom aktivnosti koje uključuju prikupljanje sortiranje obradu pa opet eventualno sortiranje spremanje i čuvanje te

dijeljenje prema korisnicima kojima su namijenjene Očigledno je vezivanje definicije za korisnika što nužno zahtijeva definiciju tog nezaobilaznog činitelja Povijesno pojam korisnika u informacijskom sustavu je konstanta kojoj se u raznim fazama razvoja informacijskih sustava pridjeljuje različit simbo l

oznaka i naziv Obzirom na temeljno značenje korisnika u životu informacijskog svako nijansiranje bilo u značenju bilo u označavanju predstavlja problem na bilo koji način Ako se informacijski sustav svede na okvire aplikativnog softvera koji podržava informacijske procese

u nekom poslovnom sustavu tada se s pravom postavlja pitanje nedvosmislenosti kod definiranja korisnika informacijskog sustava U takvim okvirima postoje dvije vrste korisnika korisnik usluga informacijskog sustava ili uživalac beneficija i produkata informacijskih procesa koji se odvijaju u

takvom sustavu ali i aktivni djelatnik zadužen za nesmetanu i valjanu funkcionalnost tog i takvog sustava Potonji se može prepoznati u različitim ulogama i zaduženjima koja se grupiraju u informatičke djelatnosti dakle informatičar na ovaj ili onaj način

Osim precizne definicije sustava i korisnika koji su rudiment i osnovna pokretačka os informaci jskog sustav nužno je precizno odreĎenje i pojma paradigma Naime svaka pojavnost ima fizičku komponentu realiziranu na odreĎeni način Premda je uz pojam informacija i informacijski sustav

najčešće vezano (ili grublje prikačeno) i puno pojmova koji se proglašavaju na bilo koji način najčešće olako virtualnima potreba za njihovom povremenom fizičkom realizacijom je dodatni osjetljivi moment u realizaciji i funkciji informacijskog sustava Kad se nešto u takvom okruženju može smatrati

virtualnim nije pitanje realizacije koliko sveukupnog poimanja potreba Takva potreba može biti konstanta jednako kao i izolirana elementarna situacija u funkcioniranju sustava u cijelosti Paradigma je u razvoju dijela informacijskih znanosti od izuzetne važnosti iz više razloga Ako se

pogleda definicija paradigme u smisli kako je definirana (Kuhn 1996) da se ne ide do starogrčkih filozofa bit će očito da je za njezinu realizaciju ili provedbu nužno propitivanje stavova svih učesnika u razvoju informacijskih sustava

Logično je da realizacija projekta ovisi u prvom redu od nositelja realizacije Tako realizacija informacijskog sustava kao softverskog rješenja ili u cjelini zavisi od nositelja aktivnosti MeĎutim u realizaciji bilo kakvog rješenja učestvuje tim a ne pojedinac pa je uspjeh projekta zavisan ne od stava

i aktivnosti pojedinca nego od ukupnog stava i ukupne aktivnosti tima UsklaĎenost stavova i mišljenja je nužna da bi se mogla definirati politika ili pristup tima konkretnom poslu Iz pristupa nužno proizlazi dinamika kao najvažniji element realizacije projekta

Zašto inzistirati na pojmovnom čistunstvu Ako se zna da samo 20 informacijskih sustava u svijetu pokazuje učinkovitost da 40 ostvaruje marginalnu dobit a preostalih 40 predstavlja promašaj onda vjerojatno dio neuspjeha jest u rudimentu cijele priče Čisto deduktivno ako se svi članovi tima

uključujući korisnike (benefita) ne razumiju ili ne govore istim jezikom neuspjeh je sasvim izvjestan

Osnovi je cilj ovog rada pokazati kroz povijesne promjene terminologije metodologije i primjenjivih

tehnika razvoja u informacijskim znanostima kako je pojmovna neodreĎenost i zbrka osnovni razlog svih neuspjeha koji su najbolje objedinjeni u Solow-ljevu paradoksu

2 a odražavaju gore navedeni

raster

Prije kratkog pregleda bdquopovijesnih― promjena u navedenim područjima nužno je napomenuti i definirati pojmove strukture informacijskih sustava i arhitekture informacijskih sustava to više što su ova dva pojma usko vezana za paradigmu (pristup realizaciji informacijskog sustava) i odreĎuju osnovne

postavke i razvoja i implementacije aplikativnih rješenja kao osnovne podrške informacijskim procesima Kako će biti kasnije pokazano pomicanje težišta osnovnog problema izgradnje informacijskog sustava od strukture prema arhitekturi izazvat će bdquopotrese― koje sveukupno okruženje

često teško a ponekad nikako ne amortizira Po pojmom strukture informacijskog sustava podrazumijevamo unutrašnji raspored elemenata koji ga čine njihov sastav poredak i sveukupne odnose u informacijskom sustavu(TuĎman at al 2012)

Činitelji strukture su informacijski subjekti informacijska kultura oprema tehnološka osnovica (uključujući softver) i okruženje u kojem se informacijski sustav realizira Opis strukture implicitno pokazuje ono što čini sustav konfiguraciju elemenata način kao su povezani ili kako meĎusobno

suraĎuju te da li postoji strukturna organiziranost u smislu hijerarhije ili slično Nakon jedne od izmjena paradigme u izgradnji informacijskih sustava se počelo govoriti o arhitekturi informacijskih sustava Premda su pojmovi struktura i arhitektura u većini odrednica bliski razlika je u

ovom području od bitne važnosti Ako se arhitekturu promatra kao stil i način projektiranja neke pojavnosti onda je jasno da se mora nužno odvojiti od pojma strukture Naime ista arhitektura može biti način realizacije različitih struktura U trenutku kad se u organizaciji informacijskih sustava počine

preferirati pojam arhitekture struktura se počinje gurati u drugi plan i postavljati u nadležnost korisnika koji nužno ne moraju poznavati procese metode i metodologije izgradnje informacijskog sustava Iz tih okvira izvire jedan novi Solow koji zahtjeva ponovno propitivanje odnosa svih učesnika u izgradnji

informacijskog sustava Kako i zašto slijedi u nastavku Od monolita do CC i dalje hellip

Praktična i smislena uporaba računala uključuje odreĎenu programsku podršku koja podrazumijeva postojanje podataka Podatci se obraĎuju u skladu s tom podrškom a prema algoritmima koje sadrže

aplikativni programi Realizacija obrade se ostvaruje kroz odreĎeni oblik komunikacije korisnik ndash računalo Kad su korisnik računalo i podatci na istom mjestu govori se o monolitnim aplikacijama (slika 1) Premda se ovakav oblik aplikacija smatra početcima računalne podrške

monolitne aplikacije nisu čista povijest jer i danas specifični sustavi mogu zahtijevati ovakvo rješenje Najčešće su to aplikacije specifične namjene pa su i korisnici specijalizirani i specifični Monolitnost pretpostavlja koegzistiranje sustava i korisnika u istom okruženju najčešće bez česte potrebe za

komunikacijom s okolinom Monolitnost za posljedicu ima čvrstu strukturu pa time i arhitekturu sustava Još je jedno svojstvo monolitnih aplikacija izraženo a to je visoka rutiniranost u obradi podataka

(BatiniampScannapieca 2006) definiraju prostor u kojem su smješteni svi informacijski sustavi prema

svojoj strukturi i arhitekturi Prostor je odreĎen koordinatama potpunost (totally ) heterogenost (heterogeneity) i distribuiranost (distribution)

Uvažavajući ova tri svojstva po mjerivom intenzitetu monolitni su sustavi postavljeni u ishodište koordinatnog sustava Dakle klasificirani su kao

homogeni nisu distribuirani i specijalizirani su U dijagonalnoj točki prostora autori smještaju tzv P2P informacijske sustave Sustavi tipa peer_to_peer se

deklariraju kao autonomni i nezavisni od računala

poslužitelja odnosno sve tri komponente imaju maksimalan intenzitet Prema strukturi se ovakvi

2 Više tehnologije u školi može imat i štetan utjecaj na obrazovanje a računala kod kuće mogu naškoditi učenju

ili bdquoMožete osjetiti eru računala posvuda ovih dana osim u statistici produktivnosti su izjave nobelovca

Roberta Solow doduše izrečene 1987 godine Pokušaj rev izije stava Arnold King tvrdnjom da se to promijenilo i

da možda vrijed i za Evropu ko ja drugačije koristi računala od USA

Slika 2 Monolitna aplikacija (izvor httprubyonrailslinkblogspotcom201009single-tier-architecturehtml 10 Travnja 2012

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 5: ERP vs. SOA ili Cloud Computing

Osnovi je cilj ovog rada pokazati kroz povijesne promjene terminologije metodologije i primjenjivih

tehnika razvoja u informacijskim znanostima kako je pojmovna neodreĎenost i zbrka osnovni razlog svih neuspjeha koji su najbolje objedinjeni u Solow-ljevu paradoksu

2 a odražavaju gore navedeni

raster

Prije kratkog pregleda bdquopovijesnih― promjena u navedenim područjima nužno je napomenuti i definirati pojmove strukture informacijskih sustava i arhitekture informacijskih sustava to više što su ova dva pojma usko vezana za paradigmu (pristup realizaciji informacijskog sustava) i odreĎuju osnovne

postavke i razvoja i implementacije aplikativnih rješenja kao osnovne podrške informacijskim procesima Kako će biti kasnije pokazano pomicanje težišta osnovnog problema izgradnje informacijskog sustava od strukture prema arhitekturi izazvat će bdquopotrese― koje sveukupno okruženje

često teško a ponekad nikako ne amortizira Po pojmom strukture informacijskog sustava podrazumijevamo unutrašnji raspored elemenata koji ga čine njihov sastav poredak i sveukupne odnose u informacijskom sustavu(TuĎman at al 2012)

Činitelji strukture su informacijski subjekti informacijska kultura oprema tehnološka osnovica (uključujući softver) i okruženje u kojem se informacijski sustav realizira Opis strukture implicitno pokazuje ono što čini sustav konfiguraciju elemenata način kao su povezani ili kako meĎusobno

suraĎuju te da li postoji strukturna organiziranost u smislu hijerarhije ili slično Nakon jedne od izmjena paradigme u izgradnji informacijskih sustava se počelo govoriti o arhitekturi informacijskih sustava Premda su pojmovi struktura i arhitektura u većini odrednica bliski razlika je u

ovom području od bitne važnosti Ako se arhitekturu promatra kao stil i način projektiranja neke pojavnosti onda je jasno da se mora nužno odvojiti od pojma strukture Naime ista arhitektura može biti način realizacije različitih struktura U trenutku kad se u organizaciji informacijskih sustava počine

preferirati pojam arhitekture struktura se počinje gurati u drugi plan i postavljati u nadležnost korisnika koji nužno ne moraju poznavati procese metode i metodologije izgradnje informacijskog sustava Iz tih okvira izvire jedan novi Solow koji zahtjeva ponovno propitivanje odnosa svih učesnika u izgradnji

informacijskog sustava Kako i zašto slijedi u nastavku Od monolita do CC i dalje hellip

Praktična i smislena uporaba računala uključuje odreĎenu programsku podršku koja podrazumijeva postojanje podataka Podatci se obraĎuju u skladu s tom podrškom a prema algoritmima koje sadrže

aplikativni programi Realizacija obrade se ostvaruje kroz odreĎeni oblik komunikacije korisnik ndash računalo Kad su korisnik računalo i podatci na istom mjestu govori se o monolitnim aplikacijama (slika 1) Premda se ovakav oblik aplikacija smatra početcima računalne podrške

monolitne aplikacije nisu čista povijest jer i danas specifični sustavi mogu zahtijevati ovakvo rješenje Najčešće su to aplikacije specifične namjene pa su i korisnici specijalizirani i specifični Monolitnost pretpostavlja koegzistiranje sustava i korisnika u istom okruženju najčešće bez česte potrebe za

komunikacijom s okolinom Monolitnost za posljedicu ima čvrstu strukturu pa time i arhitekturu sustava Još je jedno svojstvo monolitnih aplikacija izraženo a to je visoka rutiniranost u obradi podataka

(BatiniampScannapieca 2006) definiraju prostor u kojem su smješteni svi informacijski sustavi prema

svojoj strukturi i arhitekturi Prostor je odreĎen koordinatama potpunost (totally ) heterogenost (heterogeneity) i distribuiranost (distribution)

Uvažavajući ova tri svojstva po mjerivom intenzitetu monolitni su sustavi postavljeni u ishodište koordinatnog sustava Dakle klasificirani su kao

homogeni nisu distribuirani i specijalizirani su U dijagonalnoj točki prostora autori smještaju tzv P2P informacijske sustave Sustavi tipa peer_to_peer se

deklariraju kao autonomni i nezavisni od računala

poslužitelja odnosno sve tri komponente imaju maksimalan intenzitet Prema strukturi se ovakvi

2 Više tehnologije u školi može imat i štetan utjecaj na obrazovanje a računala kod kuće mogu naškoditi učenju

ili bdquoMožete osjetiti eru računala posvuda ovih dana osim u statistici produktivnosti su izjave nobelovca

Roberta Solow doduše izrečene 1987 godine Pokušaj rev izije stava Arnold King tvrdnjom da se to promijenilo i

da možda vrijed i za Evropu ko ja drugačije koristi računala od USA

Slika 2 Monolitna aplikacija (izvor httprubyonrailslinkblogspotcom201009single-tier-architecturehtml 10 Travnja 2012

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 6: ERP vs. SOA ili Cloud Computing

sustavi mogu promatrati kao cloud computing sustavi Obično se pretpostavlja korištenje mogućnosti

više mrežno povezanih računala Skalabilnost je najjače svojstvo takvih sustava(Korri 2010) Značaj podataka i potreba upravljanja podatcima pohranjivanja i čuvanje rezultiralo je potrebom drugačije organizacije aplikativnih rješenja Potreba za dvoslojno troslojno i višeslojno organiziranim

aplikativna rješenjima rezultirala je raslojavanjem u klasi korisnika-informatičara na uže specijalizirana zanimanja(slika 3) Istovremeno je to period podrazumijevane fizičke nazočnosti informatičkih kadrova u poslovno sustavu kao posebnog odjela Specijalizacija kadrova je istovremeno značila i

diversifikaciju prava koje proizlaze iz obveza koje su im na taj način delegirane Krajnji ili ključni korisnik sustava je u ovakvoj arhitekturi sustava izdvojen a pristup mu je omogućen kroz definirano sučelje Odgovornost za bazu podataka je prebačena na za to obučene i pripremljene djelatnike

najčešće informatičke stručnjake rezidentne u poslovnom sustavu Odvajanje baze podataka u zaseban slojtier je korisnikove obveze prema podatcima postavilo u okvire brige o njihovoj točnosti i ispravnosti i oslobaĎanje od briga o organizacijskim i sigurnosnim aspektima O tome je brinuo IT

odjelsektor

Slika 3 Troslojna arhitektura (izvor httpwwwiroumontrealca~pift1025bigjava Ch27 ch27html 10 svibnja 2012)

Bez obzira jesu li podatci bili smješteni u jednostavnu datoteku ili organizirani kao složeniji oblik - baza podataka Kad je tehnologija uznapredovala toliko da je dozvolila mogućnost fizičke dislokacije

korisnika i razuĎenost poslovnog okruženja javila se potreba za organizacijom odnosa poznatim kao client-server organizacija Posljedica je bila potreba specijaliziranih korisnika koji će održavati bazu podataka (dataware) i korisnika koji će brinuti o mreži računala ili radnih stanica ndash osobnih računala na

kojim rade korisnici (clients) Organizacija sustava je karakteriziran užom specijalizacijom informatičkih kadrova i povećanjem konzumnih zahtjeva krajnjih korisnika prema sustavu Novi oblici podatka i digitalizacija dovode od potrebe jače prilagodbe sustava krajnjem korisniku Grafičko sučelje

kao rješenje komunikacijskih zahtjeva će zamijeniti karakter sučelje Korisnikove su mogućnosti veće ali se javlja potreba za trećim slojem (poznat kao middle tier) koji sadrži logiku aplikativnog rješenja Period prije GUI organizacije je svojstven po relativno niskoj informatičkoj naobrazbi korisnika

(Prensky 2001) sve korisnike dijeli u dvije osnovne grupe digitalne uroĎenike i digitalne imigrante Premda je poredak neprirodan činjenica je da grupu imigranata čine poslovni uroĎenici pa je reciprocitet izrazit Tako su na neizravan način korisnici dovedeni u inferioran položaj i informatičarima

ostavljena mogućnost najčešće organiziranima u IT odjel poslovnog sustava relativna sloboda koja im realno ne pripada i koja je ponekad bila krivo tumačena To je dopuštalo dojam superiornosti informatičara i nerijetko dovodilo do problema kod implementacije rješenja i ostavljala dojam prisile

kod korisnika a komplekse neupućenosti i nedoraslosti problemu na obje strani Prikladan odgovor takvoj situaciji se mogao postići ciljanim obrazovanjem i pojednostavljenjem u upravljanju opremom - hardverom i aplikativnim rješenjima ndash softverom Multi-tier arhitekture i raslojavanje data-tiera na

data-sloj sloj preko kojeg se pristupa podatcima data-access-tier Nužnost uključenja poslovnog sloja ndash business-tier i jačeg uključenja krajnjeg korisnika u organizaciju Objektno orijentirani pristup je zrela faza svih navedenih promjena MeĎutim objektno orijentirani

pristup je i značajan pojam u paradigmi organizacije i izgradnje informacijskih sustava i posebice aplikativnih rješenja Potreba razlaganja računalnih rješenja u slojeve ili multi tier organizaciju rezultirala je detaljnijom

podjelom poslova u njihovom razvoju Promjene u pristupu i razmatranju sveukupne problematike pomiču težište od strukture sustava prema arhitekturi sustava kao novom težištu Izmjene u paradigmama su najočitije u pristupu projektiranju i programiranju Objek tno orijentirani soft ver je

praktično i uzrok i posljedica promjena koje će rezultirati pojavom otvorenih plat formi i višestruko iskoristivog softvera Paradigma nasljeĎivanja je odgovor na sve veće i sofisticiranije zahtjeve korisnika njezina praktična realizacija uvijek znači višestruku iskoristivost jednom napisanog softvera

MeĎutim objektno orijentirani pristup ima za posljedicu i bdquopreslagivanje― oko uloge i pozicije korisn ika

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 7: ERP vs. SOA ili Cloud Computing

regulirajući pristupe softveru kroz mehanizme inkapsulacije Na taj se način struktura sustava počinje

promatrati kroz način njegovog konstruiranja ili slaganja i kombiniranja njegovih dijelova pa se stoga i počinje govoriti arhitekturi Mogućnost organizacije informacijskog sustava u uvjetima fizičke razuĎenosti poslovnog sustava podrazumijeva organizaciju mreže računala različitih mogućnosti i

namjena Uz značajniji napredak i usavršavanje tehničkih mogućnosti računala očitovano kroz povećanje memorijskih kapaciteta i brzine procesiranja javljaju se mogućnosti ali i potrebe za drugačijom organizacijom računala Od strukture težište se prenosi na arhitekturu Arhitektura

računalnih sustava uključuje i ureĎenje strukture i organizaciju tehničke osnovice i aplikativnih rješenja pa je prema tome arhitektura pojmovno ali i realno šira od strukture Objektno orijentirana paradigma primarno proklamira tzv kasno vezivanje (eng late binding) čime

daje prednost projektiranju nad programiranjem Kako su programski zahtjevi su najveći izvor nesporazuma meĎu informatičarima i korisnicima ovo se može smatrati prikladnim rješenjem Isto tako se objektno orijentirani pristup može smatrati rezultatom već spomenute sve veće obrazovanosti

krajnjih korisnika u području informacijskih znanosti tako da njihovi zahtjevi predstavljaju veće probleme informatičarima Istovremeno kao posljedica Solow-ljevog paradoksa počinje i razmatranje nužnosti IT sektora kao stalnog organiziranog dijela poslovnog sustava Time je pozicija informatičara

oslabljena a započela temeljitija evaluacija doprinosa in formatike poslovnom uspjehu Većina neuspjeha informacijskog sustava proizlazi iz nerazumijevanja na liniji korisnik -informatičar Ako poslovni sustav posjeduje vlastiti IT sektora tada nesporazumi imaju interni karakter pa time i internu

regulaciju što znači da se može moderirati njihov utjecaj na poslovanje sustava Objektno orijentirani pristup će uz outsourcing omogućiti organizaciju izgradnje proklamiranu kao SOA paradigma Kada se govori o arhitekturi SOA(Service Oriented Architecture) se može promatrati kao politika praksa i okvir

koji omogućuje primjenu funkcionalnosti koje treba osigurati kroz skup usluga (Liebow 2005) Usluge se stavljaju na raspolaganje podnositelju zahtjeva za uslugom implementirane pomoću standardiziranog sučelja(COREgov 2005) U SOA okruženju se pojam korisnika zamjenjuje pojmom

podnositelj zahtjeva Ova zamjena je ipak ograničena na tzv benefitne korisnike koji koriste usluge Podnositelj zahtjeva jest korisnik usluge koju sustav pruža ali je posredno naglašeno da je on pokretač aktivnosti kojima se realizira usluge SOA takoĎer naglašenije afirmira paradigmatske

postavke objektno orijentiranog pristupa posebice način tzv kasnog vezivanja (late binding) resursa Late binding u SOA okruženju postaje weak binding a aplikativno rješenje postaje dinamička kategorija aktivna samo u trenutku potrebe Time se dobiva bolja mogućnost upravljanja troško vima

informacijskih procesa IBM (Balzer 2004) definira načela osnovnih propisa za razvoj održavanj e i korištenje SOA arhitekture SOA arhitekture je objekt sagraĎen od funkcionalnih elemenata i elemenata koji osiguravaju kvalitetu

sustava povezani su politikom pokretanja ili stavljanja usluga na tržište(slika 4)

Slika 4 SOA arhitektura (Source httpwwwmondotechnologiescomenindexaspw=0|0|1 10travnja 2012)

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 8: ERP vs. SOA ili Cloud Computing

Ako se slika 3 dopuni s humanom komponentom tada će na lijevoj strani stajati isključivo korisnici ili

po SOA terminologiji konzumenti usluga Sugeriranje oblačne strukture interneta trenutno nije važno Važnije su mogućnosti koje Internet pruža pod uvjetom da je dostupan Krajnje desno je odvojen podatkovni sloj Ako ovdje sugeriramo humana komponenta postaje jasno da je nužna nazočnost i

konzumenata i davatelja usluga Tradicijski rečeno svi su korisnici involvirani MeĎutim jasno je da je struktura organizacija i održavanje podataka djelatnost u domeni informatičkih stručnjaka podatci kao takvi u domeni korisnika Kvaliteta podataka je prema tome u nadležnosti korisnika a kvantiteta i

gabariti u nadležnosti informatičara MeĎutim nazočnost i mogućnosti koje pruža Internet pospješilo je promišljanja proklamirana SOA

paradigmom prema domišljanju rješenja koja će biti nazvana oblačnim računalstvom Oblačno računalstvo usavršava SOA koncepte ali i objektno orijentirane paradigme Tako (Perry 2009) tvrdi da CC ima zajednička svojstva s autonomnim računalstvom kad je računalni

sustav sposoban za samoupravljanje(Sun microsoft 2009)smatra da CC nasljeĎuje važna svojstva client-server arhitekture(Fontecchio 2008) smatra da CC struktura ima svojstva grid computinga jer može poprimiti formu distribuiranog ili paralelnog računalstva gdje računala mogu biti organizirana

kroz clastere ili labavo vezane mreže ili Mainframe računala za potrebe velikih organizacija s kritičnim aplikacijama poput enterprise resource planning and financial transaction processing (Prashant 2009) prepoznaju u CC Utility computing mdash pakiranje računalnih resursa obrade i spremanja

podataka npr kao mjerivih usluga poput javnih usluga struje i sl Dok (Weiamp Blake 2010) prepoznaju strukturu Peer-to-peer kao distribuiranu arhitektura bez potrebe za središnjom koordinacijom sa sudionicima dok u isto vrijeme oba i dobavljač i potrošačkorisnik koriste resurse (za razliku od

tradicionalne clientndashserver arhitekture) i u konačnici Service-oriented computing ndash software-as-a-service Na taj način nakon weak binding se dolazi do loosely binding paradigme(Sosinsky 2011) Nova arhitektura prati strukturnu razdiobu sustava Tako CC nudi arhitekturno složenu strukturu u tri

tipa SaaS ndash software kaao usluga IaaS ndash Infrastruktura kao usluga i PaaS ndash platforma kao usluga (slika 5)

Slika 5 Cloud computing i slojevita arhitektura ( izvor httpwwwchadesnettag=churchill-club 10 Travnja 2012) Terminologija ponovo ima blagu modifikaciju Tako osim slabog vezivanja komponente više nisu u

tierndashovima (što suštinski znači vezivanje) nego su organizirane u layer-e ndashslojeve Slojevi odražavaju arhitekturu (slika 5)

Client (Cloud clients) računala i ili računalni programi na raspolaganju cloud computing za

isporuku aplikacija kao najnužniji dio(Malik 2008)

Application (Cloud applications) aplikacije kao usluge ili softvera kao usluga (SaaS) softwera dostavljen kao usluge putem interneta bez potrebe za instalacijom i pokretanjem

aplikacije na klijent računalima uz pojednostavljeno održavanja i podršku(Sandu 2008)

Platform(Cloud plat forms) platforma kao usluga ili Platforma kao servis (PaaS) osiguranje računalne plat forme kao servisa uz uporabu infrastrukture i održavanje aplikacija Osigurava

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 9: ERP vs. SOA ili Cloud Computing

implementaciju aplikacije bez troškova potrebe kupovine i upravljanja hardware i software na

osnovnom sloju(Schofield 2008)

Infrastructure(Cloud infrastructure) Cloud Infrastructure Services ili Infrastruktura kao usluga (IaaS) osiguranje računalne infrastrukture - virtualizacije plat forme okoline - kao usluge uz

okvir za pohranu podataka i umrežavanje Umjesto kupnje poslužitelja software središnje memorije i mrežne opreme kupuju se klijent verzije dakle u potpunosti sve vanjske resurse kao uslugu Davatelji usluge naplaćuju na osnovi komunalnih računa odnosno cijena ovisi o

vremenu konzumacije(Pariseau 2008)

Server Poslužiteljski sloj se sastoji od računala i ili računalnih programa posebno dizajniranih za isporuku usluga uključujući višejezgrene procesora oblak specifičnih

operativnih sustava i kombinaciju ponuda(Markoff 2010) Iz podjele na slojeve se vidi da se većina aktivnosti realiziranih u okruženju koje predstavlja informacijski sustav podržan računalima tretira kao usluga Svaka takva usluga zahtjeva pažljivo

složen ugovor prema kojem će se konzumirati MeĎutim ugovor ne regulira samo nabrojane usluge Za davatelja usluga je dovoljan potpis na ugovoru za pojedinačnu uslugu Za konzumenta usluge nije Konzument mora svoje potrebe uokviriti u odgovarajući okvir Za konzumenta okvir odnosno oblak

može biti

Javni- Public cloud Vrsta oblaka u kojima se usluga kao što su aplikacije i skladištenje čine dostupnim široj javnosti preko Interneta Obično su smješteni van korisničkih prost orija i osiguravju mogućnost smanjenja rizika i troška kupca pružanjem fleksibilnih i privremenih

proširenja infrastruktureGens 2008)

Zajednički- Community cloud Oblak odreĎene organizacije Obično je formiran od strane nekoliko poslovnih sustava sa zajedničkim potrebama (sigurnost usklaĎenost nadležnost

itd) bez obzira na način i mjesto s kojeg se upravlja Troškovi funkcioniranja su manji od troškova javnog oblaka ali veći od privatnog oblaka

Hibridni - Hybrid cloud Hibridni oblak je sastavljen od dva ili više oblaka (privatnih zajedničkih

ili javnih) koji su jedinstveni kao cjelina ali osiguravaju mogućnost višestruke implementacije konkretnog modela

Privatni - Private cloud je infrastruktura koja egzistira za pojedinca ili pojedinačnu organizaciju a može biti upravljana iznutra ili izvana(MellampGrance 2011)

Ako se razmotre navedene klasifikacije postaje jasno da se oblak može izražajno i učinkovito realizirati uz pažljivo dogovaranje i pažljivo sročen ugovor ili ugovore Ovisno o tome što korisnikkonzument treba i zahtijeva i kakvu organizaciju želi morat će potpisati i toliko ugovora pojedinač no ili sročeno

zajedno Istovremeno s pomicanjem paradigme prema definicijama usluga i načinima njihovih realizacija važnosti regulacije izvoĎenja osiguranja rezultata usluga jasnije se oblikovala potreba odgovarajućeg

tipa ugovora primjerenog ovom području Osnovna definicija bilo koje ugovora glasi Ugovor je suglasna izjava volje dviju ili više stranaka usmjerena ka postizanju odreĎenog cilja Ugovor u općem obliku zahtjeva

Suglasnost i volju stranaka za potpisivanjem ugovora

Predmet ugovora

Kauzu ili osnovu za zaključenje

Ostale uvjete za potpisivanje ugovora

Suglasnost i izjavljena volja je nužan uvjet za potpisivanje ugovora MeĎutim ne mora biti i dovoljan Uvjet dovoljnosti se ispunjava definiranjem predmeta ugovora i kauzom Ponekad ugovor može imati posebnu formu Na taj način je u odnose ovog tipa ušao pojam i oblik ugovora poznat kao SLA

(service level agreement) SLA(Service level agreement)- je ugovor ili dio ugovora o uslugama izmeĎu dvije stranke gdje je jedna stranka kupac potražitelj a druga stranka je davatelj usluga Predmet ugovora je usluga Kao

pravna institucija ugovor se može koristiti za usluge ili realizacije SLA nužno mora sadržavati

naziv usluge ndash potpuni opis onog što davatelj obećava

način dostave ili isporuke

na koji način će se izvršiti verifikacija usluge vrijeme uporabe i mjerenje iskoristivosti

na koji će se način tretirati neispunjenje ugovora Paradigme i metodologije izgradnje informacijskih sustava

Na početku ovog razmatranja je naglašena relativna pojmovna zbrka u informacijskim znanostima i posebice u području definiranja tehnika metoda tehnologija i metodologija izgradnje informacijskih

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 10: ERP vs. SOA ili Cloud Computing

sustava Namjerno se za potrebe ovog razmatranja informacijski sustav poistovjećuje s računalnom

aplikacijom koja podržava taj sustav premda je to pogrešno Izgradnja aplikacijskog rješenja koje će podržavati informacijski sustav je proces stvaranja modela poslovnog sustava na način da se poslovni procesi prikažu kroz informacijske procese Odatle

sinergija ta dva sustava koja nikako nisu dijelovi nego jedna cjelina Poistovjećivanje se može izvest iz više razloga ali je najvažniji globalizacija poslovanja koja nužno zahtjeva brzo i primjereno upravljanje informacijama na osnovu kojih se upravlja tim poslovanjem Stoga informacijski sustav nužno

podrazumijeva računala Važno je naglasiti da informacijski sustav bez obzira na sve zahtjeva pažljivo planiranje izgradnju i održavanje dok traje njegov životni vijek Izgradnja je prema tome organizirana kao proces u kojem se

realizira odreĎeni projekt A projekt podrazumijeva i odreĎene resurse Jednako tako projekt nije rezultat aktivnosti pojedince već tima koji mora biti pažljivo sastavljen Uspjeh tima i uspješna realizacija projekta je rezultat rada svih članova tima Premda je timski pristup predmet osjetljive

analize nije predmet ovog razmatranja Bitno je napomenuti tko su članovi tima i koja su njihova zaduženja Krajnji korisnik i informatičar čine rudiment cijelog procesa bez obzira na primijenjene tehnike i tehnologije odnosno metode i metodologije U gornjem pregledu je razmatran pojmovni

odnos i promjene koje su se na tom polju dogaĎale vremenom i razvojem hardvera i softvera Bez obzira na to govori li se o arhitekturi ili strukturi korisniku ili akteru monolitu ili višeslojnoj organizaciji činjenica je da će svaki informacijski sustav zadržati u bilo kakvom obliku sve one dijelove koji se

prema podjeli mogu prepoznati kao hardver softver li feware netware orgware dataware Ako se promatra organizacija po SOA principu poslovni sustav mora voditi brigu o osam ključnih izazova( httpmsdnmicrosoftcomen-uslibraryaa480029aspx ) Premda autori dodjeljuju specifične

nazive pojedinim izazovima jasno se prepoznaje tijek specifičan za projektnu realizaciju Polazeći od identifikacije usluge vezanosti za poslovnu funkciju nužno je odrediti zrnatost usluge lokacija usluge (u fizičkom smislu) domena usluge način pakiranja mogućnost orkestracije upravljanje uslugom i

dosljedna primjena odreĎenih standarda Vežući se na tradicijsku razdiobu informacijskog sustava postaje nužno dopunjavanje s još jednim dijelom SLAware -om Sve prethodne aktivnosti provedbe SOA-e zahtijevaju vrlo pažljivo sročen ugovor ili ugovore ako se želi imati djelotvoran i učinkovit

informacijski sustav U kratkoj povijesti načina izgradnje informacijskih sustava metodologije su se izmjenjivale zbog više razloga Metodologija nekog procesa projekta ili bilo koje smislene aktivnosti bi na odreĎeni način

trebala bit zasnovana na znanstvenim i iskustvenim postavkama i činjenicama Svaka teorija nužno pretpostavlja odreĎenu vrstu iskustva odnosno prakse U slučaju metodologija razvoja informacijskih sustava teorija i praksa su povijesno gledano bile dosta

disonantne iz više razloga U ranijoj fazi dok su proizvoĎači hardvera držali neku vrstu zaštite nad svojim proizvodima razvijali su i vlastite metodologije razvoja informacijskih sustava Iz tog vremena potječu vodopadna metodologija v-metodologija te kasnije kad se inzistira na integralnosti

metodologije iterativnog i inkrementalnog razvoja informacijskih sustava Značajnija izmjena paradigme je funkcionalni dizajn pomaknula ka objektno orijentiranom Premda razmišljanje na objektni način seže od ranih 60 -tih pravu primjenu će objektni pristup u području

razvoja informacijskih sustava doživjeti tek početkom 90-tih

Slika 6 ERP struktura (Izvor httpwwwopen-source-erp-sitecomerp-moduleshtml 10 travnja 2012)

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 11: ERP vs. SOA ili Cloud Computing

Nekako istovremeno Gartner Group prvi koriste akronim ERP Premda je ERP većim dijelom

nastavak i razvoj MRP ndash planiranja materijala kasnije će biti uključeni i planiranje resursa te automatizacija i upravljanje procesima proizvodnje Do sredine 90 ERP sustavi će obuhvatiti sve funkcije poduzeća ndash poslovnog sustava To je bio evolucijski domet na području integracije aplikacija

unutar poslovnog sustava Iako proizašla iz proizvodnih poslovnih sustava ERP koncepcija će do kraja 90-ih biti primjenjiva i u neproizvodnim okvirima odnosno u području usluga MeĎutim ERP je koncepcija koja ne isključuje primjenu drugih metodologija dapače poželjna je

primjerena metodologija razvoja softvera da bi ERP bio realiziran na najbolji način Premda se u trenutcima proklamiranja ERP-a ne spominje eksplicitno arhitektura informacijskog sustava ona se nameće sama po sebi Inzistirajući na čvrstim vezama meĎu modulima ERP na zajedničkoj bazi

podataka dosljednosti u implementaciji i operativnoj primjeni softvera osigurava se puna funkcionalnost informacijskog sustava Spomenuto vrijedi za svaki poslovni sustav bez obzira na njegovu veličinu i konkretnu funkciju Neki će autori navesti kao razlog pojavljivanja ERP koncepta i

problem 2000 godine i pojavu eura i probleme s financijskim aplikacijama(MonkampWagner 2006) Integralnost dosljednost dostupnost su samo neka svojstva koja mora posjedovati kvalitetan informacijski sustav bez obzira na pristup u izgradnji njegove arhitekture Ako se mijenja pristup u

arhitekturnim rješenjima sva navedena svojstva moraju biti sačuvana u punoj vrijednosti Zato će pojmovi kao što su late binding u okviru objektno orijentiranih paradigmi weaak binding u okviru SOA arhitekture i loose binding u okviru oblačnog računarstva zvučati disonantno Korisnik će biti

podrazumijevano sumnjičav prema punoj integrativnosti informacijskog sustava pri tumačenjima arhitekture oblačnog računarstva MeĎutim osnovni razlog za primjenu koncepcije oblačnog računarstva je financijske prirode ndash smanjenje ukupnih troškova poslovnog sustava kroz smanjenje

troškova informacijskog sustava Ako korisnik stekne dojam da informacijski sustav ima prazne hodove a troši resurse u prvom redu financijske onda će pristati na svaki vid uštede Pogotovu ako je ta ušteda značajnija ili barem postoje izgledi da takva bude U nastavku će bit usporeĎeni i

komentirani neki faktori i neka svojstva kod izgradnje informacijskog sustava zasnovanog na ERP koncepciji i primijenjenoj arhitekturi tipa SOA ili oblačnog računarstva

Koncept struktura arihtektura ili sve skupa Čak i kad se predloži SOA ili oblačno računarstvo kao arhitekturni pristup ostaje klasična struktura

računalno podržanog informacijskog sustava Činjenica da korisnik ili poslovni sustav ne posjeduje svoj hardver nego plaća njegovo iznajmljivanje ne mijena ništa u strukturi U globalnim uvjetima hardver mora postojati bio on vlastiti ili iznajmljeni Posljedično ista je stvar i sa softverom bio on

vlastiti ili iznajmljeni razvijan unutar poslovnog sustava ili kupljen na tržištu softvera I u najizraženi joj varijanti oblačnog računarstva poslovni sustav će morati posjedo vati odreĎeni hardver i softver na krajnjoj točki ndash rubu ili sredini oblaka Jednako tako će biti nužno posjedovanje odreĎenih mrežnih

ureĎaja kapaciteta u mjeri koja bude zahtijevala integriranost tog tipa Dakle ipak netware kombiniranog posjedovnog porijekla Dataware - podatci baza podataka upravljanje bazom održavanje baze i ostali poslovi većim dijelom mogu biti izmješteni odnosno izvlašteni u tom smislu ali

odgovornost za pragmatički aspekt ostaje u nadležnosti korisnika Ovo područje otvara i druge probleme kao što su sigurnost baze podataka (ne)mogućnost ugroze vitalnih interesa poslovnog sustava kroz odavanje podataka koji mogu biti poslovna tajna i sl Orgware

ndash sveukupna organizacijska pravila prema kojima se realizira funkcija informacijskog sustava u oblačnom računarstvu dobiva na izražajnosti Na slici 7 autori sugeriraju čvrsto ugovaranje na svim pozicijama komunikacije Stoga Orgware dobiva poseban dio kojeg se može uvjetno nazvati SLAware

pa ga čak i izdvojiti u zaseban dio strukturni dio Pravni etički pa i moralni aspekti izgradnje i održavanja informacijskog sustava postaju u ovakvoj arhitekturi naglašeniji Ostaje lifeware - dio koji mora garantirati funkcioniranje informacijskog sustava Osjetljivo područje

ljudskih nadležnosti i odgovornosti ndash bdquominsko polje― područje u kojem su sadržani najčešći razlozi zbog kojih sustav može biti nezadovoljavajući Izmještanje kadrova informatičke specijalnosti pa i cijel og IT sektora može značajnije smanjiti troškove poslovnog sustava ali istovremeno učiniti poslovni sustav

ugroženijim u osnovnoj funkciji koja izrazito ovisi o funkcioniranju informacijskog sustava ERP koncepcija pretpostavlja punu integriranost pojedinih modula aplikativnog software ali ne prejudicira arhitekturno rješenje MeĎutim za punu funkciju poslovnog sustava pretpostavka je nužna

ali nije i dovoljna Ako su ranijim paradigmatskim postavkama i pristupima bili ispunjeni uvjeti koji su bili postavljeni pred informacijski sustav tada izmjena paradigmatskog pristupa i arhitekturni oblik na to ne smiju utjecati Pogotovo ako je ušteda planirana outsourcing -om IT sektora manja od eventualne

štete izazivane raznim nefunkcionalnostima informacijskog sus tava

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 12: ERP vs. SOA ili Cloud Computing

Slika 7 SOA arhitektura (izvor httpmsdnmicrosoftcomen-uslibraryaa480027aspx aj2mps

oarch_topic2 10 travnja 2012) U nastavku su prikazani neki momenti u izgradnji ERP s autorskim viĎenjem eventualnih posljedica koje mogu nastupiti ako se planira SOA arhitektura ili arhitektura tipa oblačnog računarstva

Odluka za SOA ili CC arhitekturu u današnjim okvirima za već postojeće informacijske sustave će značiti migraciju postojećeg sustava u nove okvire ili novo okruženje Za poslovni sus tav će to značiti donošenje odluke o načinu provoĎenja i konačnom obliku ili konačnoj arhitekturi To znači projektnu

provedbu svih aktivnosti koje su nužne Posljedično je potrebno planirati projekt dodijeliti resurse i odrediti rokove Kako ovaj dogaĎaj ima veliku financijsku težinu podrazumijevano je i preporučljivo temeljito istraživanje tržišta

Pri tome se menadžment poslovnog sustava može rukovoditi za različitim kriterijima Tako subjektivni kriteriji izbora mogu biti

Podatci sa tržišta Premda se podatci ovog tipa dobiju od prodavatelja ovo nije pouzdan i

jednostavan kriterij Prvu skupinu čine financijski pokazatelji Veće se prodavače i dobavljače percipira ka o uspješne dok se manje koji mogu biti uspješniji i specijalizirani može zanemariti Usporedba takvih podataka može biti bez rezultata Druga podskupina je procjena

angažiranosti prodavatelja na provedbi obuke savjetovanja i usluga podrške korisnicima Treći pokazatelj je cijena Najjeftinije rješenje nije često najbolji izbor kao niti n ajskuplje Jednako tako i način plaćanja treba biti jedan od pokazatelja Važan faktor kod izbora je

mogući podatak o tome koliko se dobavljačprodavač angažira na komunikaciji sa svojim kupcima Dobro je provjerit dali možda postoje asocijacije bivših kup aca i jesu li mogući kontakti s njima Relativno doba znak kvalitete može biti i podatak o tome koliko je prodavatelj

otvoren za javne rasprave i kritike i održava li korisničke sastanke gdje se postojeći korisnici mogu upoznati a potencijalni korisnici dobit potrebne informacije

Jednostavnost korištenja Ovaj skup kriterija je čisto subjektivan i ovisi o polaznoj procjeni i

tumačenje onoga što je dobro ili nije dobro za potencijalnog korisnika Jednostavnost uporabe se obično temelji na procjeni jednostavnosti sučelja i mogućnosti njegove modifikacije Pitanja u ovom području iziskuju vrijeme i trebaju biti rasporeĎeni tijekom cijelog selekcijskog

postupka Osjetljivi faktor je odnos pune funkcionalnosti aplikacije i jednostavnosti provedbe pojedinih funkcija

Reference Reference su pokazatelj zasnovan na korisničkoj procjeni kvalitete softvera načinu izvedbe isporuke podrške i potrebnih servisa Ovo je subjektivna kriterij koji se može

primijeniti na bilo koji izbor softvera i bilo koji način organizacije Objektivni kriteriji izbora

Jasno definiranje zahtjeva Nužno je znati što se želi uraditi kroz promjene Zahtjevi

trebaju biti podržani od strane više odjela i pri tome artikulirani u suglasnosti s ključnim korisnicima i prilagoĎeni relevantnim funkcijama poslovnog sustava Nastojati uskladiti zahtjeve s ponudom potencijalnog dobavljača

Provjera prikladnosti dobavljačevih kompetencija zahtjevima Uključiti provjeru iskustva dobavljača i njegovu upućenost u funkcioniranje sličnih poslovnih sustava Ispitati posjeduju li izvješća s takvih pozicija Kod prezentacije rješenja inzistirati na obradi primjera koji se

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 13: ERP vs. SOA ili Cloud Computing

mogu sresti u poslovnom sustavu Minimizirati broj pretpostavki Na osnovu jasne i

djelotvorne komunikacije brzine dobivenih odgovora i njihove primjerenosti zahtjevima može se procijeniti kvaliteta rješenja Odrediti specijalnost dobavljača i pokušati ugraditi u svoje specifičnosti

Provjera certificiranosti i organizacije podrške Kao i kod subjektivnih procjena treba provjerit da li dobavljač posjeduje certifikate i organizira li potrebne obuke te ima li rezervirane djelatnike za podršku i kako je podrška organizirana

Upravljati promjenama UvoĎenje novog rješenja ERP-a iskoristit za obuku i usavršavanje djelatnika posebice ključnih Dati priliku za napredovanje zainteresiranima i inzistirati na povezivanju u funkcioniranju Ovo je u SOA okruženju bitno kod procesa orkestracije

usluga

Granularnost ili zrnatost usluga u SOA je prilično novo svojstvo aplikativnog rješenja Inzistiranje na

bdquoatomizaciji― usluga je nužno iz više razloga Cijena usluge će se odreĎivati i prema broju obavljenih aktivnosti za vrijeme odreĎene usluge Stoga se odreĎivanje zahtjeva prema sustavu može uobličiti u jednu ili više elementarnih usluga Poseban je problem orkestracija usluga tj situacija kad jedna

usluga može pozivati više različitih usluga ili neku uslugu više puta Navedeno je svojstvo polazna osnova za procjenu vrijednosti usluge i u okviru oblačnog računarstva se naziva mjerivost (measured service) Usluga u oblačnom računarstvu mora biti mjeriva jer se

proklamira način plaćanja tipa (PAG pay-as-you-go) dakle plaćanje po usluživanju Naravno da to ne znači da je mogućnost prepaid -a ili pretplate isključena a obračun izveden u odreĎenom roku sumarno Osim mjerivosti nužno je pretpostavljena mreža s kojom će raspolagati korisnik prema

potrebi Skalabilnost će osigurati mogućnost angažiranja tehnoloških potreba prema trenutnom zahtjevu korisnika Zajedničko svojstvo ERP SAP i oblačno računarstvo pristupima je nastojanje smanjenja ukupnih

troškova poslovnog sustava kroz optimizaciju informacijskih procesa i cijene tehnologije (hardver -softver kombinacije) koja se koristi u tim procesima Oblačno računarstvo je u tom smislu najefikasnije jer se kroz koncepte virtualne postavke potrebnog

sustava angažira optimalno potrebna količina opreme Mreža i pristup mreži je od vitalnog značaja u takvim situacijama Ako se ima namjeru organizirati ERP kroz oblačnu arhitekturu tada kod izbora konačne arhitekture

treba voditi računa o nekoliko činjenica(Toolboxcom amp Ziff Davis Inc)

Web bazirani ERP je rješenje u kojem se usluge oslanjaju na hardver i softver raspoloživ na web-u što znači da poslovni sustav ne mora raspolagati vlastiti

Jasno definirati ciljeve poslovnog sustava i način kako ERP treba osigurati njihovo

ostvarenje Zadatak ERP-a je optimizacija poslovnih procesa pa je uporaba raspoloživih standardnih tehnika npr u računovodstvu raspoloživih na webu dobar način

Koncentrirati se na mogućnosti kojima ERP može optimizirati poslovne procese Pri tome

može javiti potreba za modifikacijom pojedini poslovnih procesa odnosno reinženjeringom u svrhu postizanja potrebnog cilja

Potreba poznavanja rada i aktivnosti krajnjih korisnika i njihovih svakodnevnih komunikacija jer će konačna verzija usluge zavisiti u većem dijelu od navedenog U tu svrhu je nužno

uključenje krajnjih korisnika kod artikulacije zahtjeva za uslugom

Priprema i rok uvoĎenja ERP su osjetljivi faktori Ako se inzistira na integraciji ERP kao cjelovit sustav će zahtijevati više vremena i angažman različit ih profila djelatnika Ako

poslovni sustav posjeduje IT sektor i nastoji ga zadržati tada će vjerojatno biti nužna neka vrsta dodatnog treninga i obuke i za IT struku a ne samo za krajnje korisnike

Trening obuka i testiranje konačnog rješenja pod punim opterećenjem ne smiju izostati Zato

se treba planirati dio projektnog budžeta za tu svrhu

Migracija podataka (Data take over) je osjetljiva faza u kojoj je poslovni sustav ranjiv Ak podatci migriraju u novo okruženje tipa oblačnog računarstva tada taj proces mora biti vrlo pažljivo izveden Migracija baze podataka obično jest proces koji podrazumijeva

preformatiranje podataka što može dovesti do gubljenja odreĎenih podataka koji opet mogu biti od vitalnog značaja

Navedeno su samo neke činjenice i savjeti kako voditi brigu o njima prilikom provoĎenja ERP -a

MeĎutim najjači adut kod primjene ERP-a je zapravo implementacija softvera na zahtjev (SaaS) To praktično znači da korisnik izbjegava bdquotradicijski― način instalacije i kupovine softvera nema potrebu za kupovinom hardvera niti obukom kadrova koji trebaju brinuti o tim poslovima Time se i poslovi oko

praćenja povrata investicija u daj dio opreme i aplikacijskih rješenja smanjuju značajno

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 14: ERP vs. SOA ili Cloud Computing

Zaključak

Niti jedna znanost nije imala takve okolnosti u svojem razvoju kao informacijska znanost Od početaka zasnovanih na semiotici 1938 godine (Charles Morris) preko raznih teorija igara odlučivanja teorije informacija kibernetike 1948 (Norbert Wiener) opće teorije sustava (Ludvig von Bertalanffy) 1950

do početaka 60-tih godina isprepletat će se teorije koje će činiti informacijsku znanost Preuzimanje pojedinih teorija metodologija metoda i tehnika su posljedica u prvom redu nedostatka sustavno obraĎivane dobre prakse na kojoj bi se mogla definirati vlastita znanstvena jezgra Drugi je razlog

involviranost teorije informacija u svim drugim znanostima odakle proizlazi meĎuzavisnost Oba su ova razloga aktualna i danas Nedostatak vlastite znanstvene jezgre se najjače očituje u nedostatku standardizirane i unificirane

terminologije Izgradnja informacijskog sustava može biti izvedena na raz ličite načine uz primjenu različitih metodologija što će u velikoj mjeri ovisiti o poslovnom sustavu čiji se informacijski sustav izgraĎuje Zbog toga se u literaturi može sresti tvrdnja da informacijsku znanost odlikuje i u dobrom i u

lošem smislu adhokratičnost odnosno primjerenost svih aktivnosti ad hoc situacijama Dobra strana tog svojstva je svakako činjenica da je svaki sustav specifičan na svoj način pa je time i ad hoc reakcija nužna

MeĎutim tijekom razvoja informacijskih znanosti utjecaj na spomenute činjenice je najvećim dijelom izražen kroz odnos korisnika i informatičkog stručnjaka te načine organizacije njihove komunikacije Kroz čitavo to vrijeme mijenja se i poimanje odnosa u smislu vlasništva nad tehničkim i tehnološkim

rješenjima Obrazovanost krajnjeg korisnika je usmjeravana na postupno usvajanje odreĎenih kompetencija koje su svojatane od strane informatičara Kad je informatički odjel postao preskup u svijetlu ukupnog poslovanja sustava stekle su se okolnosti da ga se izmjesti ili barem pokuša izmjestiti

iz poslovne okoline Povlaštenost umišljena neprikosnovenost pojedinih proizvoĎača hardvera i softvera plovila je godinama a za neke još plov t raje na krilima prikrivenog monopolizma i okolnosti trenutka

ERP je u svakom poslovnom sustavu bio prvi značajniji pokušaj ekonomiziranja informacijskim sustavom na svim razinama poslovnog sustava Smanjenje troškova je podrazumijevalo integraciju svih postojećih modularnih rješenja Pri tome je svejedno kojom metodologijom tehnikama i

metodama će se izgraditi aplikacijsko rješenje informacijske podrške poslovnim procesima Sugeriranje suprotnosti ERP i recentnih rješenja izgradnje arhitekture ali i strukture informacijskog sustava očito nema smisla jer se radi o dva različita pojma ali j e napravljeno s namjerom da se

naglasi ponovo da se informacijski sustav gradi zbog pripadajućeg poslovnog sustava i krajnjeg korisnika koji u njemu ostvaruje svoje potrebe realizirajući konkretne poslovne procese Konkretan poslovni proces mora biti praćen informacijskim procesom i nužnim informacijama a

njihova realizacija zahtijeva angažman svih onih dijelova prema tradicijskoj podjeli informacijskog sustava Pri tome je svejedno kako su oni organizirani i realizirani realno fizički ili virtualno jer s vaka virtualnost podrazumijeva realnost u nekoj od faza Stoga je korisniku svejedno ima li po nazivu pred

sobom modul paket aplikaciju uslugu ili oblak ako svoje trenutne probleme može trenutno riješiti Nije nužno da mu se pojašnjava teorija paradigme ako izostaje podrška Očito je da potreba lako mijenja paradigmu ako je dovoljno urgentna A na informatičarima je sada da se prilagoĎavaju situaciji

i postanu za svoje dobro što senzibilniji i adhokratičniji Literatura

Balzer Y (2004) Improve your SOA project plans IBM 16 July 2004 BatiniCScannapieco M (Oct 9 2006) Data Quality Concepts Methodologies and Techniques

(Data-Centric Systems and Applications) by) Springer ISBN-13 978-3540331728 Fontecchio M (2009) Sun CTO Cloud computing is like the mainframe Itknowledgeexchange techtargetcom 2009-03-11 Retrieved 2010-08-22

Gens F (2008) Defining Cloud Services and Cloud Computing IDC 2008 -09-23 Retrieved 2010-08-22 httpwwwtheregistercouk20100121brad_smith_cloud_computing_microsoft

Korri T Cloud computing utility computing over the Internet Helsinki University of Technology wwwcsetkkfienpublicationsB5papersKorri_finalpdf (pristupljeno 1052010) Kroenke D M (2008) Experiencing MIS Prentice-Hall Upper Saddle River New Jersey

Kuhn TS (1996) The Structure of Scientific Revolutions Chicago and London University of Chicago Press 1996 (3rd ed) Liebow M(2005) Do customers really want SOA IBM TechRepublic ZDNet News Feb 10

Malik O (2008) bdquoWhat Makes a Cloud Computer Gigaomcom Retrieved 2010-08-22

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Page 15: ERP vs. SOA ili Cloud Computing

Markoff J (2010) Microsoft Plans Cloud Operating System Nyt imescom Retrieved 2011-08-20

Mell P Grance T (2011) (The NIST Definition of Cloud Computing (Draft) National Institute of Science and Technology Retrieved 2011-07-24) Monk Ellen M Wagner B (2006) Concepts in Enterprise Resource Planning (Second ed) Boston

Thomson Course Technology ISBN 0-619-21663-8) OBrien J A (2003) Introduction to information systems essentials for the e -business enterprise McGraw-Hill Boston MA

Pariseau B (2008)EMC buys Pi and forms a cloud computing group Searchstoragetechtargetcom Retrieved 2010-08-22 Perry G (2010) Whats In A Name Utility vs Cloud vs Grid Datacenterknowledgecom Retrieved

2010-08-22 Prensky M (2001) Digital Natives Digital Immigrants From On the Horizon MCB University Press Vol 9 No 5

Robert Solow R(1987) Wed better watch out New York Times Book Review Sandu KJ at al (2008) An example of a Cloud Platform for building applications Eccentexcom Retrieved 2010-08-22

Schofield J (2008) Google angles for business users with platform as a service London Guardian Retrieved 2010-08-22 Sharma P(2010) It s probable that youve misunderstood Cloud Computing until now TechPluto

Retrieved 2010-09-14 Sosinsky B Cloud Computing Bible Wiley 2011 ISBN-13 978-0470903568 Sun Microsystem (2009) Distributed Application Architecture Sun Microsystem Retr 2009-06-16

TuĎmanM BorasD Dovedan Z (2012) Uvod u informacijske znanosti Digitalna zbirka udžbenika Filozofskog fakulteta u Zagrebu pristup httpdzsffzgunizghrtextUvod20u20 informacijske20znanostiindexhtml 10-04-2012

Yi Wei Y Blake M B (2010) Service-Oriented Computing and Cloud Computing Challenges and Opportunities IEEE Internet Computing Retrieved 2010-12-04

drsc Pogarčić Ivan Marinići Mučići 46 a 51216 Viškovo Hrvatska (Croatia) Tel +385 51 353 753 pogarcicvelerihr

Viši predavač na Veleučilištu u Rijeci Voditelj studija informatike pri Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Doktorat znanosti Filozofski fakultet Sveučilišta u Zagrebu dr znanosti završio E-learning akademiju pri Carnet-u smjer E-learning management

certificiran za Carnet-ov online tečaj Izrada online tečaja pomoću WebCT-a certificiran kao ECDL espert i ECDL ovlašteni ispitivač certificiran za full diplomu ECDL-a

Microsoft certi fikat za Microsoft Project Oracle certifikat za programiranje u Javi T-com interna edukacija za MM FI CO module SAP-a

certificiran za Oracle-ove alate Forms Report PLSQL OracleCase - alat za projektiranje IS certificiran za BSP pri IBM Intertrade u Radovljici cerificiran za MAPPER 1100 i RDBMS pri UNISYS ndash Inforsistem

magisterij informacijskih znanosti Postdiplomski studij Sveučilišta u Zagrebu mr znanosti diploma profesora matematike i fizike Pedagoški fakultet Rijeka profesor matematike i fizike automehaničar Industrijska škola Vareš Republika BiH

amatersko zborsko pjevanje ndash tenor I Davidović Vlatka profesor informatike

Tel +385 51 353 753 vdavidvelerihr Predavač na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr

Panev Ida profesor informatike Tel +385 51 353 753 vdavidvelerihr

Asistent na Veleučilištu u Rijeci Veleučilište u Rijeci Trpimirova 2 +385 51 32 13 00 uredvelerihr httpwwwvelerihr