VILNIAUS UNIVERSITETAS

MATEMATIKOS IR INFORMATIKOS FAKULTETAS

PROGRAMŲ SISTEMŲ KATEDRA

Paslaugų stiliaus informacinių sistemų kūrimas

korporacijos kontekste

Business-Driven Service-Oriented Information System

Development in an Enterprise Context

Magistro baigiamojo darbo literatūros apţvalga

Atliko: Lukas Sirvydis (parašas)

Darbo vadovė: doc. dr. Audronė Lupeikienė (parašas)

Darbo recenzentas: Donatas Čiukšys (parašas)

Vilnius – 2012

2

TURINYS

ĮVADAS ..................................................................................................................................... 3

1. KORPORACIJOS ARCHITEKTŪROS KŪRIMAS ....................................................... 7

1.1. IS sampratos kitimas .................................................................................................. 7

1.2. Korporacijos masto sistemos ................................................................................... 11

1.3. Korporacijos paslaugų stiliaus IS ............................................................................ 13

1.4. Korporacijos IS architektūros samprata ................................................................... 16

2. METODIKŲ ANALIZĖ ................................................................................................. 20

2.1. Zachman metodinis karkasas ................................................................................... 20

2.2. TOGAF ADM metodika .......................................................................................... 24

2.3. SOMA metodas ........................................................................................................ 28

IŠVADOS IR PASTEBĖJIMAI .............................................................................................. 31

ŠALTINIAI .............................................................................................................................. 33

3

ĮVADAS

Nagrinėjimo objektas

Šiuolaikinė informacinė sistema yra korporacijos dalis, teikianti jai informacines,

skaičiuojamąsias ir komunikavimo paslaugas ir padedanti siekti verslo tikslų. Todėl informacinės

sistemos turi būti kuriamos kaip integruotos korporacijų sudedamosios dalys. Šiame darbe

nagrinėjamas paslaugų architektūros stiliaus integruotų informacinių sistemų kūrimas, uţtikrinantis

tokių sistemų ir jas palaikančių programų sistemų atitikimą verslo poreikiams.

Temos aktualumas

Nuolat besikeičiančios verslo sąlygos, aplinkybės sukelia verslo įmonei papildomus

rūpesčius: keičia įmonės tikslus, veiklos planus, vykdomus procesus. Pasikeitę įmonės tikslai

įtakoja verslo procesą, kuris betarpiškai susijęs su įmonės naudojama informacine sistema.

Pasikeitimai verslo aplinkos formuoja naujus reikalavimus informacinei ir ją palaikančioms

programų sistemoms. Verslą palaikanti informacinė sistema tampa viena iš lemiančių faktorių

sėkmingam verslo vykdymui.

Informacinių sistemų kūrimo metodikos aprašo kaip verslo reikalavimai yra paverčiami

programų sistemų reikalavimais, neatskiriant verslo proceso kuris yra informacinės sistemos dalis.

Verslą palaikančios informacinės sistemos nepasiţymi lankstumu, kuris leistų kuo maţesnėmis

sąnaudomis esamą informacinę sistemą pritaikyti naujiems verslo poreikiams. Daţniausiai

keičiantis informacinės sistemos funkciniams reikalavimams, esamų informacinių sistemų

architektūrinio lankstumo nepakanka naujų reikalavimų įgyvendinime maţiausiais kaštais. Esamos

informacinių sistemų kūrimo metodikos neaprašo išreikštinai atskiriant informacinės sistemos

kūrimą nuo programų sistemų. Vienas iš plačiausiai naudojamų korporacijų kompiuterinių sistemų

kūrimo metodinis karkasas TOGAF ir inţinerinis procesas ADM aprašo visas integruotų sistemų

gyvavimo ciklo stadijas kompiuterinių paslaugų architektūros stiliaus sistemoms kurti. Verslą

palaikanti informacinė sistema realizuoja funkcionalumą savo kompiuterinių paslaugų

komponentuose. Metodika uţtikrina verslą palaikančių kompiuterinių paslaugų kūrimą, tačiau

neišsprendţia atotrūkio tarp verslo proceso ir jam reikiamų programų sistemų, todėl galėtų būti

modifikuojama. Nagrinėjama programų sistema, susideda iš funkcinių komponentų [Vas07], kurie

tarpusavyje susiję, jų funkcionalumas beveik nekintantis. Programų sistema įgyvendina [Spe92]

4

funkcinius reikalavimus, tačiau sistemos architektūros projektavimas nėra tinkamas, kai daţnai

keičiaisi verslo procesai iš kurių išplaukia nauji informacinės sistemos reikalavimai.

Besikeičiančiomis verslo sąlygomis, sėkmingai veikiančiam verslui aktualu prisitaikyti kuo

maţesnėmis sąnaudomis prie naujų verslo aplinkybių. Kadangi verslą palaikanti informacinė

sistema yra neatsiejama nuo verslo lygmens, todėl reikalinga tokia informacinės sistemos kūrimo

metodika, kuri išreikštiniu būdu formuotų informacinės sistemos kūrimą atskirai nuo

funkcionalumo realizavimo funkciniuose komponentuose, kurie gali būti trečių šalių. Funkcinių

komponentų paslaugų tiekėjai suteiks informacinei sistemai verslo procesų palaikymo

funkcionalumą. Nebenaudojamos ir nereikalingos paslaugos bus nesunkiai pakeičiamos naujomis,

kurių reikalauja pasikeitęs verslo procesas. Korporacijos informacinė sistema išreikštiniu būdu

susies verslo procesus, kurių įgyvendinimas bus realizuotas ţemesniame lygyje, kuriame bus

įgyvendinti iš informacinių sistemų reikalavimų suformuluoti programų sistemų reikalavimai.

Tačiau didţioji dalis korporacijų kompiuterinėms sistemoms kurti skirtų metodinių karkasų ir

inţinerinių procesų retai skiria pakankamai dėmesio informacinių sistemų, kaip vienos iš

korporacijų sudedamosios dalies, kūrimui. Todėl šios metodikos labiau tinka pirmos kartos

informacinėms sistemoms, ir jų išskiriamų aspektų nepakanka informacinei sistemai, suprantamai

kaip korporacijos daliai, sukurti.

Temos naujumas

Verslo įmonės organizacinė struktūra turi savo verslo tikslus, procesus, strategiją. Kuriant

įmonės integruotas sistemas lygiagrečiai projektuojama ir verslą palaikanti informacinė sistema.

Organizacijos tikslai transformuojami į informacinės sistemos reikalavimus. Verslą palaikanti

informacinė sistema yra susiejama su verslo procesais. Darbo [Ver03] teigimu vienas iš pagrindinių

informacinės sistemos privalumų, tai korporacijos programų sistemų integravimas į visumą.

Informacinė sistema yra nagrinėjama [Vas07], realizavimo poţiūriu išskiriant programų sistemas

kaip komponentus, palaikančius informacinės sistemos funkcionalumą, o pati sistema teikia

paslaugas verslui.

Darbo [Spe92] autorius Steven H. Spewak mano, kad verslo informacinė sistema turėtų būti

pradėta kurti nuo korporacijos architektūros planavimo (angl. Enterprise Architecture Planning

(EAP)), nusakant korporacijos tikslus, strategiją, kurie sąlygoja veiklos procesą ir reikalavimus

informacinei sistemai. Sistemos funkcionalumas įgyvendinimas programų sistemose atsiţvelgiant į

5

verslo reikalavimus ir duomenis gautus iš informacinės sistemos. Remiantis Spewak metodika

[Spe92] ir Zachman metodiniu karkasu, Amerikos Federalinė vyriausybė bei daugelis kitų

organizacijų sukūrė savo integruotas informacines sistemas. Kitaip nei programų sistema,

organizacijos centrinė informacinė sistema yra integruojanti ir koordinuojanti verslo procesus,

teikianti informaciją funkciniams komponentas, kurie gali būti ir trečių šalių [BS11].

Informacinės sistemos reikalavimus reikia atskirti nuo verslo reikalavimų ir formuluoti juos

atskirai. Visų informacinę sistemą palaikančių programų sistemų bei informacinių ir komunikavimo

technologijų kūrimas turi būti nagrinėjamas informacinės sistemos kontekste, nes tos technologijos

ir sistemos yra informacinės sistemos komponentai. Vieno iš plačiausiai naudojamų metodinio

karkaso TOGAF ir programų sistemų kūrimo proceso ADM kontekste informacinė sistema turėtų

įsiterpti tarp verslo ir programų sistemos. Tačiau taip ši problema dar nėra išspręsta, todėl programų

sistemų kūrimo procesas ADM bus pasirinktas informacinės sistemos kūrimo metodikos sudarymui.

Darbo tikslas

Modifikuoti korporacijų integruotų kompiuterinių sistemų kūrimo metodiką taip, kad būtų

atsiţvelgiama į visų lygmenų sistemas – informacinių sistemų kūrimą atskirti nuo verslo ir

programų sistemų ir jas projektuoti išreikštiniu būdu.

Darbo užduotys

1. Išanalizuoti korporacijų kompiuterinių sistemų kūrimo metodikas, konkrečiau – metodinius

karkasus ir inţinerinius procesus, išreikštinio informacinių sistemų nagrinėjimo poţiūriu.

2. Modifikuoti korporacijų integruotų kompiuterinių sistemų kūrimo metodiką taip, kad

paslaugų architektūros stiliaus informacinė sistema būtų kuriama išreikštiniu būdu.

3. Ištirti ir įvertinti modifikuotą korporacijų integruotų kompiuterinių sistemų kūrimo

metodiką.

Planuojami rezultatai

1. Patvirtinta hipotezė, kad korporacijų kompiuterinių sistemų kūrimo metodikos, skirtos

paslaugų architektūros stiliaus sistemoms kurti, išreikštiniu būdu nenagrinėja informacinių

sistemų kūrimo.

6

2. Pasiūlytos taisyklės, nusakančios kaip modifikuoti korporacijų paslaugų architektūros

stiliaus kompiuterinių sistemų kūrimo metodiką, kad informacinių sistemų kūrimas būtų

nagrinėjamas kaip išreikštinis tokių sistemų kūrimo inţinerinis procesas.

7

1. KORPORACIJOS ARCHITEKTŪROS KŪRIMAS

1.1. IS sampratos kitimas

Vystantis informacinėms technologijoms, verslo informacinės sistemos apimtis, sudėtingumas

ir valdomų duomenų kiekis kinta informacinės sistemos vystymosi atţvilgiu. Keičiasi organizacijos

architektūros sampratos sąvoka.

Informacinių sistemų vystymasis susijęs su verslo apimties didėjimu, kuris tampriai susijęs

tarpusavyje informaciniais ryšiais su verslą įtakojančiais išorės elementais. Verslui keliami

uţdaviniai susiję su konkurencingumu, efektyvus prisitaikymas prie naujų verslo sąlygų. Prasidėjus

verslo kompiuterizacijai pirmosios informacinės sistemos buvo tapatinamos su programų

sistemomis, kurių suteikiamas funkcionalumas buvo ribotas, buvo kompiuterizuotos tam tikros

verslo proceso veiklos, verslo reikalavimai formuluojami programų sistemų funkciniais

reikalavimais. Plečiantis verslui, kompiuterizuojamas verslo procesas tampa labiau susijęs su

informacijos apdorojimu, kuris atliekamas informacinės sistemos. Programų sistema suteikia

funkcionalumą informacinei sistemai, kuri operuoja informaciniais objektais, apdoroja duomenis,

Atsiradus pirmosioms informacinėms sistemos, atsirado terminas informacijos architektūra [EE03],

kuri padeda organizacijai valdyti informaciją ir naudoti ją kaip resursą verslo procesui. Informacinė

sistema pateikia informacijos valdymo strategiją ir ją realizuoja. Informacijos architektūra yra

fundamentaliai reikalinga, kad informacinės sistemos kūrimo kontekste būtų apibrėţtos

informacinės duomenų struktūros.

Per paskutinius 30 metų buvo sukurtos kelios kartos organizacijos architektūros kūrimo

metodologijų ir metodinių karkasų, nagrinėjančių organizacijos verslo procesą, informacines

sistemas ir jas palaikančias programų sistemų sistemas. Informacinių technologijų vystymasis ir

informacinių sistemų kūrimo metodikų evoliucionavimas išskiria tris pagrindines informacinių

sistemų architektūros kartas.

8

1 lentelė. Informacinių sistemų architektūros projektavimo raida

IS architektūros

karta Sistemos apimtis Motyvacija Projektavimo pokyčiai

I karta

(1970-1980 metai)

Sistema veikianti kaip

lokali programų sistema

vieno kompiuterio

aplinkoje, apimanti vieną

organizaciją.

Suteikiamas

funkcionalumas ir

pasitenkinimas verslo

atstovų teikiama

programų sistemų nauda.

Verslo reikalavimai

įgyvendinimas tiesiogiai

siejamas su programų

sistemų reikalavimais.

Projektavime naudojamos

diagramos, remiamasi

projektavimo karkasais.

II karta

(1980-1990 metai)

Sistema veikianti kaip

programų sistemų

rinkinys, apimantis vieną

organizaciją, pasiekiama

iš skirtingų darbo vietų.

Sistemos sudėtingumo

padidėjimas;

Programų sistemų

tarpusavio

priklausomybė;

Plečiantis infrastruktūrai

atsirado sprendimų,

praktikų pakartotinio

panaudojimo poreikis.

Praplečia ir adaptuoja I

kartos IS architektūros

projektavimo diagramas;

Projektavimo karkasai,

skirti gamybos IS kurti,

pradedami naudoti

plačiau.

III karta

(nuo 1990 metų)

Sistema, suteikianti

informaciją kaip resursą

verslo procesui, atliekanti

informacijos apdorojimą.

Verslas vis labiau

priklausomas nuo išorės;

Verslo poreikis

informacijos valdymui ir

apdorojimui;

Didėja priklausomybė

tarp organizacijų;

Ţinių valdymo poreikis.

Išreikštinai apibrėţti

principai ir projektavimo

metodikos skirtingų

lygmenų IS kurti;

Metodinių karkasų

taikymas konkretiems

atvejams.

9

Pirmos kartos informacinės sistemos architektūra

1970 metais pasirodţius pirmosioms informacinių sistemų kūrimo metodologijoms ir

metodiniams karkasams, organizacijos architektūrą konstruktyviai projektuoti, siekiant sukurti

kompiuterizuotą sistemą verslo procesui palaikyti. Iš pradţių informacinė sistema buvo laikoma

sinonimu programų sistemai [Mol11], abiejų sistemų reikalavimai buvo tapatinami, nebuvo verslo

procesų visuminio palaikymo, suteikiamas funkcionalumas buvo ribotas, sistemos buvo silpnai

susijusiomis su išorinėmis sistemomis, silpna sistemų komunikacija. Programų sistemų kūrimas

remiasi krioklio modeliu. Zachman metodinis karkasas šios kartos sistemos vadina atskiromis

kompiuterinėmis programomis (angl. standalone application). Šios kartos sistemos stipriai

priklausomos nuo technologinių sprendimų.

Antros kartos informacinės sistemos architektūra

Informacinė sistema vadinama kelių programų sistemų visuma, kuri realizuoja organizacijos

tikslus platesniu mastu, visos korporacijos kontekste. Informacinės sistemos reikalavimai yra

skaidomi į atskiras programų sistemas. Šios kartos informacinės sistemos stipriai priklausomos nuo

technologijų, todėl maţesnis dėmesys skiriamas informacijos apdorojimui kūrimo procese.

Trečios kartos informacinės sistemos architektūra

Šios kartos sistemos nėra tokios priklausomos nuo technologijų kaip buvusios kartos.

Pagrindinis dėmesys skiriamas reikalingos informacijos kaip resurso pateikimui verslo procesui.

Vykdomas kompiuterizuojamo verslo proceso palaikymo apimties didinimas, todėl informacinės

sistemos apimtis išauga, padidėja sudėtingumas. Projektuojamas organizacijos architektūroje

tarpinis lygmuo verslo procesus palaikant programinės sistemos elementais. Sprendţiami sistemą

sudarančių komponentų integravimo į vieningą informacijos apdorojimo sistemą uţdaviniai

[Zac87].

Evoliucionuojančios informacinės sistemos

Šiuo metu organizacijai siekiant būti konkurencingai rinkoje keičiantis verslo aplinkai, svarbi

organizacijos savybė tampa lankstumas, greita adaptacija, naujų pokyčių suvokimas. Verslo sąlygos

pareikalauja kuo efektyvesniu būdu keisti verslo procesą, gaminti kitus produktus, pasikeitus

uţsakovams. Organizacijos verslui keliami reikalavimai iš išorinių agentų yra transformuojami į

organizacijos informacinės sistemos reikalavimus. Tuo būdu informacinė sistema vis labiau

10

integruojanti visus procesus, tampa centrinė, nesunkiai keičiama atsiradus naujiems informacijos

reikalavimams. Organizacijos verslo sėkmė ima priklausyti nuo informacinės sistemos greito

adaptavimosi. Statistika rodo, kad net 42% informacinės sistemos palaikymo išlaidų sunaudojama

naujų arba esamų informacinės sistemos reikalavimų keitimui [OPF04]. Visai nekalbama apie

programų sistemas, kurių verslo procesui teikiamas funkcinis palaikymas maţai keičiasi, jos išlieka

stabilios.

1 paveikslas. Evoliucionuojančios informacinės sistemos informacijos apdorojimas

Evoliucionuojančiose informacinėse sistemose vykdomas procesoriaus informacijos

apdorojimo procesas. Gautai uţklausai iš išorinės aplinkos, procesorius yra informuojamas apie

būsenos pasikeitimą ir pradedama informacijos apdorojimo veikla. Informacijos apdorojimas

remiasi meta modeliu aprašančiu informacinius objektus, tarpusavio elgseną, sąveikos taisykles. Tai

labai primena į informacinės sistemos reikalavimus, kurie lanksčiai modifikuojami pagal verslo

taisykles. Programų sistemos kaip funkciniai komponentai yra naudojami informacijos apdorojimo

proceso, kurie gali būti papildomi naujais.

11

1.2. Korporacijos masto sistemos

Korporacijos resursų planavimo sistemos trumpai vadinamos EPR tipo sistemomis yra plačiai

naudojamos organizacijų, kaip integruojančios ir valdančios atskirus sistemos komponentus. 1990

metais atsiradęs ERP tipo sistemų apibrėţimas atsirado iš gamybos produktų planavimo sistemos

(angl. MRP). Sistemos paskirtis gamybos resursų įsigijimo planavimas ir gamybos proceso

kompiuterizavimas. Verslo reikalavimai tenkinami ERP tipo sistemos iš ją sudarančių komponentų

tenkinamų reikalavimų vadinamų moduliais. Daţniausiai naudojami šio tipo sistemose šie moduliai:

1. Finansinė apskaita (pinigų valdymas, finansinis konsolidavimas, įsipareigojimai, turtas);

2. Vadybos apskaita (sąnaudų išlaidų valdymas);

3. Ţmogiškieji ištekliai (mokymai, įdarbinimas);

4. Gamyba (gamybos procesas, uţsakymų vykdymas, planavimas, darbo eigos stebėjimas,

kokybės kontrolė);

5. Tiekimo valdymas (tiekimo planavimas);

6. Projektų valdymas (projekto planavimas, išteklių planavimas, veiklos valdymas);

7. Ryšių su klientais valdymas (pardavimų ir rinkodaros paslaugos, klientų kontaktų

valdymas, pagalbos teikimas produkto palaikymui).

ERP tipo sistemų kūrimas remiasi sprendimų pakartotiniu panaudojimu tenkinant verslo

reikalavimus. Tai iš dalies patvirtintina darbe [ZJ97], verslo informacinių sistemų kūrimas

realizuojant naujus modulius, neieškant sukurtų modulių yra laikoma pasenusia praktika, kuri labiau

tinka programų sistemoms. Skirtingo funkcionalumo moduliai yra plačiai naudojami daugumos

organizacijų informacinių sistemų. Daugumos modulių funkcijos savybės kaip de facto standartas

priimtinas plačiai organizacijų grupei, kas sąlygoja šių sistemų populiarumą. ERP sistemų kūrimo

procesas pasiţymi reikalavimų valdymu tarp skirtingų informacinės sistemos lygmenų.

ERP tipo sistemos pasiţymi pagrindiniais savybėmis:

1. Universalumu (pagal organizacijos veiklos tipą);

2. Įvairių organizacijos grandţių (skyrių, padalinių, filialų) planavimo proceso palaikymas;

12

3. Įvairių organizacijos dalykinių sričių (gamyba, finansai, tiekimas, realizacija) planavimo

procesų palaikymas.

Darbe [MCC08] nagrinėjamos ERP tipo sistemos korporacijos architektūros modeliavimas,

kuris yra aukščiausio abstrakcijos lygmens, palaikančios verslo procesą. Bendras korporacijos

verslo procesą palaikančių sistemų modeliavimas pradedamas nuo EPR sistemos modeliavimo.

ERP sistemai keliami reikalavimai, kurie yra gaunami iš verslo lygmens vėliau yra konkretinami ir

suformuluojami programų sistemų reikalavimai. Tokiu būdu ERP sistema yra integruojanti kitas

sistemas, kurios tenkina reikalavimus. Toks skirtingų lygmenų susiejimas reikalauja papildomų

metodų ir ţinių, uţtikrinančių sistemos kokybę ir informacijos tarp skirtingų lygmenų valdymą.

ERP tipo sistemų teikiama nauda organizacijai:

1. Gerina organizacijos veiklą, optimizuoja materialinius ir finansų srautus;

2. Sistema apjungianti visus organizacijos veiklos procesų grupes: planavimas, valdymas,

pradedant ţaliavų įsigijimu ir baigiant produkcijos pristatymu klientui;

3. Leidţia pasiekti konkurencinį pranašumą įmonės verslo procesų gerinimo ir išlaidų

maţinimo dėka;

4. Tokio tipo sistemų diegimas gali pagelbėti pritraukiant investicijas, nes šių sistemų

naudojimas verslo kompanijas daro skaidresnes, o tai didina investuotojų pasitikėjimą

jomis;

5. Verslo proceso standartizavimas pagal geriausias įgyvendinimo praktikas [Mol11].

Daţnai tokios sistemos yra sudėtingos, didelės apimties ir tokių sistemų vystymas stipriai

skiriasi nuo įprastų programų sistemų kūrimo [ST12]. Bill Swanton, AMR kompanijos vice

prezidentas teigia, kad tik 35 nuošimčiai organizacijų turinčių ERP tipo sistemas yra patenkintos

sistemos funkcionalumu ir teikiama nauda, kitoms organizacijoms ERP tipo sistemų teikiamas

funkcionalumas netenkina verslo tikslų ir jų modifikavimas per brangus ir neatperka išlaidų. Tokio

tipo sistemos organizacijai kainuoja gana nemaţai, sistemų diegimas yra sudėtingas ir ilgas

procesas. Išlaidos didėja, dėl sistemos konsultavimo, darbuotojų mokymų, todėl daţnai pasitaiko

13

tokių sistemų nuoma (angl. ASP1), sistema įdiegiama tiekėjo serveryje, vartotojui suteikiama teisė

naudotis sistema uţ tam tikrą mokestį.

Darbe [JC09] nagrinėjamos ERP tipo sistemos pasiţyminčios aukštu sudėtingumo lygiu

realizavimo procesas. Skirtingų sistemos lygmenų reikalavimų valdymas yra atsakingas, kruopštus

ir laiko reikalaujantis darbas. Sistemos reikalavimai yra specifikuojami tam, kad būtų suformuoti

ţemesnio lygmens reikalavimai sistemos komponentams realizuoti. Šiame procese nagrinėjami

reikalavimai skirtingu lygmeniu, kas padeda lengviau įţvelgti problemas ir jas išspręsti.

Reikalavimų valdymas yra plati tema nagrinėjama mokslinių straipsnių. Darbo [RR99] autoriaus

yra pateikti net 17 reikalavimų rūšių, kurie grupuojami į 3 pagrindines dalis: produkto, funkciniai ir

nefunkciniai reikalavimai. Kai kurių reikalavimų įgyvendinimas gali pareikalauti sudėtingesnių

sprendimų, nei reikalavimus nuleidţiant į programų sistemų lygmenį.

ERP tipo informacinės sistemos

Organizacijos verslo procesas susideda iš keleto veiklų, kurio pagrindinis uţdavinys pradinių

resursų transformavimas į proceso sukuriamus rezultatus. Resursų transformacija kartais reikalauja

ţmogaus, sistemos arba abiejų įsiterpimo. ERP tipo sistemų sėkmingą vystymąsi lėmė verslo

proceso palaikymas operaciniu lygmeniu. Tai buvo labai ribotos funkcionalumo sistemos,

reikalaujančios daţno į verslo procesą ţmogaus įsiterpimo. Vėlesnės kartos ERP tipo informacinės

sistemos rėmėsi organizacijos ilgesnio laikotarpio taktiniais sprendimais, kol galiausiai pradėjo

palaikyti verslo procesus organizacijos strateginiu lygmeniu. ERP tipo informacinių sistemų

plėtimuisi ir vystymuisi, sistemai palaikant verslo procesą didesne apimtimi, įgyvendinimui

neišvengiamai reikalinga vis įvairesni ir sudėtingesni sprendimai susiejantys tarpusavyje sistemos

komponentus. ERP tipo sistema tampa verslą palaikanti informacinė sistema, apdorojanti

informaciją verslo procesui palaikyti. Informacija betarpiškai susijusi su korporacijos verslo

procesu turi būti apdorojama ir valdoma informacijos apdorojimo sistemos [SV09].

1.3. Korporacijos paslaugų stiliaus IS

Organizacijos verslo procesą palaikantis informacinė sistema yra sudėtinga, susidedanti iš

skirtingų programinės įrangos komponentų. Sistemos įgyvendinimas reikalauja atskirų modulių

1 ASP (angl. Application Service Providing) – programinės įrangos nuoma.

14

teikiamo funkcionalumo realizavimo arba pasinaudoti jau esamais sukurtais spendimais,

teikiamomis paslaugomis. Į paslaugas orientuotas informacinės sistemos architektūros kūrimas

leidţia nuotoliniu būdu dalinai išskirstyti sistemos funkcionalumą ir realizuoti atskiruose sistemos

dalyse. 1970 metais atsiradęs paslaugomis orientuotos architektūros (angl. SOA) projektavimas

pateikia sistemų kūrimo ir integravimo atskirų sistemų dalių koncepciją, leidţiančią kurti

išskirstytas sistemas, sukomponuoti, sumaţinti sąryšį tarp atskirų elementų. Sistemos kūrėjui

paliekama pasirinkimo laisvė pasirinkti tarp padėsiančių įgyvendinti technologinių sprendimų, kaip

pavyzdţiui CORBA2, Java RMI

3, DCOM

4.

2 paveikslas. Paslaugų sistemų tarpusavio sąveika

Korporacijos informacinės sistemos kūrimas grindţiamas paslaugomis, gaunamomis

nuotoliniu būdu iš paslaugų tiekėjų. Su paslaugomis grįsto architektūrinio stiliaus atsiradimu,

2 CORBA (angl. Common Object Request Broker Architecture) – architektūra, leidţianti efektyviai bendrauti

paskirstytų programų sudėtinėms dalims.

3 Java RMI (angl. Java Remote Method Invocation) – Java nutolusių metodų kvietimas.

4 DCOM (angl. Distributed Component Object Model) – išskirstytas komponentinis objektų modelis.

15

pradėjo sparčiau vystytis organizacijos architektūros kūrimo metodologijos [SHM08], grindţiamos

išskirstytų sistemų integravimu informacinei sistemai sukurti, pavyzdţiui: DoDAF5, MoDAF

6,

TOGAF7.

3 paveikslas. Paslaugos realizacija paslaugų stiliaus sistemų

Korporacijos paslaugų stiliaus informacinės sistemos reikalavimai trasuojami į paslaugų

servisus, kurie reikalavimus įgyvendina programų sistemose. Paslaugų stiliaus architektūra (angl.

SOA) supaprastina sistemos projektavimą. Sistema naudoja paslaugų servisus, kurie kuriami ir

palaikomi nepriklausomai nuo sistemos gyvavimo ciklo.

Paslaugomis orientuotos architektūros privalumai:

Naujo funkcionalumo integravimas į paslaugų stiliaus sistemas reikalauja maţiau sąnaudų,

nei į monolitines sistemas;

5 DoDAF (angl. Department of Defense Architecture Framework)

6 MoDAF (angl. Ministry of Defense Architecture Framework)

7 TOGAF (angl. The Open Group Architecture Framework)

16

Padidina informacinės sistemos lankstumą ir sumaţina reakcijos laiką prisitaikant prie naujų

verslo reikalavimų;

Į paslaugas orientuotas funkcionalumas yra nesunkiai pakartotiniu būdu panaudojamas kitų

sistemų;

Sistemos informacijos apsikeitimas su paslaugų servisais yra standartizuotas ir vienodas tarp

visų sistemų.

1.4. Korporacijos IS architektūros samprata

Verslo įmones palaikančių informacinių sistemų kūrimas yra sudėtingas ir laiko reikalaujantis

darbas. Siekiant, kad verslą palaikanti informacinė sistema kuo geriau atitiktų verslo tikslus ir

tenkintų verslo poreikius, informacinės sistemos kūrimas, kaip ir verslo turėtų būti atliekamas

lygiagrečiai vienu metu. Formuojant informacinės sistemos architektūrą, pirmiausia nusakoma

korporacijos architektūra, apibrėţianti organizacijos verslo, informacinius, duomenų valdymo

procesus, logines konstrukcijas [Zac87]. Korporacijos architektūrai keliami klausimai:

Kokia ir ar tinkama pasirinkta organizacijos struktūra?

Kaip organizacija kontroliuoja verslo procesus?

Kokia informacija yra reikalinga, operuojant verslo procesus?

Kokios informacinės sistemos reikia organizacijai?

Atsakymai į šiuos klausimus padeda geriau įţvelgti skirtingų kontekstų atsakomybes ir

poţiūrio taškus.

Vystantis technologijoms, kintant informacinės sistemos apimčiai, korporacijos architektūra

skirtingu laikotarpiu buvo modeliuojama skirtingai. Darbe [Cae09] autoriai nagrinėja korporacijos

architektūrą susidedančią iš 4 skirtingų kontekstų arba lygmenų.

17

Korporacijos architektūros lygmenys

1. Organizacijos lygmuo;

2. Verslo lygmuo;

3. Informacinės sistemos lygmuo;

4. Technologijų lygmuo.

Informacinės sistemos lygmuo analizuojamas platesniu poţiūriu, skaidant lygmenį (ţr. 4

paveikslas. Organizacijos architektūros lygmenys) į dvi dalis.

4 paveikslas. Organizacijos architektūros lygmenys

Verslo architektūra apibrėţia verslo strategiją, viziją, misiją, procesus. Verslo reikalavimai

formuoja informacinės sistemos reikalavimus;

Programų sistemų architektūra nusako kaip bus kuriama programinė įranga, kuri atitiks

informacinės sistemos reikalavimus;

Informacijos architektūra aprašo logines duomenų struktūras, naudojamas programų

sistemų;

Technologijų architektūra aprašo programinės įrangos veikimo terpė, kokios technologijos

naudojamos.

18

Šioje architektūroje programų sistema yra tapatinama su verslą palaikančia informacine

sistema ir sudaro vieną lygmenį architektūros apibrėţime. Verslo procesus palaikanti programų

sistema yra monolitinė, pasikeitus verslo reikalavimams šios sistemos teikiamas funkcionalumas

netenkins naujų verslo poreikių, nes programų sistemos nėra adaptyvios.

Organizacijos verslo procesus palaikanti sistema yra projektuojama trijų lygmenų (ţr. 5

paveikslas. Verslą palaikančios IS architektūros lygmenys) [ČLV03]. Informacijos apdorojimo

lygmuo projektuojamas išreikštiniu būdu, atskiriamas nuo verslo lygmens, programų sistemoms

reikalavimai apibrėţiami iš informacinės sistemos lygmens. Programų sistemos turi maţiausią

polinkį kisti, suteikdamos funkcionalumą informacinei sistemai, kurios procesai nesunkiai

modifikuojami pasikeitus verslui.

ERP tipo sistemų, kurios laikomos informacinės sistemos sinonimu, kūrimo metodai

naudojantys verslo informacijos apdorojimo procesus padeda uţtikrinti ERP tipo sistemų

lankstumą, kintant verslo procesams [SV09], sumaţinant pokyčius programų sistemose.

Toliau nagrinėdami informacinių sistemų kūrimo metodinius karkasus ir metodologijas,

remsimės trijų lygmenų informacinės sistemos architektūra, kuri projektuoja išreikštiniu būdų

informacijos apdorojimą.

19

5 paveikslas. Verslą palaikančios IS architektūros lygmenys

20

2. METODIKŲ ANALIZĖ

2.1. Zachman metodinis karkasas

Zachman metodinis karkasas sukurtas 1980 metais, IBM tyrėjo John. A.Zachman, autoriaus

pavarde taip pat pavadintas. Tai vienas iš pirmųjų metodinių karkasų projektuojančių organizacijos

architektūrą informacinei sistemai kurti. Iki metodinio karkaso atsiradimo, tuometinės organizacijos

neturėjo vieningos architektūros. Paplitusi praktika dokumentuoti ir projektuoti atskiras

architektūros dalis, be visuminės organizacijos architektūros apibrėţimo. Verslą palaikančios

sistemos buvo monolitinės, sudėtingos, verslo procesai buvo silpnai kompiuterizuoti. John.

A.Zachman pasiskolino architektūros terminą iš namų statybos srities, kurioje architektūros

projektavimas buvo labiau paţengęs nusakyti organizacijos architektūros projektavimui.

Zachman metodinis karkasas yra vienas iš plačiausiai taikomų organizacijos architektūros

projektavimo įrankių konceptualizuoti korporacijos architektūrą aukštu abstrakcijos lygmeniu.

Darbe [FHM03] nagrinėjama organizacijos architektūros konceptualizavimas susijęs su Zachman

metodinio karkaso aukštos abstrakcijos architektūros modeliavimu, kuris yra lankstus ir

nepriklausomas nuo specifinių įgyvendinimo technikų. Karkasas nepateikia konkrečių informacijos

rinkimo ir valdymo procesų kurie padėtų uţpildyti reikiama informaciją karkaso schemą. Be

nurodytų artefaktų ir metodų, neįmanoma patikrinti, ar sukurti karkaso elementai yra teisingi, ar

korporacijos architektūros kūrimas tęsiamas [Zac87].

Zachman korporacijos architektūros kūrimo metodinis karkasas pateikiantis formaliai

organizacijos architektūros struktūrą. Informacija pateikiama dviejų dimensijų klasifikavimo

schemos pavidalu, organizacijos architektūra yra skirstoma į lygmenis, skirtingus poţiūrius.

Kiekvienas architektūros lygmuo skaidomas į skirtingas fundamentalias dalis, kurioms keliami

klausimai padedantys nustatyti kiekvieno lygmens atitinkamos dalies sukuriamą produktą.

Aukštesnio lygmens klausimo suformuoti reikalavimai sukuria ribojimą ţemesnio lygmens

reikalavimams. Metodinis karkasas apibrėţia kas bus sukurta, neatsiţvelgiant į kaip tai bus

padaryta.

21

2 lentelė. Zachman metodinio karkaso klasifikavimo schema

Ką?

(apdorojami

objektai)

Kaip?

(procesai)

Kur? (vieta) Kas?

(vykdytojai)

Kada?

(laikas)

Kodėl?

(motyvacija)

Planavimo

lygmuo

Objektai

susiję su

verslu

Verslo

vykdomos

uţduotys

Verslo

vykdymo

vietos

Verslą

valdančios

organizacijos

Verslui

reikšmingi

įvykiai

Verslo

tikslas,

strategija

Verslo

lygmuo

Verslo

objektai

Verslo

procesai

Darbo vieta Verslo

proceso

vykdytojai

Verslo

našumas

Verslo

misija,

vizija, planas

Sistemos

lygmuo

(Programų

sistema)

Loginė

duomenų

struktūra

Programų

sistemos

funkciniai

reikalavimai

Programų

sistemos

dislokavimas

Vartotojo

sąsaja

Sistemos

veikimo

našumas

Verslo

taisyklės

Technologijų

lygmuo

Fizinės

duomenų

saugyklos

Sistemos

komponentų

realizavimas

Sistemos

komponentų

sąveika

Sistemos

komponentų

architektūros

aprašas

Sistemos

komponentų

našumas

Sistemos

eskizinis

projektas

Zachman metodinio karkaso lygmenys:

Planavimo lygmuo organizacijos architektūrą nagrinėja iš abstrakčiausio poţiūrio.

Šiame lygmenyje vertinamas organizacijos dydis, sukūrimo kaštai, padalinių skaičius,

sąryšiai su kitomis įstaigomis veikiančiomis toje pačioje aplinkoje;

Verslo lygmuo aprašo verslo procesus vykdomus organizacijos, verslo objektus,

organizacijos verslo architektūrą, procesų sukuriamus rezultatus;

Sistemos lygmuo aprašo logines duomenų konstrukcijas, modelius, architektūros

aprašą, tam kad programų sistemų architektas galėtų projektuoti sistemą pagal

poreikius ir technines galimybes;

22

Technologijų lygmuo aprašo sistemos įgyvendinimą technologiniame lygmenyje,

apibrėţiamos kokios bus naudojamos technologijos, kokia sistemos architektūra

taikant technologinius sprendimus, galutinio produkto projektavimas.

Atsiradęs Zachman metodinis karkasas suteikė verslui įrankį leidţiantį fundamentaliai

apibrėţti organizacijos architektūrą, kuri leistų kurti informacinę sistemą. Tuo metu tik pradėjus

evoliucionuoti informacinių sistemų architektūrai, jos buvo tapatinamos su programų sistemomis,

Zachman metodiniame karkase vadinama tiesiog sistema (ţr. 2 lentelė. Zachman metodinio karkaso

klasifikavimo schema). Verslo reikalavimai betarpiškai projektuojami programų sistemų lygmenyje,

informacijos apdorojimo procesas išreikštiniu būdu neprojektuojamas. Verslo taisyklės, kurios turi

polinkį daţnai keistis dėl verslo sąlygų įtraukiamos į programų sistemos kontekstą, vėliau sumaţina

sistemos keičiamumą ir programų sistema tampa nebenaudojama, reikalingi kaštai per dideli

sistemai atnaujinti. Sistema nebetenkina verslo poreikių, investicijos neatsiperka.

Vienas iš karkaso pagrindinių trūkumų yra paţeistas turinių atskyrimo principas, verslo

lygmens duomenys perkeliami į programų sistemos lygmenį. Pasikeitus verslo modeliui [AO05]

programų sistema nebetenkina verslo poreikių ir verslo taisyklių.

6 paveikslas. Verslo procesą palaikančios programų sistemos

23

O turėtų būti [FHM03], kad verslo lygmuo yra nepriklausomas nuo informacinės sistemos.

Informacinė sistema yra nepriklausoma nuo programinės įrangos realizuojančios verslą

palaikančios sistemos reikalavimus. Programų sistemos reikalavimai formuoja technologinį

sistemos kontekstą, kuris leidţia sukurti produktą ir funkcionuoti technologinėje aplinkoje.

Zachman metodinis karkasas korporacijos architektūrą schemiškai padalina į artefaktus,.

suprojektavus architektūros lygius, metodinis karkasas patvirtina ir uţtikrina architektūros lygmenų

tarpusavio darnų susietumą, integralumą, skirtingų architektūros lygmenų reikalavimų valdymą,

uţtikrina, kad tarp skirtingų lygmenų perduodama informacija bus suvaldyta tinkamai. Darbas

[FST07] nagrinėjantis karkaso integralumą ir darną nurodo, kad Zachman karkaso idėja,

nagrinėjanti architektūrą vien tik iš skirtingų poţiūrio taškų, ne visai korektiška, nepateikiant

priemonių, kurios uţtikrintų skirtingų poţiūrių integralumą, duomenų ir informacijos korektišką

apsikeitimą.

24

2.2. TOGAF ADM metodika

TOGAF metodinis karkasas pateikia būdus kaip projektuoti, įgyvendinti patikimą

organizacijos architektūrą, kuri tenkintų verslo poreikius. TOGAF susideda iš trijų pagrindinių dalių

[LZ06]:

1. TOGAF metodinio karkaso inţinerinis procesas ADM nurodo būdus ir procedūras

organizacijos architektūrai kurti;

2. Vieta (angl. Enterprise Continuum), kurioje laikomi architektūros projektavimui reikalingi

resursai: modeliai, šablonai, architektūros aprašai, kiti artefaktai. Vadinama virtualia

duomenų saugykla;

3. Rinkinys įrankių ir metodikų (angl. Resource Base) padėsiančių kurti TOGAF metodinio

karkaso architektūrą pagal ADM inţinerinį procesą.

ADM inţinerinis procesas aprašo detaliai organizacijos architektūros kūrimo procedūras,

pakartotinai vykdant visame kūrimo procese skirtingose architektūros kūrimo fazėse. Architektūros

kūrimo metu naudojami resursai iš virtualios duomenų saugyklos, taikant TOGAF pateiktus

įrankius ir metodikas. Karkaso išskiriamos pagrindinės kūrimo fazės:

A. Architektūros vizija;

B. Verslo architektūra;

C. Informacinės sistemos architektūra;

D. Technologijų architektūra;

E. Sprendimų architektūra (angl. opportunities and solutions);

F. Migravimo planavimas (angl. migration planning);

G. Įgyvendinimas (angl. implementation governance);

H. Architektūros pokyčių valdymas.

25

7 paveikslas. Architektūros projektavimo schema naudojant TOGAF

Informacinės sistemos architektūros projektavimas yra skaidomas į dvi atskiras dalis:

1. Duomenų architektūra sudaro tarpinę grandį tarp programų sistemos ir verslo

architektūros. Aprašo duomenų struktūras, tipus, informacijos apsikeitimui su verslo

lygmeniu. Verslo atstovams duomenys turi būtų aiškūs, išbaigti, suteikiantys pakankamai

ţinių verslui palaikyti. Duomenų architektūros tikslas nėra modeliuoti logines duomenų

struktūras naudojamas programų sistemos;

2. Programų sistemų architektūra nusakoma kaip programų sistemų rinkinys, kuris gali būti

sugrupuotas pagal skirtingas funkcines savybes, apdorojantis duomenis ir palaikantis

verslo funkcijas. Programų sistemos yra stabilios ir beveik nesikeičia naudojimo

laikotarpiu.

26

Verslo architektūra modeliuojama UML8 kalba, verslo procesai nustatomi veiklos

diagramomis, naudojimosi scenarijais, tam kad būtų sukurtas bazinės verslo architektūros aprašas,

leidţiantis projektuoti programų sistemas.

Programų sistemos funkcionalumas tapatinimas funkcinių schemų pagalba su verslo

funkcijomis, kurios yra dalis verslo proceso. Verslo procesas palaikomas funkciniame lygmenyje,

tenkinant verslo funkcijų reikalavimus, neatsiţvelgiant į informacijos apdorojimo reikalavimus

reikalingus verslo procesui palaikyti.

Išreikštiniu būdu verslo lygmens procesai nesiejami su informacijos apdorojimo procesais,

kurie turėtų būti vykdomi lygiagrečiai. Programos sistemos kaip funkciniai komponentai tiesiogiai

siejami su verslo procesais, kurie turi polinkį keistis, kintant verslo aplinkai. Funkciniai

komponentai nebetenkina naujų reikalavimų, kai programinės sistemos reikalavimai keičiasi.

Karkaso lygmenis sudarantys elementai:

1. Verslo architektūra: verslo modelis, organizacijos procesas, informacijos architektūra;

2. Programų sistemų architektūra: korporacijos programų sistema, portalas ir informacijos

valdymo platforma, duomenų saugykla, paslaugų tiekėjai;

3. Technologijų architektūra: paslaugų servisai, sistemos talpinimo sistema, duomenų

saugykla, tinklo infrastruktūra.

Architektūros karkasas [Roh08] aiškiai ir vienareikšmiškai apibrėţia verslo arhitektūrą ir

technologijų architektūrą. Informacinės sistemos architektūra, kuri yra tapatinama šiame karkase su

programų sistemų architektūra, kuri palaiko verslo procesus. Verslo lygmens taisyklės ir veiklos

projektuojamos programų sistemoje, paţeidiant turinių atskyrimo principą. Informacijos

architektūra [Mol11] nėra išskiriama kaip atskiras architektūros lygmuo, kuris turėtų būti tarpinis

tarp verslo ir programų sistemų.

TOGAF karkasas programų sistemos architektūros modelio kūrime, kuriame gali būti įvairių

sąryšių, priklausomybių tarp skirtingų sistemų, pateikia architektūrinį karkasą kurti integruotoms

8 UML (angl. Unified Modeling Language) – modeliavimo ir specifikacijų kūrimo kalba, skirta specifikuoti,

atvaizduoti ir konstruoti objektiškai orientuotų programų dokumentus.

27

informacinėms sistemoms (angl. III-RM9). Tuo pateikiama, programų sistemų kaip grupės kūrimas,

kuomet organizacijos gali vykdyti verslo procesus kartu, procesai palaikomi kelių programų

sistemų, kurių sąryšiai uţtikrina informacijos perdavimą (angl. boundaryless information flow). Šio

karkaso išplėtimas leidţia kurti komunikuojančias programų sistemas, kurios vienu metu gali būti

kaip resursų tiekėjos kitoms, ir tuo pat metu naudoti resursus.

9 III-RM (angl. Integrated Information Infrastructure Reference Model).

28

2.3. SOMA metodas

SOMA10

metodas, sukurtas IBM grupės architektų ir susijusių organizacijų narių plėtojančių

SOA architektūrą, nurodantis taisykles organizacijai padedančias sukurti SOA architektūrą. Kūrimo

proceso pagrindiniai etapai: analizė, projektavimas, įgyvendinimas, diegimas. Kiekvienam etapui

SOMA metodas apibrėţia technikas, roles, darbų skaidinį (angl. WBS11

), įeitis, išeitis, proceso

vykdymo taisykles. Metodas gali būti plačiai taikomas organizacijų projektuojančių architektūrą

SOA pagrindu.

SOMA metodas susideda iš 7 pagrindinių etapų:

1. Verslo modeliavimas ir transformacija;

2. Sprendimų valdymas;

3. Esamų servisų identifikavimas;

4. Servisų specifikavimas;

5. SOA sprendimų realizavimas;

6. Įgyvendinimas, konstravimas;

7. Diegimas, stebėjimas, valdymas.

Kiekvienas etapas detaliau pateikiamas su veiklomis (ţr. 8 paveikslas. SOMA gyvavimo ciklo

modelis), kurios plačiau nagrinėjamos identifikavimo, specifikavimo, realizavimo etapų,

atsiţvelgiant į informacinės sistemos lygmenų projektavimą.

Pradedant nuo identifikavimo etapo, kuriame nagrinėjami trys pagrindiniai SOA

fundamentalūs elementai: servisas, komponentas ir sąveika. Rekomendacijos teigia [AGA+08], kad

atliekant verslo modelio veiklų komponavimą, veiklos, siekiančios verslo tikslų, turi būti siejamos

su paslaugų servisais, kurie modeliuoja verslo veiklas (angl. GSM12

). Toks poţiūris, labai primena

verslą palaikančias programų sistemas, kurių realizuojami funkciniais reikalavimai, palaiko verslo

10

SOMA (angl. Service Oriented Modeling and Architecture) – paslaugų stiliaus architektūros modeliavimas.

11 WBS (angl. Work Breakdown Structure) – darbų išskaidymo stuktūra.

12 GSM (angl. Goal Service Modelling) – paslaugų servisų modeliavimas atliekamas remiantis veslo tikslais.

29

veiklas ir pasiekia verslo tikslus. Tačiau jei verslo procesus palaiko informacinė sistema, verslo

tikslai yra pasiekiami informacinės sistemos vykdomų informacijos apdorojimo procesų. Šiek tiek

keičiasi SOMA metodo identifikavimo etapas, kai paslaugų servisai turėtų būti projektuojami iš

informacinės sistemos perspektyvos, o ne iš verslo lygmens. Paslaugų servisų krepšelis (angl.

portfolio) nėra tiesiogiai siejamas su verslo veiklomis, kurios vykdomos verslo procesų. Tokia

praktika apsunkintų verslo procesų lankstų adaptavimą ir koregavimą. Informacinės sistemos

lygmuo atlieka tarpinį vaidmenį tarp verslo ir paslaugų servisų.

8 paveikslas. SOMA gyvavimo ciklo modelis

30

Verslo veiklų identifikavimas ir nustatymas [AGA+08], kurios veiklos bus atliekamos

paslaugų servisų nėra korektiškas sprendimas, ţinant kad verslo informacinė sistema palaiko visas

verslo proceso veiklas. Verslo modelio dekompozicijos veikloje verslo modelio procesai

modeliuojami, verslo veiklas priskiriant paslaugų servisams, ţinant kad verslo procesai savyje turi

verslo taisykles, ribojimus, kitimo tikimybę, ne visai tinkamas sprendimas, keičiantis verslo

modeliui.

Sekančiame specifikavimo etape priimami serviso paslaugų realizavimo sprendimai.

Tyrinėjamos esamos programų sistemos, ieškoma būdų kaip serviso paslaugos būtų įgyvendintos

maţiausiais kaštais su turimais resursais. Organizacijos verslą palaikančios programų sistemos

tampa komponentais SOA architektūroje. Darbe [AGA+08] teigiama, kad verslą palaikančios

programų sistemos nelanksčios, SOA architektūra šią problema padeda išspręsti. Tačiau visai

nenagrinėjamas informacinės sistemos kontekstas, kurio pagrindinė uţduotis yra uţtikrinti verslo

procesų palaikymą, nesvarbu kas realizuoja programų sistemos ar paslaugų servisai. Metodas

padeda organizacijai įgyvendinti SOA architektūrinius sprendimus, turinčią verslą palaikančią

programų sistemą.

31

IŠVADOS IR PASTEBĖJIMAI

Vystantis informacinėms sistemoms bei keičiantis jų sampratai, neišvengiamai kinta ir

korporacijos architektūros projektavimas verslo sistemoms kurti. Informacinės sistemos termino

suvokimas skirtingu laikotarpiu buvo skirtingas, sampratos kitimas informacines sistemas išskyrė į

tris pagrindines kartas pagal reikšmingus skirtumus. Pirmosios buvo tiesiogiai tapatinamos su

programų sistemomis, informacijos apdorojimo procesai jose nebuvo vykdomi. Verslą palaikančios

sistemos vis labiau tampa neatsiejamos nuo verslo procesų. todėl suprojektuoti verslą palaikančios

sistemos architektūrą adekvačią verslui yra sudėtingas ir netrivialus uţdavinys. Korporacijos masto

sistemų projektavimas remiasi metodikomis, metodiniais karkasai, fundamentaliais metodais, kurie

nurodo fundamentalius principus korporacijos architektūros projektavimui ir informacinės sistemos

kūrimui. Kintant informacinės sistemos sampratai, metodikos nurodančios kaip kurti tokio tipo

sistemas, pateikiama nurodymus tokių sistemų kūrimui, atsiţvelgiant tuo metu vyraujančią

informacinės sistemos apibrėţimą.

Pavyzdţiui 1987 metais publikuotas Zachman metodinis karkasas apibrėţiantis korporacijos

architektūrą informacinei sistemai kurti iš tiesų kalba apie programų sistemą. Zachman

metodiniame karkase nėra projektuojamas informacijos apdorojimo lygmuo. Verslo lygmens

reikalavimai yra nuleidţiami ţemyn tiesiogiai į programų sistemų reikalavimus. Verslo dalykinės

srities ekspertų, kurie vyko verslo procesą, poţiūris nenagrinėjamas, kokių informacinių,

skaičiavimo paslaugų reikės vykdyti verslo procesą. Informacinės sistemos lygmuo praleidţiamas,

tarsi tiksliai ţinoma, kokios programinės įrangos reikia. Toks projektavimas korektiškas kai verslo

dalykinės srities specialistai ţino kokios programų sistemos reikia ir ji nėra didelė.

TOGAF ADM metodika apibrėţianti korporacijos architektūrą verslo informacinei sistemai

kurti išreikštiniu būdu neprojektuoja verslo procesą palaikančių informacinės sistemos informacijos

apdorojimo paslaugų. Apibrėţiamas informacinės sistemos lygmuo yra tapatinamas su programų

sistema, tuo iš dalies patvirtina ADM procesas nurodantis kad šis lygmuo maţai kintantis, esantis

stabilus. Metodika apibrėţianti korporacijos paslaugų stiliaus informacinių sistemų kūrimą verslo

lygmens reikalavimus sieja funkcinėmis schemos su programų sistemų reikalavimais, praleidţiamas

informacijos apdorojimo lygmuo. TOGAF metodiniame karkase programų sistemose išreikštiniu

būdu projektuojama duomenų architektūra, apibrėţianti informacijos struktūra kuri maţai kintanti,

naudojama sistemos ir verslo dalykinės srities ekspertams.

32

SOMA metodas pateikia organizacijai kaip įgyvendinti teisingai SOA architektūrą, turinčiai

verslą palaikančią programų sistemą. Metodas nurodo etapus su ţingsniais kas turi būti daroma,

norint verslo palaikančios programų sistemos veiklas realizuoti kaip paslaugas. Metodas verslo

lygmenį nagrinėja kartu su palaikančia programų sistema, kuri atlieka verslo procesų palaikymą.

Paslaugų servisuose projektuojant verslo veiklas, naudojant tinklinių paslaugų choreografija, kuri

paremta laisvai prieinamomis tinklinėmis paslaugomis. Programų sistemos naudojančios tinklines

paslaugas, sumaţina sudėtingumą, pokyčių tikimybę, paprastėja tokių sistemų palaikymas. Metodo

pateikiamos taisyklės padeda verslo programų sistemą perdaryti į paslaugų stiliaus programų

sistemą.

Išnagrinėjus tris informacinės sistemos kūrimo metodikas ir metodinius karkasus, atlikus

analizę, gavus rezultatus, galime teigti, kad nė viena iš metodikų ir metodinių karkasų nenagrinėja

informacinės sistemos išreikštiniu poţiūriu. Zachman metodiniame karkase ir TOGAF AMD

metodikoje informacinė sistema tapatinama su programų sistema. Tokioje sistemoje dalykinės

srities ekspertas turi ţinoti kokios verslo veiklos turi būti kompiuterizuotos. Verslo reikalavimai

nėra nuleidţiami į informacinės sistemos lygmenį, tačiau tiesiogiai nuleidţiami į programų sistemų

lygmenį. SOMA metodas nurodo kaip esančią verslą palaikančią sistemą realizuoti paslaugų stiliaus

sistema. Metode nagrinėjamas verslo lygmuo siejamas kartu su verslą palaikančia programų

sistema, kurios kompiuterizuotos veiklos skaidomos į paslaugas.

Galime patvirtinti hipotezę, kad išnagrinėtos metodikos ir metodiniai karkasai nenagrinėja

informacinės sistemos lygmens, bei nepateikia nurodymų, kaip verslo procesas yra palaikomas

informacijos apdorojimo sistemos, kuri verslo veiklas kompiuterizuoja programų sistemose.

33

ŠALTINIAI

[AGA+08] A.Arsanjani, S.Ghosh, A.Allam, T.Abdollah, S.Ganapathy, K.Holley. SOMA: A

method for developing service-oriented solutions. IBM Systems Journal, 47(3), 2008,

pp.377-396.

[AO05] V.Anaya, A.Ortiz. How Enterprise Architectures Can Support Integration. ACM 1-

59593-184-5, 2005, pp.25-30.

[BS11] M.A.Bari, S.Ahamad. Process of Reverse Engineering of Enterprise Information

System Architecture. IJCSI International Journal of Computer Science Issues, 2001,

pp.359-365.

[Cae09] A.Caetano. A Role-Based Enterprise Architecture Framework. ACM 978-1-60558-

166-8, 2009, pp.253-258.

[ČLV03] A.Čaplinskas, A.Lupeikienė, O. Vasilecas. The Role of Ontologies in Reusing

Domain and Enterprise Engineering Assets. Informatica, 14(4), 2003, pp.455–470.

[EE03] R.Evernden, E.Evernden. Third-Generation Information Architecture.

Communications of the ACM, 2003, pp.95-98.

[FST07] A.Fatolahi, S.S.Somé, C.Timothy. Lethbridge.Enterprise Architecture Using the

Zachman Framework: A Model Driven Approach. Managing Worldwide Operations

& Communications with Information Technology, 2007, pp.65-69.

[JC09] B.Johansson, R.Carvalho. Management of Requirements in ERP development: A

Comparison between Proprietary and Open Source ERP. Proceedings of the 2009

ACM symposium on Applied, 2009, pp.1605-1609.

[LZ06] S.Leist, G.Zellner. Evaluation of Current Architecture Frameworks. ACM 1-59593-

108-2, 2006, pp.1546-1553.

[MCC08] R.M.Monnerat, R.A.Carvalho, R.Campos. Enterprise Systems Modeling: the ERP5

Development Process. ACM 978-1-159593-753-7, 2008, pp.1062-1068.

[Mol11] B.Molnar. The Country-specific Organizational and Information Architecture of ERP

Systems at Globalised Enterprises. Business Systems Research Vol.2, No.2. 1-56,

2011, pp.39-50.

[OPF04] J.L.H.Oei, H.A.Proper, E.D.Falkenberg. Modelling the Evolution of Information

Systems, 2004, pp. 1-23.

[Roh08] M.Rohloff. An Integrated View on Business - and IT-Architecture. ACM 978-1-

59593-753-7, 2008, pp.561-565.

[RR99] S. Robertson, J. Robertson Mastering the requirements process. Addison Wesley,

1999 pp.395.

34

[SHM08] D.T.Sanders, J.A.Hamilton, R.A.MacDonald. Supporting A Service-Oriented

Architecture. SpringSim, 2008 pp.325-334.

[Spe92] S.Spewak. Enterprise Architecture Planning: Developing a Blueprint for Data,

Applications and Technology. John Wiley and Sons, Inc. New York. ISBN: 0-471-

599859, 1992, pp.1-35.

[ST12] L.Shaul, D.Tauber. CSFs along ERP life-cycle in SMEs: a field study. Industrial

Management & Data Systems, 112(3), 2012, pp.360-384.

[SV09] A.Smaizys, O.Vasilecas. Business Rules Based Agile ERP Systems Development.

Informatica, 20(3), 2009, pp.439–460.

[Vas07] A.Vasconcelos. Information System Architecture Metrics: an Enterprise Engineering

Evaluation Approach. Electronic Journal of Information Systems Evaluation, 2007,

pp.91-122.

[Ver03] F.B.Vernadat. Enterprise Modelling and Integration: From Fact Modelling to

Enterprise Interoperability. Library of Congress Cataloging-in-Publication Data.

Enterprise Inter- and Intra-Organizational Integration: Building International

Consensus. ISBN: 0-4020-7277-5, 2003, pp.25-33.

[Zac87] J.A.Zachman. A framework for information systems architecture. IBM System Journal

26(3). 1987, 276–292,

[ZJ97] P.Zave, M.Jackson. Four dark corners of requirements. ACM Transactions on

Software Engineering and Methodology, 1997, pp.1-30.